linux-kernel - Re: patch to make Linux capabilities into something useful (v 0.3.1)

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]

Message-ID: <20060907230245.GB21124@sergelap.austin.ibm.com>
Date:	Thu, 7 Sep 2006 18:02:45 -0500
From:	"Serge E. Hallyn" <serue@...ibm.com>
To:	David Madore <david.madore@....fr>
Cc:	Linux Kernel mailing-list <linux-kernel@...r.kernel.org>,
	"Serge E. Hallyn" <serue@...ibm.com>
Subject: Re: patch to make Linux capabilities into something useful (v 0.3.1)

Quoting David Madore (david.madore@....fr):
> On Wed, Sep 06, 2006 at 01:25:31PM -0500, Serge E. Hallyn wrote:
> > The fact that you're changing the inheritance rules is a bit scary, so
> > I'm going to (and I hope others will) take some time to look it over.
> 
> Thanks!  I'd appreciate it.  Don't hesitate to ask me if some
> decisions I made are unclear.

Ok, so to be clear, in terms of inheritability of capabilities, your
three main changes are:

	1. When creating a bprm, it's inheritable and effective
	capability sets are set full on, whereas they used to be
	cleared.  The permitted set is treated as before (always
	cleared)

	2. When computing a process' new capabilities, the new
	inheritable come from the new permitted, rather than the old
	inheritable.

	3. You change half the computation of p'E to replace fE by
	pE in one half.

Here is one apparent change in behavior:

If I currently do

	cp /bin/sh /bin/shsetuid
	chmod u+s /bin/shsetuid

then log in as uid 1000 and run

	/bin/shsetuid
	# whoami
	hallyn
	# ls /root
	ls: /root: Permission denied

With your patch I believe it will succeed, since the sh process'
inheritable set will be set to it's permitted set.

Put another way:

	cap_set_proc("=i");
	execve("/bin/shsetuid");

I obviously wanted my inheritable set to be cleared, but running the
setuid binary will end up resetting my inheritable set to a larger
set.  Your goal of allowing the inheritable caps to be truly
inheritable may make sense, but this part of it feels wrong, and
changes current setuid behavior.

So in other words, it may make sense for the process to be able to
say "I want these caps to persist across exec" (*1), but it shouldn't
happen automatically based on the file's attributes.

In any case, perhaps it would be worthwhile making this a part of
a capability_plusplus module?  That would be less controversial,
given that I believe many people use the capability module who
really just want classic setuid behavior. 

thanks,
-serge
-
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/