linux-kernel - Re: [RFC][PATCH 1/1] support optional non-VFS capability inheritance without disabling file caps

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: <2359eed20908170948p6612b075mc245aa4fb92e76aa@mail.gmail.com>
Date:	Mon, 17 Aug 2009 11:48:54 -0500
From:	Will Drewry <redpig@...aspill.org>
To:	"Andrew G. Morgan" <morgan@...nel.org>
Cc:	"Serge E. Hallyn" <serue@...ibm.com>, linux-kernel@...r.kernel.org,
	James Morris <jmorris@...ei.org>,
	linux-security-module@...r.kernel.org,
	David Howells <dhowells@...hat.com>
Subject: Re: [RFC][PATCH 1/1] support optional non-VFS capability inheritance 
	without disabling file caps

On Mon, Aug 17, 2009 at 10:26 AM, Andrew G. Morgan<morgan@...nel.org> wrote:
> On Mon, Aug 17, 2009 at 7:38 AM, Will Drewry<redpig@...aspill.org> wrote:
[snip]
>> It is almost possible to achieve #2 on existing systems, assuming xattr
>> support can always be achieved.
>> Step 1, setcap cap_sys_rawio+i /usr/bin/pulseaudio
>> Step 2, pam_cap at X11 login to add cap_sys_rawio+i for a user session
>> (alternately, use capsh).
>> Step 3, run pulseaudio (pP' = (...) | (fI & pI) => cap_sys_rawio+ip)
>
> What about filecaps of cap_sys_rawio+eip on pulseaudio. With the
> bounding set suppressing cap_sys_rawio?
>
> In this case, only a process with (pI & cap_sys_rawio) can exec()ute
> pulseaudio, let alone use the capability. That is, the filecap +pe
> implies that the capability is required for the app to run, but the
> bounding set suppresses the bit from the file's xattr...! The only way
> that the exec()d program can get this required bit is from the (pI &
> fI), and so only if a process has (pI & cap_sys_rawio) will it be able
> to invoke the program...

Aha! I was missing something.  I was thinking that the bounding set was
still governing system-wide despite the fact it was right in front of me
that it wasn't (kernel source, capsh).

This works perfectly and achieves the exact same goal of step-down root
permissions with run-time inheritance-based management.

I guess we can bin the patch since I doubt xattr-less filesystems are
worth the change. (I might whip up a stackable one just to avoid dealing
with symlinks and loopbacks :)

Thanks for working through this with me.  Sorry that it took a few
rounds.

cheers!
will
--
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/