On Thu, Jan 16, 2025 at 4:29 AM Paul Moore <paul@xxxxxxxxxxxxxx> wrote:
>
> On Thu, Jan 9, 2025 at 4:24 AM Nicolas Dichtel
> <nicolas.dichtel@xxxxxxxxx> 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.
