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: <CALCETrUwVO6YjO-VzwBO59z4L2zB+-Zd_V-ontciMEFzRHzDFQ@mail.gmail.com>
Date:	Fri, 7 Dec 2012 10:39:26 -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 Fri, Dec 7, 2012 at 9:07 AM, Andrew G. Morgan <morgan@...nel.org> wrote:
> I'm still missing something with the problem definition.
>
> So far if I follow the discussion we have determined that inheritance
> as implemented is OK except for the fact that giving user an
> inheritable pI bit which gives them default permission to use all
> binaries endowed with the corresponding file fI bit.

This is IMO part of the problem but not the entire problem.

>
> Is this the problem a different inheritance model is supposed to
> address? Serge suggested that the binary could authenticate the
> user... This seems like its putting the protection in the best
> place... Each app can control its sub functions with the richest
> semantics.
>
> That being said...
>
> To me this looks like it's an access control problem... Namely use
> acls to limit which users (groups) can execute each privileged binary.
> Serge's option 2 seems like a similar approach.
>

The issue is (as I see it) with non-privileged binaries.  If a given
program (correctly) has a permitted capability and is not root, then
the only way that it can pass that capability on to children (e.g.
helper programs) is to set it into pI.  This only works if the child
has the same bit set in fI.

This is doable but annoying -- every program that a privileged program
runs needs to be authorized by the administrator.

It breaks down because, currently, users with nonzero pI have no
direct ability to wield the capabilities.  That means that every
single binary with fI bits set needs to be as careful as a setuid-root
binary to avoid leaking privilege to the caller.  (Obviously, binaries
with fP set need to be careful.  IMO binaries with only fI set should
not need to exercise any particular care to defend themselves from
their callers.)

I'm obviously missing some fundamental (and probably historical) issue
here, so let me ask the following straw-man question.  Suppose
capabilities worked like this on exec:

pP' = pI | (fP & pB)  (i.e. the current way, except that fI always has
all bits set for every binary on the system)
pI' = pI (unless !SECURE_NOROOT and uid == 0 or euid == 0, in which
case pI' = pP')

with the added restriction that pI is always a subset of pP (i.e.
dropping a bit from pP (on exec or otherwise) drops that bit from pI).

What would be wrong with this model?  (Let's pretend for now that
capabilities had always worked this way, so there's no change of
behavior to worry about.)

 - The sendmail capability bug wouldn't happen: pI has no effect on
setuid-root binaries.

 - There would be no difference between a user being trusted with a
capability and being inh-trusted with that capability, since the
latter concept wouldn't really exist.

 - Totally unprivileged users couldn't engage in any funny business.
Their pI masks would be zero, and they would have no way of changing
that.

 - Partially privileged users would work just fine.  They could wield
their capabilities (subject to some possible fiddling with pE) from
bash or from anything else.  They could also freely drop those
capabilities.

 - Privileged programs would require less thought: to grant a program,
you set its privilege in fP.  There is no fI, so there's nothing
special to think about.

NB:  This is not a real proposal because there *are* capability-aware
programs out there.  I want to understand why the current system is so
different.

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