linux-kernel - Re: [PATCH -v2] capabilites: allow the application of capability limits to usermode helpers

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 09 Mar 2011 17:11:12 -0500
From:	Eric Paris <eparis@...hat.com>
To:	Greg KH <greg@...ah.com>
Cc:	linux-kernel@...r.kernel.org,
	linux-security-module@...r.kernel.org, dhowells@...hat.com,
	jmorris@...ei.org, serge.hallyn@...onical.com, morgan@...nel.org
Subject: Re: [PATCH -v2] capabilites: allow the application of capability
 limits to usermode helpers

On Wed, 2011-03-09 at 13:38 -0800, Greg KH wrote:
> 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?

Yes, they should.  Will do.

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

I don't have a good answer for this.  I was originally looking at this
thinking about modprobe.  Since it's a purely restrictive interface I
probably don't need something quite so strong.  I'm trying to decide
what the implications are of usemode helpers being forced to run with
reduced permissions.  Andrew, do you have thoughts?

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

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.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/