linux-kernel - Re: [RFC] Capabilities still can't be inherited by normal programs

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: <CALCETrXC9hnBtqHguHh_tXphNutarPYj-nnUA_VAtY9XsfSbpA@mail.gmail.com>
Date:	Sat, 8 Dec 2012 15:57:39 -0800
From:	Andy Lutomirski <luto@...capital.net>
To:	"Andrew G. Morgan" <morgan@...nel.org>
Cc:	"Serge E. Hallyn" <serge@...lyn.com>,
	Casey Schaufler <casey@...aufler-ca.com>,
	Serge Hallyn <serge.hallyn@...onical.com>,
	linux-kernel@...r.kernel.org,
	linux-security-module@...r.kernel.org,
	Kees Cook <keescook@...omium.org>,
	James Morris <james.l.morris@...cle.com>,
	Eric Paris <eparis@...hat.com>,
	"Serge E. Hallyn" <serge@...onical.com>,
	Markku Savela <msa@...h.iki.fi>
Subject: Re: [RFC] Capabilities still can't be inherited by normal programs

On Sat, Dec 8, 2012 at 3:37 PM, Andy Lutomirski <luto@...capital.net> wrote:
>
> Again (any mainly because I feel like there's a giant mental
> disconnect here in that I really don't understand wtf the current /
> POSIX system is trying to accomplish): what would be wrong with a
> model in which capabilities could be freely passed from parent to
> child?  Why would it be insecure?  Why would it be error-prone?
> There's got to be *some* reason why it's not in use right now.
>
> I can speculate as to the reason the current scheme is barely used
> except internally to a few daemons (and why AFAIK there is no one
> making serious use of fI): it's basically incomprehensible.  Security
> systems should be simple enough to understand and analyze.  "Here is
> the set of things that I and my descendants can do" (the Windows
> model) is simple.  "Here is the set of things I can do (pP).  Here is
> a different set of things that a certain class of my descendants can
> do (pI).  Here is the class of descendants that can do those things
> (fI).  And here's a different class of descendants that can do things
> no matter who invokes them (fP)." is really hard to understand.
>
> It's especially bad because granting CAP_DAC_READ_SEARCH to user "foo"
> doesn't mean anything.  Is he authorized to back things up to
> encrypted storage?  Is he authorized to read any file for any purpose?
>  Is he authorized to read things on behalf of properly authenticated
> remote users?  No one knows because it depends entirely on what set of
> binaries with CAP_DAC_READ_SEARCH=i he can find.
>
> * I see "If pathconf() indicates that {_POSIX_CAP_PRESENT} is not in
> effect for a file, then the capability state of that file shall be
> implementation defined."  I think this means that the designers didn't
> actually decide whether fI should default to all zeros or all ones.

I just tried to search to find actual uses of pI/fI.  Here's what I found:

http://www.engardelinux.org/modules/index/list_archives.cgi?list=linux-security-module&page=0144.html&month=2010-04

A user (Stephen Hemminger, who presuambly understands Linux fairly
well...) who gave up because normal programs couldn't inherit
capabilities.

http://fpmurphy.blogspot.com/2009/05/linux-security-capabilities.html

Gives an (incorrect, AFAICT) example in which pI=cap_net_raw means "can ping"

http://forums.fedoraforum.org/showthread.php?t=203879

An unanswered question which the poster thought (I think) that giving
a user a capability would have some effect.

OK, bored of this search now.  Having trouble finding anything that works.

--Andy
--
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/