On Thu, Jan 14, 2021 at 9:22 AM Petr Lautrbach <plautrba@xxxxxxxxxx> wrote:
>
> Petr Lautrbach <plautrba@xxxxxxxxxx> writes:
>
> > Stephen Smalley <stephen.smalley.work@xxxxxxxxx> writes:
> >
> >> On Wed, Jan 13, 2021 at 4:52 PM Petr Lautrbach <plautrba@xxxxxxxxxx> 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@xxxxxxxxxx/
>
> 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.
