On Mon, Jul 22, 2024 at 2:21 AM Thiébaud Weksteen <tweek@xxxxxxxxxx> wrote:
>
> > > > > Reuse the existing extended permissions infrastructure to support
> > > > > sepolicy for different netlink message types.
>
> (Following up on this patch).
>
> > > > >
> > > > > When individual netlink message types are omitted only the existing
> > > > > permissions are checked. As is the case for ioctl xperms, this feature
> > > > > is intended to provide finer granularity for nlmsg_read and nlmsg_write
> > > > > permissions, as they may be too imprecise. For example, a single
> > > > > NETLINK_ROUTE socket may provide access to both an interface's IP
> > > > > address and to its ARP table, which might have different privacy
> > > > > implications. In addition, the set of message types has grown over time,
> > > > > so even if the current list is acceptable, future additions might not be.
> > > > > It was suggested before on the mailing list [1] that extended permissions
> > > > > would be a good fit for this purpose.
> > > > >
> > > > > Existing policy using the nlmsg_read and nlmsg_write permissions will
> > > > > continue to work as-is. Similar to ioctl xperms, netlink xperms allow
> > > > > for a more fine-grained policy where needed.
> > > > >
> > > > > 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_read
> > > > > };
> > > > > 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
> > > > > };
> > > > >
> > > > > Android currently uses code similar to [1] as a temporary workaround to
> > > > > limit access to certain netlink message types; our hope is that this patch
> > > > > will allow us to move back to upstream code with an approach that works for
> > > > > everyone.
> > > > >
> > > > > [1] https://lore.kernel.org/selinux/CAHC9VhRSUhozBycHMZcMaJsibJDxNMsTsKVT2zOnW=5H4R4mdg@xxxxxxxxxxxxxx/
> > > > >
> > > > > Signed-off-by: Bram Bonne <brambonne@xxxxxxxxxx>
> > > > > ---
> > > > > security/selinux/hooks.c | 24 +++++++++++++++++++++++-
> > > > > security/selinux/ss/avtab.h | 1 +
> > > > > security/selinux/ss/services.c | 23 ++++++++++++++++++++++-
> > > > > 3 files changed, 46 insertions(+), 2 deletions(-)
> > > > >
> > > > > diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c
> > > > > index e7ebd45ca345..a503865fabed 100644
> > > > > --- a/security/selinux/hooks.c
> > > > > +++ b/security/selinux/hooks.c
> > > > > @@ -4662,6 +4662,28 @@ static int sock_has_perm(struct sock *sk, u32 perms)
> > > > > &ad);
> > > > > }
> > > > >
> > > > > +static int nlmsg_sock_has_extended_perms(struct sock *sk, u32 perms, u16 nlmsg_type)
> > > > > +{
> > > > > + struct sk_security_struct *sksec = sk->sk_security;
> > > > > + struct common_audit_data ad;
> > > > > + struct lsm_network_audit net = {0,};
> > > > > + u8 xperm;
> > > > > +
> > > > > + if (sksec->sid == SECINITSID_KERNEL)
> > > > > + return 0;
> > > > > +
> > > > > + ad.type = LSM_AUDIT_DATA_NET;
> > > > > + ad.u.net = &net;
> > > > > + ad.u.net->sk = sk;
> > > > > +
> > > > > + // nlmsg_types comfortably fit into a single driver, see RTM_MAX in uapi/linux/rtnetlink.h
> > > > > + xperm = nlmsg_type & 0xff;
> > > >
> > > > This seems like a dangerous assumption; obviously not all netlink
> > > > users are rtnetlink. Even if all existing netlink users follow this,
> > > > nothing prevents userspace from creating a netlink message that
> > > > violates it AFAIK, at which point you will just silently discard the
> > > > higher bits. If we think we can get away with this restriction, then
> > > > we need to enforce it here (i.e. return an error if they do not fit);
> > > > if not,
> > > > then we likely need to support multiple drivers with a simple mapping
> > > > of the upper bits to driver.
>
> Agreed. Mapping the upper bits to the driver field would work.
>
> In this case, AVTAB_XPERMS_NLMSG proposed here would have the exact same
> implementation as AVTAB_XPERMS_IOCTLFUNCTION. An option could be to rename the
> AVTAB_XPERMS_IOCTLFUNCTION constant (for example, to AVTAB_XPERMS_PERMS, and
> similarly moving AVTAB_XPERMS_IOCTLDRIVER to AVTAB_XPERMS_DRIVER). This is
> describing more how struct avtab_extended_perms is being used rather than
> focusing on its original meaning. (That is, the driver and perms fields are
> historically related to ioctl, but they have their own meanings in the xperm
> implementation).
>
> The alternative is simply to have that new constant (AVTAB_XPERMS_NLMSG, maybe
> renamed to AVTAB_XPERMS_NETLINK_MSGTYPE, to be more explicit?).
Considering that the original patch is almost three years old at this
point, if you're interested in picking up this work I'd suggest
starting by picking one of the options above that you like the most
and preparing a patch(set) that works on the current development
trees. At this point all I remember about this patchset is that it
existed. If I'm going to spend the time to go back and re-review
something, I'd rather it be a bit more recent than three years ;)
> > > Looks like generic netlink puts the family id into the message type
> > > field, with the actual command in the separate generic netlink header
> > > in the payload. generic netlink family ids appear to be dynamically
> > > allocated, with GENL_MAX_ID defined as 1023. genl-ctrl-list on a
> > > sample Linux system reports ids from 0x10 through 0x1f so those would
> > > fit but there isn't anything in the code to prevent higher ids from
> > > being allocated up to the max. And if someday you want to be able to
> > > filter generic netlink messages at the per-command level, you'd
> > > further need to deal with the separate cmd field.
> >
> > There is also NETLINK_AUDIT which currently has message types defined
> > up to 2000. The netlink message header format allows for 16 bit
> > message types (look at the nlmsghdr struct) and I think it would be a
> > mistake if the SELinux netlink/xperms code didn't support a full 16
> > bits for the message type.
> >
> > As far as NETLINK_GENERIC is concerned, yes, that's a bit of a
> > nuisance both with the dynamic family IDs and buried message types.
> > On the plus side, there are existing kernel functions that will
> > resolve the generic netlink family IDs to a genl_family struct but
> > those are currently private to the generic netlink code; I imagine if
> > there was a need those functions (or something similar) could be made
> > available outside of the genetlink.c. Once you've matched on
> > NETLINK_GENERIC and done the family resolution, it should just be a
> > matter of doing the generic netlink command lookup in the context of
> > the family, which really shouldn't be much different than looking up
> > the message type of a conventional netlink message.
>
> I can see how the resolution for cmd can be done, but I am not sure how the
> family should be handled. I don't think it is ok to not correlate the family to
> some data in the policy.
Yes, the family needs to be represented in the policy and using
precedence as a guide I would suggest encoding the netlink family
types as object classes. You'll need a generic netlink "default" for
those generic netlink families that aren't explicitly defined, but
that shouldn't be too hard to implement.
--
paul-moore.com
