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.
--
paul-moore.com
