Re: [PATCH] security/landlock: use square brackets around "landlock-ruleset"
From: Ondrej Mosnacek <omosnace@redhat.com>
Date: 2021-10-12 20:38:51
Also in:
selinux
On Tue, Oct 12, 2021 at 8:12 PM Paul Moore [off-list ref] wrote:
On Tue, Oct 12, 2021 at 6:38 AM Christian Brauner [off-list ref] wrote:quoted
On Mon, Oct 11, 2021 at 04:38:55PM +0200, Mickaël Salaün wrote:quoted
On 11/10/2021 15:37, Christian Brauner wrote:quoted
From: Christian Brauner <redacted> Make the name of the anon inode fd "[landlock-ruleset]" instead of "landlock-ruleset". This is minor but most anon inode fds already carry square brackets around their name: [eventfd] [eventpoll] [fanotify] [fscontext] [io_uring] [pidfd] [signalfd] [timerfd] [userfaultfd] For the sake of consistency lets do the same for the landlock-ruleset anon inode fd that comes with landlock. We did the same in 1cdc415f1083 ("uapi, fsopen: use square brackets around "fscontext" [ver #2]") for the new mount api.Before creating "landlock-ruleset" FD, I looked at other anonymous FD and saw this kind of inconsistency. I don't get why we need to add extra characters to names, those brackets seem useless. If it should be partPast inconsistency shouldn't justify future inconsistency. If you have a strong opinion about this for landlock I'm not going to push for it. Exchanging more than 2-3 email about something like this seems too much.[NOTE: adding the SELinux list as well as Chris (SELinux refrence policy maintainer) and Petr (Fedora/RHEL SELinux)] Chris and Petr, do either of you currently have any policy that references the "landlock-ruleset" anonymous inode? In other words, would adding the brackets around the name cause you any problems?
AFAIU, the anon_inode transitions (the only mechanism where the "file name" would be exposed to the policy) are done only for inodes created by anon_inode_getfd_secure(), which is currently only used by userfaultfd. So you don't even need to ask that question; at this point it should be safe to change any of the names except "[userfaultfd]" as far as SELinux policy is concerned. -- Ondrej Mosnacek Software Engineer, Linux Security - SELinux kernel Red Hat, Inc.