From: Petr Lautrbach <plautrba@redhat.com>
To: SElinux list <selinux@vger.kernel.org>
Cc: Stephen Smalley <stephen.smalley.work@gmail.com>
Subject: Re: can't unmount /sys/fs/selinux
Date: Wed, 13 Jan 2021 23:56:46 +0100 [thread overview]
Message-ID: <87k0sga1jl.fsf@redhat.com> (raw)
In-Reply-To: <CAEjxPJ6jqHX+bSwLoKratsBD47_WNAoQ4OQQN9yWcMzTRoMbzA@mail.gmail.com>
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.
next prev parent reply other threads:[~2021-01-13 23:40 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
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 [this message]
2021-01-14 14:21 ` Petr Lautrbach
2021-01-14 16:24 ` Stephen Smalley
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87k0sga1jl.fsf@redhat.com \
--to=plautrba@redhat.com \
--cc=selinux@vger.kernel.org \
--cc=stephen.smalley.work@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).