Allow ioctl TUNSETIFF without CAP_NET_ADMIN via seccomp?

Allow ioctl TUNSETIFF without CAP_NET_ADMIN via seccomp?

[Zach Walton]

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)

Re: Allow ioctl TUNSETIFF without CAP_NET_ADMIN via seccomp?

[Willem de Bruijn]

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?

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@gmail.com> 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?
>

Re: Allow ioctl TUNSETIFF without CAP_NET_ADMIN via seccomp?

[Stanislav Fomichev]

On 09/17, Zach Walton wrote:
> 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.

There is a bit of "expand capabilities" prior art in the bind cgroup hooks:
https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next.git/tree/include/linux/bpf.h#n2075

The BPF program can return special value to ask kernel to not apply
CAP_NET_BIND_SERVICE. But this eBPF hook, not a seccomp..