diff mbox series

selinux: map RTM_DELNSID to nlmsg_write

Message ID 20250108231554.3634987-1-tweek@google.com (mailing list archive)
State Rejected
Delegated to: Paul Moore
Headers show
Series selinux: map RTM_DELNSID to nlmsg_write | expand

Commit Message

Thiébaud Weksteen Jan. 8, 2025, 11:15 p.m. UTC
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.

Fixes: 387f989a60db ("selinux/nlmsg: add RTM_GETNSID")
Signed-off-by: Thiébaud Weksteen <tweek@google.com>
---
 security/selinux/nlmsgtab.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Comments

Nicolas Dichtel Jan. 9, 2025, 9:24 a.m. UTC | #1
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.


Regards,
Nicolas

> 
> Fixes: 387f989a60db ("selinux/nlmsg: add RTM_GETNSID")
> Signed-off-by: Thiébaud Weksteen <tweek@google.com>
> ---
>  security/selinux/nlmsgtab.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/security/selinux/nlmsgtab.c b/security/selinux/nlmsgtab.c
> index 3a95986b134f..f97e75301018 100644
> --- a/security/selinux/nlmsgtab.c
> +++ b/security/selinux/nlmsgtab.c
> @@ -71,7 +71,7 @@ static const struct nlmsg_perm nlmsg_route_perms[] = {
>  	{ RTM_DELMDB, NETLINK_ROUTE_SOCKET__NLMSG_WRITE },
>  	{ RTM_GETMDB, NETLINK_ROUTE_SOCKET__NLMSG_READ },
>  	{ RTM_NEWNSID, NETLINK_ROUTE_SOCKET__NLMSG_WRITE },
> -	{ RTM_DELNSID, NETLINK_ROUTE_SOCKET__NLMSG_READ },
> +	{ RTM_DELNSID, NETLINK_ROUTE_SOCKET__NLMSG_WRITE },
>  	{ RTM_GETNSID, NETLINK_ROUTE_SOCKET__NLMSG_READ },
>  	{ RTM_NEWSTATS, NETLINK_ROUTE_SOCKET__NLMSG_READ },
>  	{ RTM_GETSTATS, NETLINK_ROUTE_SOCKET__NLMSG_READ },
Paul Moore Jan. 15, 2025, 5:29 p.m. UTC | #2
On Thu, Jan 9, 2025 at 4:24 AM Nicolas Dichtel
<nicolas.dichtel@6wind.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.
diff mbox series

Patch

diff --git a/security/selinux/nlmsgtab.c b/security/selinux/nlmsgtab.c
index 3a95986b134f..f97e75301018 100644
--- a/security/selinux/nlmsgtab.c
+++ b/security/selinux/nlmsgtab.c
@@ -71,7 +71,7 @@  static const struct nlmsg_perm nlmsg_route_perms[] = {
 	{ RTM_DELMDB, NETLINK_ROUTE_SOCKET__NLMSG_WRITE },
 	{ RTM_GETMDB, NETLINK_ROUTE_SOCKET__NLMSG_READ },
 	{ RTM_NEWNSID, NETLINK_ROUTE_SOCKET__NLMSG_WRITE },
-	{ RTM_DELNSID, NETLINK_ROUTE_SOCKET__NLMSG_READ },
+	{ RTM_DELNSID, NETLINK_ROUTE_SOCKET__NLMSG_WRITE },
 	{ RTM_GETNSID, NETLINK_ROUTE_SOCKET__NLMSG_READ },
 	{ RTM_NEWSTATS, NETLINK_ROUTE_SOCKET__NLMSG_READ },
 	{ RTM_GETSTATS, NETLINK_ROUTE_SOCKET__NLMSG_READ },