CLONE_NEWNET requires CAP_NET_RAW (and the intended CAP_SYS_ADMIN)

CLONE_NEWNET requires CAP_NET_RAW (and the intended CAP_SYS_ADMIN)

[Eric Paris]

We just saw today, because vsftpd just started using by default, that
CLONE_NEWNET requires both the intended CAP_SYS_ADMIN (see
kernel/nsproxy.c::copy_namespace()) and the unintended CAP_NET_RAW.
This is because tcp_sk_init() calls inet_ctl_sock_create() with
SOCK_RAW.  Ultimately we end up in inet_create() which see that
answer->capability is equal to CAP_NET_RAW.  So now it checks
capable(CAP_NET_RAW).

What you will find is that the generic __sock_create() has an argument
"int kern" which is passed to the security server to bypass checks which
were caused by the kernel, not because of userspace.  That flag is not
passed down to the create() function in struct net_proto_family.  I
think the easiest solution is to add the kern argument to the
net_proto_family create function and pass it along to the security
system so it can make the right decision.

I also see that the whole capability checking in struct inet_protosw
(and can, dccp, and sctp) seem overly complicated.  Most of it (all but
inet) could just be deleted since they aren't doing anything.  Inet
could replace it with just a single if (SOCK_RAW) which make the
security server changes very simple....

Did I explain my problem (I don't want to check CAP_NET_RAW)?  Do people
see an issue with me passing kern down to create?  Anyone have problems
with me ripping out the half ass unused security infrastructure?

-Eric

Re: CLONE_NEWNET requires CAP_NET_RAW (and the intended CAP_SYS_ADMIN)

[David Miller]

From: Eric Paris <eparis@redhat.com>
Date: Tue, 03 Nov 2009 15:15:52 -0500

> Do people see an issue with me passing kern down to create?

This sounds fine.

> Anyone have problems with me ripping out the half ass unused
> security infrastructure?

If you can simplify it as you describe, indeed this sounds
like a great change to make.