All of lore.kernel.org
 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 13:38:13 -0800	[thread overview]
Message-ID: <20110309213813.GA28009@kroah.com> (raw)
In-Reply-To: <20110309193330.12181.92080.stgit@paris.rdu.redhat.com>

On Wed, Mar 09, 2011 at 02:33:31PM -0500, Eric Paris wrote:
> There is no way to limit the capabilities of usermodehelpers. This problem
> reared its head recently when 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.  This patch addes new
> sysctls which allow us to bound the permissions of usermode helpers.
> 
> /proc/sys/kernel/usermodehelper/bset
> /proc/sys/kernel/usermodehelper/inheritable

Shouldn't these be documented somewhere?  Documentation/ABI?

> You must have CAP_SYS_MODULE to change these (changes are &= ONLY).

Why that permission?  Just because 'modprobe' is usually run from this
callback?  Or some other reason?

> 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?

thanks,

greg k-h

  parent reply	other threads:[~2011-03-09 21:38 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-03-09 19:33 [PATCH -v2] capabilites: allow the application of capability limits to usermode helpers 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 [this message]
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=20110309213813.GA28009@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.