Netdev List
 help / color / mirror / Atom feed
From: Eric Paris <eparis@redhat.com>
To: netdev@vger.kernel.org
Cc: nhorman@redhat.com, acme@redhat.com, dwalsh@redhat.com
Subject: CLONE_NEWNET requires CAP_NET_RAW (and the intended CAP_SYS_ADMIN)
Date: Tue, 03 Nov 2009 15:15:52 -0500	[thread overview]
Message-ID: <1257279352.2891.202.camel@dhcp231-106.rdu.redhat.com> (raw)

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


             reply	other threads:[~2009-11-03 20:15 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-11-03 20:15 Eric Paris [this message]
2009-11-04 13:33 ` CLONE_NEWNET requires CAP_NET_RAW (and the intended CAP_SYS_ADMIN) David Miller

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1257279352.2891.202.camel@dhcp231-106.rdu.redhat.com \
    --to=eparis@redhat.com \
    --cc=acme@redhat.com \
    --cc=dwalsh@redhat.com \
    --cc=netdev@vger.kernel.org \
    --cc=nhorman@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox