On Mon, Sep 16, 2024 at 8:02 AM Paul Moore <paul@xxxxxxxxxxxxxx> wrote: > On Sep 11, 2024 "=?UTF-8?q?Thi=C3=A9baud=20Weksteen?=" <tweek@xxxxxxxxxx> wrote: > > > > Reuse the existing extended permissions infrastructure to support > > policies based on the netlink message types. > > > > A new policy capability "netlink_xperm" is introduced. When disabled, > > the previous behaviour is preserved. That is, netlink_send will rely on > > the permission mappings defined in nlmsgtab.c (e.g, nlmsg_read for > > RTM_GETADDR on NETLINK_ROUTE). When enabled, the mappings are ignored > > and the generic "nlmsg" permission is used instead. > > > > The new "nlmsg" permission is an extended permission. The 16 bits of the > > extended permission are mapped to the nlmsg_type field. > > > > Example policy on Android, preventing regular apps from accessing the > > device's MAC address and ARP table, but allowing this access to > > privileged apps, looks as follows: > > > > allow netdomain self:netlink_route_socket { > > create read getattr write setattr lock append connect getopt > > setopt shutdown nlmsg > > }; > > allowxperm netdomain self:netlink_route_socket nlmsg ~{ > > RTM_GETLINK RTM_GETNEIGH RTM_GETNEIGHTBL > > }; > > allowxperm priv_app self:netlink_route_socket nlmsg { > > RTM_GETLINK RTM_GETNEIGH RTM_GETNEIGHTBL > > }; > > > > The constants in the example above (e.g., RTM_GETLINK) are explicitly > > defined in the policy. > > > > It is possible to generate policies to support kernels that may or > > may not have the capability enabled by generating a rule for each > > scenario. For instance: > > > > allow domain self:netlink_audit_socket nlmsg_read; > > allow domain self:netlink_audit_socket nlmsg; > > allowxperm domain self:netlink_audit_socket nlmsg { AUDIT_GET }; > > > > The approach of defining a new permission ("nlmsg") instead of relying > > on the existing permissions (e.g., "nlmsg_read", "nlmsg_readpriv" or > > "nlmsg_tty_audit") has been preferred because: > > 1. This is similar to the other extended permission ("ioctl"); > > 2. With the new extended permission, the coarse-grained mapping is not > > necessary anymore. It could eventually be removed, which would be > > impossible if the extended permission was defined below these. > > 3. Having a single extra extended permission considerably simplifies > > the implementation here and in libselinux. > > > > Signed-off-by: Thiébaud Weksteen <tweek@xxxxxxxxxx> > > Signed-off-by: Bram Bonné <brambonne@xxxxxxxxxx> > > --- > > v3: > > - Remove condition on SECCLASS_NETLINK_GENERIC_SOCKET in > > selinux_netlink_send. > > - Remove comment in selinux_netlink_send. > > - Add comment in selinux_nlmsg_lookup. > > - Update commit message. > > v2: Reorder classmap.h to keep the new permission "nlmsg" at the end. > > > > security/selinux/hooks.c | 51 +++++++++++--- > > security/selinux/include/classmap.h | 8 +-- > > security/selinux/include/policycap.h | 1 + > > security/selinux/include/policycap_names.h | 1 + > > security/selinux/include/security.h | 6 ++ > > security/selinux/nlmsgtab.c | 27 ++++++++ > > security/selinux/ss/avtab.h | 5 +- > > security/selinux/ss/services.c | 78 ++++++++++++---------- > > 8 files changed, 126 insertions(+), 51 deletions(-) > > Looks good to me, thanks for the revision. We're in the merge window > right now so I'm going to merge this into selinux/dev-staging now and > I'll move it into selinux/dev after -rc1 is released. Thanks for your patience, I just merged this into selinux/dev, you should see it upstream shortly. -- paul-moore.com