mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Greg KH <greg@kroah.com>
To: Eric Paris <eparis@redhat.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, 9 Mar 2011 14:26:29 -0800	[thread overview]
Message-ID: <20110309222629.GB30323@kroah.com> (raw)
In-Reply-To: <1299708672.17577.42.camel@unknown001a4b0c2895>

On Wed, Mar 09, 2011 at 05:11:12PM -0500, Eric Paris wrote:
> On Wed, 2011-03-09 at 13:38 -0800, Greg KH wrote:
> > > When the kernel launches a usermodehelper it will do so with these as
> > > the bset and pI.
> > 
> > Shouldn't the caller of these functions be the ones dictating the
> > capabilities it should be run with?
> 
> Yes. And no.  It depends what you mean.  The caps of the 'caller' task
> are irrelevant.  If I run ifconfig ipv6 I need CAP_NET_ADMIN but the
> upcall needs CAP_SYS_MODULE.  If I plug in a USB drive there is no
> 'caller' task which makes sense.
> 
> Now if by 'caller' you mean 'call site' then yes, we could probably
> launch usermodehelpers with reduced privileged sets.  We know in the
> code when we are asking to launch modprobe that we are going to need
> CAP_SYS_MODULE and don't need caps like CAP_SYS_RAWIO and CAP_MAC_ADMIN.
> We know when we upcall to hotplug we don't really need any priv, since
> it's another task that is going to do the real work.  So yeah, there
> might be some value in another patch to address this....

Yes, that is what I was referring to.

> But neither solves the problem of being able to eliminate capabilities
> from a machine globally.  In olden times we had a global cap-bound but
> it was dropped in favor of an inheritance from init type mechanism.
> Since kthreads don't inherit from init we still end up with this patch.

I'm not objecting to the patch, or the idea, just want to make sure it
is correct.

thanks,

greg k-h

  reply	other threads:[~2011-03-09 22:26 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
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 [this message]
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=20110309222629.GB30323@kroah.com \
    --to=greg@kroah.com \
    --cc=dhowells@redhat.com \
    --cc=eparis@redhat.com \
    --cc=jmorris@namei.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=morgan@kernel.org \
    --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®