Re: Allow ioctl TUNSETIFF without CAP_NET_ADMIN via seccomp?

[Zach Walton]

Thanks, I think this might have been a misunderstanding on my part;
seccomp is meant to restrict, not expand, permissions. I spent some
time looking for prior art and see nothing like it.

I will look into alternatives like AppArmor/eBPF. Appreciate the response.

On Tue, Sep 17, 2024 at 1:45 AM Willem de Bruijn
<willemdebruijn.kernel@xxxxxxxxx> wrote:
>
> Zach Walton wrote:
> > I was debugging a seccomp profile that attempts to allow TUNSETIFF in
> > a container, relevant bits:
> >
> > ...
> >       {
> >             "names":[
> >                   "ioctl"
> >             ],
> >             "action":"SCMP_ACT_ALLOW",
> >             "args":[
> >                   {
> >                         "index":1,
> >                         "value":1074025674,
> >                         "op":"SCMP_CMP_EQ"
> >                   },
> >                   {
> >                         "index":1,
> >                         "value":2147767498,
> >                         "op":"SCMP_CMP_EQ"
> >                   }
> >             ]
> >       },
> > ...
> >
> > ...but I get:
> >
> > Tuntap IOCTL TUNSETIFF failed [0], errno operation not permitted
> >
> > Looking at the code, it seems that there's an explicit check for
> > CAP_NET_ADMIN, which I'd prefer not to grant the container because the
> > permissions are excessive (yes, I can lock it down with seccomp but
> > still...): https://github.com/torvalds/linux/blob/3352633ce6b221d64bf40644d412d9670e7d56e3/drivers/net/tun.c#L2758-L2759
> >
> > Is it possible to update this check to allow TUNSETIFF operations if a
> > seccomp profile allowing it is in place? (I am not a kernel developer
> > and it's unlikely I could safely contribute this)
>
> In this case seccomp would not restrict capabilities, but actually
> expand them, by bypassing the standard CAP_NET_ADMIN requirement.
>
> That sounds like it might complicate reasoning about seccomp.
>
> Is there prior art, where kernel restrictions are actually relaxed
> when relying on a privileged process allow a privileged operation
> through a seccomp policy?
>