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
