Re: can't unmount /sys/fs/selinux

[Petr Lautrbach <plautrba@redhat.com>]

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