netdev - Re: [PATCH] selinux: map RTM_DELNSID to nlmsg

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAHC9VhTFBPG2Ai7zT80m=Ez7RRN5J+1rA+n=q4SrAjrVvs+Dpw@mail.gmail.com>
Date: Wed, 15 Jan 2025 12:29:00 -0500
From: Paul Moore <paul@...l-moore.com>
To: Thiébaud Weksteen <tweek@...gle.com>, 
	nicolas.dichtel@...nd.com
Cc: "David S . Miller" <davem@...emloft.net>, selinux@...r.kernel.org, 
	netdev <netdev@...r.kernel.org>
Subject: Re: [PATCH] selinux: map RTM_DELNSID to nlmsg_write

On Thu, Jan 9, 2025 at 4:24 AM Nicolas Dichtel
<nicolas.dichtel@...nd.com> wrote:
> Le 09/01/2025 à 00:15, Thiébaud Weksteen a écrit :
> >
> > The mapping for RTM_DELNSID was added in commit 387f989a60db
> > ("selinux/nlmsg: add RTM_GETNSID"). While this message type is not
> > expected from userspace, other RTM_DEL* types are mapped to the more
> > restrictive nlmsg_write permission. Move RTM_DELNSID to nlmsg_write in
> > case the implementation is changed in the future.
>
> Frankly, I don't think this will ever change. It's not a problem of implementing
> the delete command, it's conceptually no sense.
>
> I don't see why the DEL should be restricted in any way.

While the RTM_DELNSID messages are not generated from userspace, the
presence of the SELinux access control point is visible to userspace
and thus we have to worry about the backwards compatibility impact of
changing a "read" operation to a "write" operation.

We could likely have a discussion about which is a better permission
mapping for RTM_DELNSID, read or write, but ultimately I think this
should probably be treated as a read operation since the kernel is
using this simply as a notification message.  Sending, or receiving, a
RTM_DELNSID message doesn't affect the state of the netns ID, or the
netns itself; in other words, a RTM_DELNSID is not the cause of netns
state change, it is a notification artifact of such a change.  Leaving
this mapped as a "read" operation seems correct to me.

It is also worth noting that the SELinux netlink xperms support that
will ship for the first time in v6.13 will allow policy developers to
target RTM_DELNSID messages with much greater permissions granularity,
largely solving this problem for those who care about it.

Finally, looking at unhash_nsid(), the only place which seems to
generate RTM_DELNSID notification messages, an access control denial
on the netlink notification operation will have no impact on the
removal of the netns or the netns ID, only the notification itself
should be impacted.

-- 
paul-moore.com