From: Eric Paris <eparis@redhat.com>
To: Vasiliy Kulikov <segoon@openwall.com>
Cc: linux-kernel@vger.kernel.org,
linux-security-module@vger.kernel.org, dhowells@redhat.com,
jmorris@namei.org, serge.hallyn@canonical.com, morgan@kernel.org
Subject: Re: [PATCH -v2] capabilites: allow the application of capability limits to usermode helpers
Date: Wed, 09 Mar 2011 15:00:25 -0500 [thread overview]
Message-ID: <1299700826.3411.4.camel@localhost.localdomain> (raw)
In-Reply-To: <20110309194501.GA9362@albatros>
On Wed, 2011-03-09 at 22:45 +0300, Vasiliy Kulikov wrote:
> Eric,
>
> On Wed, Mar 09, 2011 at 14:33 -0500, Eric Paris wrote:
> > someone complained that any user with
> > cap_net_admin was able to load arbitrary kernel modules, even though the user
> > didn't have cap_sys_module. The reason is because the actual load is done by
> > a usermode helper and those always have the full cap set.
>
> AFAIU, your patch sets system-wide caps for _all_ usermode helpers,
> right? Then it does nothing with cap_net_admin's problem as it should
> restrict caps of specific helpers spawned from specific networking code,
> but not touching anything related to another helpers.
I'm actually solving 2 problems at once and it just so happens the the
CAP_NET_ADMIN brew-ha-ha came up more recently. The original problem,
and reason I wrote this patch, is because it's impossible on a modern
Linux system to permanently and irrevocably drop capabilities system
wide. You can get very close by dropping capabilities from the bset
before init is launched which means everything launched by userspace
can't have the dropped capabilities. But, khelper is still going to
have the full set and thus usermodehelpers launched by the kernel will
have the full set. This patch allows one to control usermode helpers.
How one chooses to use that, is up to them.
-Eric
next prev parent reply other threads:[~2011-03-09 20:00 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-03-09 19:33 Eric Paris
2011-03-09 19:45 ` Vasiliy Kulikov
2011-03-09 20:00 ` Eric Paris [this message]
2011-03-09 20:47 ` David Howells
2011-03-09 21:38 ` Greg KH
2011-03-09 22:11 ` Eric Paris
2011-03-09 22:26 ` Greg KH
2011-03-12 17:01 ` Andrew G. Morgan
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=1299700826.3411.4.camel@localhost.localdomain \
--to=eparis@redhat.com \
--cc=dhowells@redhat.com \
--cc=jmorris@namei.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=morgan@kernel.org \
--cc=segoon@openwall.com \
--cc=serge.hallyn@canonical.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
all inboxes | Powered by JetHome®