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] [day] [month] [year] [list]

Message-ID: <CA+zpnLe5X3jcjF2=A72Bgpxt7wDrSgK0Y29h42mttTDr6vk9NA@mail.gmail.com>
Date: Thu, 16 Jan 2025 08:55:41 +1100
From: Thiébaud Weksteen <tweek@...gle.com>
To: Paul Moore <paul@...l-moore.com>
Cc: nicolas.dichtel@...nd.com, "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 16, 2025 at 4:29 AM Paul Moore <paul@...l-moore.com> wrote:
>
> 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.

Ack. No worries. I agree with you Paul. When I was going through the
list for updating our policy, this entry stood out as the only DEL_
mapped to nlmsg_read. But as you described, it makes little sense to
move it now. Thanks for the review.