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: <2359eed20908170738w4b3c5980x4e1defb2ed8e773c@mail.gmail.com>
Date:	Mon, 17 Aug 2009 09:38:37 -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

Hi Andrew,

Cool, so yes, I would like for a parent process to be able to
grant a subset of its privileges to its children.

I am interested in this approach for two reasons:
1. provides xattr-less filesystem SECURE_NOROOT 'support'
2. provides ephemeral capabilities

For #1, I concede that there are any number of workarounds to achieve
xattr support on a given system.  As with any workaround, they come with
some overhead, be it in additional kernel support or in system
management overhead.  However, those can be dealt with at a non-kernel
level for the most part.

For #2, it is currently the case that if a given user can run a binary
with capabilities, they can always run it with those capabilities, just
like a SUID binary.  I would like support to empower a given process
tree with a capability that is not granted unless that process tree has
been traversed.

IMHO, a good example is /usr/bin/pulseaudio.  On most distributions, it
is a SUID binary, but it could probably get by with cap_sys_rawio+ep.
However, even with 'setcap cap_sys_rawio+ep', it would still provide the
attack platform used in several recent kernel NULL pointer dereferencing
exploits.  Any user that can normally execute pulseaudio can do so at
anytime.  However, it would be preferable if a user's pulseaudio sound
server was run once with privilege (on X11 login, perhaps) instead of
anytime during a given session.

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)

It would mean that that specific user-session could launch pulseaudio
with cap_sys_rawio+ip but not necessarily any active user with +x
privileges on the pulseaudio binary. In addition, at any point in the
session, cap_sys_rawio could be dropped permanently which would block
future reuse/abuse (without relogin).

The problem with this approach is that many existing applications are
capability-ignorant.  Since the capabilities granted above
would be in the inherited and permitted sets only, these legacy
applications would still lack the privileges they need -- even if only
because they are too dumb to fix it.  To get the same effect, each of
these daemons/packages/etc will need to be patched to attempt to setpcap
any capabilities they might need to move them into the effective set.

My proposal would alleviate the need to independently patch existing code
and would avoid filesystem-related workarounds.  I'm looking at the
change as a compatibility feature. root privileges could be parceled but
still inherited - but only when the new securebit is set.

I hope that I'm making a bit more sense this go around.  Sorry for any
confusion.

thanks!
will

On Sun, Aug 16, 2009 at 11:50 PM, Andrew G. Morgan<morgan@...nel.org> wrote:
> Will,
>
> I've read this over a few times, but the in-lining is confusing me.
> The idea of tying privilege only to 'anointed' binaries is the "POSIX"
> capabilities model.
>
> If you are willing to concede that one can always arrange xattrs to be
> convenient with various filesystem mounting techniques, are you saying
> you would like all executables to be able to wield privilege if their
> parent wants to give it to them?
>
> Thanks
>
> Andrew
--
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/