* can't unmount /sys/fs/selinux
@ 2021-01-13 21:44 Petr Lautrbach
2021-01-13 22:09 ` Stephen Smalley
0 siblings, 1 reply; 5+ messages in thread
From: Petr Lautrbach @ 2021-01-13 21:44 UTC (permalink / raw)
To: selinux
Hi,
we have few tests which uses `umount /sys/fs/selinux` trick to check how
userspace works in SELinux "disabled" environment. But it's not possible
with the current master:
# umount /sys/fs/selinux
umount: /sys/fs/selinux: target is busy.
# lsof /sys/fs/selinux
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
systemd 1 root mem REG 0,21 0 19 /sys/fs/selinux/status
systemd 1 root 55r REG 0,21 0 19 /sys/fs/selinux/status
systemd-u 875 root mem REG 0,21 0 19 /sys/fs/selinux/status
systemd-u 875 root 6r REG 0,21 0 19 /sys/fs/selinux/status
dbus-brok 1116 dbus mem REG 0,21 0 19 /sys/fs/selinux/status
dbus-brok 1116 dbus 5r REG 0,21 0 19 /sys/fs/selinux/status
systemd-l 1134 root mem REG 0,21 0 19 /sys/fs/selinux/status
systemd-l 1134 root 4r REG 0,21 0 19 /sys/fs/selinux/status
systemd 1643 root mem REG 0,21 0 19 /sys/fs/selinux/status
systemd 1643 root 28r REG 0,21 0 19 /sys/fs/selinux/status
(sd-pam) 1645 root mem REG 0,21 0 19 /sys/fs/selinux/status
...
sshd 218874 root mem REG 0,21 0 19 /sys/fs/selinux/status
sshd 218874 root 3r REG 0,21 0 19 /sys/fs/selinux/status
sshd 218880 plautrba mem REG 0,21 0 19 /sys/fs/selinux/status
sshd 218880 plautrba 3r REG 0,21 0 19 /sys/fs/selinux/status
It seems to be caused by commit 05bdc03130d7 ("libselinux: use kernel
status page by default") which replaced avc_netlink_open() in
avc_init_internal() with selinux_status_open()
In case of sshd process, /sys/fs/selinux/status seems to be mapped by
selinux_check_access() which is called from pam_selinux and it's left
open as there's no selinux_status_close() in selinux_check_access().
The similar situations probably happen in systemd and dbus.
So is it expected? Is it a bug? Do we need to change other components so
that they would call selinux_status_close() when they use check access?
Petr
^ permalink raw reply [flat|nested] 5+ messages in thread* Re: can't unmount /sys/fs/selinux 2021-01-13 21:44 can't unmount /sys/fs/selinux Petr Lautrbach @ 2021-01-13 22:09 ` Stephen Smalley 2021-01-13 22:56 ` Petr Lautrbach 0 siblings, 1 reply; 5+ messages in thread From: Stephen Smalley @ 2021-01-13 22:09 UTC (permalink / raw) To: Petr Lautrbach; +Cc: SElinux list On Wed, Jan 13, 2021 at 4:52 PM Petr Lautrbach <plautrba@redhat.com> wrote: > > Hi, > > we have few tests which uses `umount /sys/fs/selinux` trick to check how > userspace works in SELinux "disabled" environment. But it's not possible > with the current master: > > # umount /sys/fs/selinux > umount: /sys/fs/selinux: target is busy. > > # lsof /sys/fs/selinux > COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME > systemd 1 root mem REG 0,21 0 19 /sys/fs/selinux/status > systemd 1 root 55r REG 0,21 0 19 /sys/fs/selinux/status > systemd-u 875 root mem REG 0,21 0 19 /sys/fs/selinux/status > systemd-u 875 root 6r REG 0,21 0 19 /sys/fs/selinux/status > dbus-brok 1116 dbus mem REG 0,21 0 19 /sys/fs/selinux/status > dbus-brok 1116 dbus 5r REG 0,21 0 19 /sys/fs/selinux/status > systemd-l 1134 root mem REG 0,21 0 19 /sys/fs/selinux/status > systemd-l 1134 root 4r REG 0,21 0 19 /sys/fs/selinux/status > systemd 1643 root mem REG 0,21 0 19 /sys/fs/selinux/status > systemd 1643 root 28r REG 0,21 0 19 /sys/fs/selinux/status > (sd-pam) 1645 root mem REG 0,21 0 19 /sys/fs/selinux/status > ... > sshd 218874 root mem REG 0,21 0 19 /sys/fs/selinux/status > sshd 218874 root 3r REG 0,21 0 19 /sys/fs/selinux/status > sshd 218880 plautrba mem REG 0,21 0 19 /sys/fs/selinux/status > sshd 218880 plautrba 3r REG 0,21 0 19 /sys/fs/selinux/status > > It seems to be caused by commit 05bdc03130d7 ("libselinux: use kernel > status page by default") which replaced avc_netlink_open() in > avc_init_internal() with selinux_status_open() > > In case of sshd process, /sys/fs/selinux/status seems to be mapped by > selinux_check_access() which is called from pam_selinux and it's left > open as there's no selinux_status_close() in selinux_check_access(). > The similar situations probably happen in systemd and dbus. > > So is it expected? Is it a bug? Do we need to change other components so > that they would call selinux_status_close() when they use check access? What if we just close the fd after mmap and not keep it open? I don't see any use of selinux_status_fd beyond assignment and closing. Tearing down the mapping and re-creating it on every access check would defeat the purpose. ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: can't unmount /sys/fs/selinux 2021-01-13 22:09 ` Stephen Smalley @ 2021-01-13 22:56 ` Petr Lautrbach 2021-01-14 14:21 ` Petr Lautrbach 0 siblings, 1 reply; 5+ messages in thread From: Petr Lautrbach @ 2021-01-13 22:56 UTC (permalink / raw) To: SElinux list; +Cc: Stephen Smalley Stephen Smalley <stephen.smalley.work@gmail.com> writes: > On Wed, Jan 13, 2021 at 4:52 PM Petr Lautrbach <plautrba@redhat.com> wrote: >> >> Hi, >> >> we have few tests which uses `umount /sys/fs/selinux` trick to check how >> userspace works in SELinux "disabled" environment. But it's not possible >> with the current master: >> >> # umount /sys/fs/selinux >> umount: /sys/fs/selinux: target is busy. >> >> # lsof /sys/fs/selinux >> COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME >> systemd 1 root mem REG 0,21 0 19 /sys/fs/selinux/status >> systemd 1 root 55r REG 0,21 0 19 /sys/fs/selinux/status >> systemd-u 875 root mem REG 0,21 0 19 /sys/fs/selinux/status >> systemd-u 875 root 6r REG 0,21 0 19 /sys/fs/selinux/status >> dbus-brok 1116 dbus mem REG 0,21 0 19 /sys/fs/selinux/status >> dbus-brok 1116 dbus 5r REG 0,21 0 19 /sys/fs/selinux/status >> systemd-l 1134 root mem REG 0,21 0 19 /sys/fs/selinux/status >> systemd-l 1134 root 4r REG 0,21 0 19 /sys/fs/selinux/status >> systemd 1643 root mem REG 0,21 0 19 /sys/fs/selinux/status >> systemd 1643 root 28r REG 0,21 0 19 /sys/fs/selinux/status >> (sd-pam) 1645 root mem REG 0,21 0 19 /sys/fs/selinux/status >> ... >> sshd 218874 root mem REG 0,21 0 19 /sys/fs/selinux/status >> sshd 218874 root 3r REG 0,21 0 19 /sys/fs/selinux/status >> sshd 218880 plautrba mem REG 0,21 0 19 /sys/fs/selinux/status >> sshd 218880 plautrba 3r REG 0,21 0 19 /sys/fs/selinux/status >> >> It seems to be caused by commit 05bdc03130d7 ("libselinux: use kernel >> status page by default") which replaced avc_netlink_open() in >> avc_init_internal() with selinux_status_open() >> >> In case of sshd process, /sys/fs/selinux/status seems to be mapped by >> selinux_check_access() which is called from pam_selinux and it's left >> open as there's no selinux_status_close() in selinux_check_access(). >> The similar situations probably happen in systemd and dbus. >> >> So is it expected? Is it a bug? Do we need to change other components so >> that they would call selinux_status_close() when they use check access? > > What if we just close the fd after mmap and not keep it open? I don't > see any use of selinux_status_fd beyond assignment and closing. > Tearing down the mapping and re-creating it on every access check > would defeat the purpose. Thanks for this hint! I've checked mmap(2) and it's there: After the mmap() call has returned, the file descriptor, fd, can be closed immediately without invalidating the mapping. I'll try it tomorrow. ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: can't unmount /sys/fs/selinux 2021-01-13 22:56 ` Petr Lautrbach @ 2021-01-14 14:21 ` Petr Lautrbach 2021-01-14 16:24 ` Stephen Smalley 0 siblings, 1 reply; 5+ messages in thread From: Petr Lautrbach @ 2021-01-14 14:21 UTC (permalink / raw) To: SElinux list; +Cc: Stephen Smalley Petr Lautrbach <plautrba@redhat.com> writes: > Stephen Smalley <stephen.smalley.work@gmail.com> writes: > >> On Wed, Jan 13, 2021 at 4:52 PM Petr Lautrbach <plautrba@redhat.com> wrote: >>> >>> Hi, >>> >>> we have few tests which uses `umount /sys/fs/selinux` trick to check how >>> userspace works in SELinux "disabled" environment. But it's not possible >>> with the current master: >>> >>> # umount /sys/fs/selinux >>> umount: /sys/fs/selinux: target is busy. >>> >>> # lsof /sys/fs/selinux >>> COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME >>> systemd 1 root mem REG 0,21 0 19 /sys/fs/selinux/status >>> systemd 1 root 55r REG 0,21 0 19 /sys/fs/selinux/status >>> systemd-u 875 root mem REG 0,21 0 19 /sys/fs/selinux/status >>> systemd-u 875 root 6r REG 0,21 0 19 /sys/fs/selinux/status >>> dbus-brok 1116 dbus mem REG 0,21 0 19 /sys/fs/selinux/status >>> dbus-brok 1116 dbus 5r REG 0,21 0 19 /sys/fs/selinux/status >>> systemd-l 1134 root mem REG 0,21 0 19 /sys/fs/selinux/status >>> systemd-l 1134 root 4r REG 0,21 0 19 /sys/fs/selinux/status >>> systemd 1643 root mem REG 0,21 0 19 /sys/fs/selinux/status >>> systemd 1643 root 28r REG 0,21 0 19 /sys/fs/selinux/status >>> (sd-pam) 1645 root mem REG 0,21 0 19 /sys/fs/selinux/status >>> ... >>> sshd 218874 root mem REG 0,21 0 19 /sys/fs/selinux/status >>> sshd 218874 root 3r REG 0,21 0 19 /sys/fs/selinux/status >>> sshd 218880 plautrba mem REG 0,21 0 19 /sys/fs/selinux/status >>> sshd 218880 plautrba 3r REG 0,21 0 19 /sys/fs/selinux/status >>> >>> It seems to be caused by commit 05bdc03130d7 ("libselinux: use kernel >>> status page by default") which replaced avc_netlink_open() in >>> avc_init_internal() with selinux_status_open() >>> >>> In case of sshd process, /sys/fs/selinux/status seems to be mapped by >>> selinux_check_access() which is called from pam_selinux and it's left >>> open as there's no selinux_status_close() in selinux_check_access(). >>> The similar situations probably happen in systemd and dbus. >>> >>> So is it expected? Is it a bug? Do we need to change other components so >>> that they would call selinux_status_close() when they use check access? >> >> What if we just close the fd after mmap and not keep it open? I don't >> see any use of selinux_status_fd beyond assignment and closing. >> Tearing down the mapping and re-creating it on every access check >> would defeat the purpose. > > Thanks for this hint! I've checked mmap(2) and it's there: After the > mmap() call has returned, the file descriptor, fd, can be closed > immediately without invalidating the mapping. > > I'll try it tomorrow. https://patchwork.kernel.org/project/selinux/patch/20210114133910.282686-1-plautrba@redhat.com/ With this patch fd's are closed but the mapped memory is still there: # umount /sys/fs/selinux umount: /sys/fs/selinux: target is busy. # lsof /sys/fs/selinux COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME systemd 1 root mem REG 0,21 0 19 /sys/fs/selinux/status systemd-u 363 root mem REG 0,21 0 19 /sys/fs/selinux/status systemd-r 393 systemd-resolve mem REG 0,21 0 19 /sys/fs/selinux/status dbus-brok 432 dbus mem REG 0,21 0 19 /sys/fs/selinux/status ... For now we have a workaround for our tests - `umount -l /sys/fs/selinux` works. But we should document the side effect of selinux status page change in release notes if there's no better solution. Petr ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: can't unmount /sys/fs/selinux 2021-01-14 14:21 ` Petr Lautrbach @ 2021-01-14 16:24 ` Stephen Smalley 0 siblings, 0 replies; 5+ messages in thread From: Stephen Smalley @ 2021-01-14 16:24 UTC (permalink / raw) To: Petr Lautrbach, Ondrej Mosnacek, Paul Moore; +Cc: SElinux list On Thu, Jan 14, 2021 at 9:22 AM Petr Lautrbach <plautrba@redhat.com> wrote: > > Petr Lautrbach <plautrba@redhat.com> writes: > > > Stephen Smalley <stephen.smalley.work@gmail.com> writes: > > > >> On Wed, Jan 13, 2021 at 4:52 PM Petr Lautrbach <plautrba@redhat.com> wrote: > >>> > >>> Hi, > >>> > >>> we have few tests which uses `umount /sys/fs/selinux` trick to check how > >>> userspace works in SELinux "disabled" environment. But it's not possible > >>> with the current master: > >>> > >>> # umount /sys/fs/selinux > >>> umount: /sys/fs/selinux: target is busy. > >>> > >>> # lsof /sys/fs/selinux > >>> COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME > >>> systemd 1 root mem REG 0,21 0 19 /sys/fs/selinux/status > >>> systemd 1 root 55r REG 0,21 0 19 /sys/fs/selinux/status > >>> systemd-u 875 root mem REG 0,21 0 19 /sys/fs/selinux/status > >>> systemd-u 875 root 6r REG 0,21 0 19 /sys/fs/selinux/status > >>> dbus-brok 1116 dbus mem REG 0,21 0 19 /sys/fs/selinux/status > >>> dbus-brok 1116 dbus 5r REG 0,21 0 19 /sys/fs/selinux/status > >>> systemd-l 1134 root mem REG 0,21 0 19 /sys/fs/selinux/status > >>> systemd-l 1134 root 4r REG 0,21 0 19 /sys/fs/selinux/status > >>> systemd 1643 root mem REG 0,21 0 19 /sys/fs/selinux/status > >>> systemd 1643 root 28r REG 0,21 0 19 /sys/fs/selinux/status > >>> (sd-pam) 1645 root mem REG 0,21 0 19 /sys/fs/selinux/status > >>> ... > >>> sshd 218874 root mem REG 0,21 0 19 /sys/fs/selinux/status > >>> sshd 218874 root 3r REG 0,21 0 19 /sys/fs/selinux/status > >>> sshd 218880 plautrba mem REG 0,21 0 19 /sys/fs/selinux/status > >>> sshd 218880 plautrba 3r REG 0,21 0 19 /sys/fs/selinux/status > >>> > >>> It seems to be caused by commit 05bdc03130d7 ("libselinux: use kernel > >>> status page by default") which replaced avc_netlink_open() in > >>> avc_init_internal() with selinux_status_open() > >>> > >>> In case of sshd process, /sys/fs/selinux/status seems to be mapped by > >>> selinux_check_access() which is called from pam_selinux and it's left > >>> open as there's no selinux_status_close() in selinux_check_access(). > >>> The similar situations probably happen in systemd and dbus. > >>> > >>> So is it expected? Is it a bug? Do we need to change other components so > >>> that they would call selinux_status_close() when they use check access? > >> > >> What if we just close the fd after mmap and not keep it open? I don't > >> see any use of selinux_status_fd beyond assignment and closing. > >> Tearing down the mapping and re-creating it on every access check > >> would defeat the purpose. > > > > Thanks for this hint! I've checked mmap(2) and it's there: After the > > mmap() call has returned, the file descriptor, fd, can be closed > > immediately without invalidating the mapping. > > > > I'll try it tomorrow. > > https://patchwork.kernel.org/project/selinux/patch/20210114133910.282686-1-plautrba@redhat.com/ > > With this patch fd's are closed but the mapped memory is still there: > > # umount /sys/fs/selinux > umount: /sys/fs/selinux: target is busy. > > # lsof /sys/fs/selinux > COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME > systemd 1 root mem REG 0,21 0 19 /sys/fs/selinux/status > systemd-u 363 root mem REG 0,21 0 19 /sys/fs/selinux/status > systemd-r 393 systemd-resolve mem REG 0,21 0 19 /sys/fs/selinux/status > dbus-brok 432 dbus mem REG 0,21 0 19 /sys/fs/selinux/status > ... > > > For now we have a workaround for our tests - `umount -l /sys/fs/selinux` works. > > But we should document the side effect of selinux status page change in > release notes if there's no better solution. Is this a problem for clean shutdown/reboot as well or does that already use lazy unmount? Keeping the status page mapped is by design to avoid needing to perform system calls each time to check enforcing status, policy seqno, etc. ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2021-01-14 16:25 UTC | newest] Thread overview: 5+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2021-01-13 21:44 can't unmount /sys/fs/selinux Petr Lautrbach 2021-01-13 22:09 ` Stephen Smalley 2021-01-13 22:56 ` Petr Lautrbach 2021-01-14 14:21 ` Petr Lautrbach 2021-01-14 16:24 ` Stephen Smalley
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.