Message-ID: <CALCETrXRuARVzBsdDufYUaJcp6Ta80WWb5nBuk_sATk52PgoTw@mail.gmail.com>
Date:	Mon, 10 Dec 2012 11:55:33 -0800
From:	Andy Lutomirski <luto@...capital.net>
To:	Casey Schaufler <casey@...aufler-ca.com>
Cc:	Serge Hallyn <serge.hallyn@...onical.com>,
	"Andrew G. Morgan" <morgan@...nel.org>,
	"Serge E. Hallyn" <serge@...lyn.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 Mon, Dec 10, 2012 at 11:51 AM, Casey Schaufler
<casey@...aufler-ca.com> wrote:
> On 12/10/2012 11:31 AM, Andy Lutomirski wrote:
>> On Mon, Dec 10, 2012 at 11:13 AM, Casey Schaufler
>> <casey@...aufler-ca.com> wrote:
>>> On 12/10/2012 10:12 AM, Andy Lutomirski wrote:
>>>> I think that the Windows approach is worth looking at.  See here:
>>>>
>>>> http://msdn.microsoft.com/en-us/library/windows/desktop/aa375202%28v=vs.85%29.aspx
>>>>
>>>> In the Windows model, each capability ("privilege") can be in one of
>>>> three states: enabled (i.e working right now),
>>> Effective
>>>
>>>>  permitted (i.e.
>>>> available upon request but not currently enabled),
>>> Permitted
>>>
>>>> or removed
>>>> (disallowed to this process and all of its children).
>>> ~Inherited
>> No.  It's ~Inherited in a world where every binary has fI = everything.
>>
>>>> Permitted
>>>> privileges are always inherited when a child process is created.
>>>>
>>>> This is *way* simpler than Linux's model, and it works just fine*.
>>> I see a different set of complications, and Windows never had
>>> a setuid bit to contend with. God created the universe in seven
>>> days, but then, He didn't have an installed base.
>>>
>> What are those complications?
>
> I wish I had the time to go into the details, but I just can't.

Um.

I'd like to solve what appears to me to be a problem.  There's an
existing design that, from my perspective, is overcomplicated and
doesn't actually do what I want it to do.  I'd really like to know
what the current design *does* accomplish, since then I can make far
more informed proposals for how to fix it.

So far, I know of exactly nothing useful that's accomplished by the
current design.  It would be great if someone would enlighten me.

>
>> Also, I think we really could get rid of setuid without breaking
>> anything with a bit of extra (non-capability-related) plumbing work.
>
> If RedHat or Ubuntu wanted to take a year off from everything else
> they could create a setuid-root free system. It would probably be
> easier for Android or ChromiumOS, as they provide more limited
> environments.
>
> It's not "a bit of extra plumbing". I did it for a Unix system and
> you'll have to change bunches of existing programs to make it work.
> I'm not saying that the changes would be bad, but the sendmail
> fiasco arose from just such an effort. You'll also have to train
> the users that sudo no longer does them any good. In fact, you'll
> be barraged with one question:
>         "How do I get to be Real root"?
>

That's not what I'm talking about.

Write a daemon.  Rig up wrappers for each setuid program to instead
call into that daemon and have that daemon invoke the privileged
program on behalf of the caller, with a sanitized environment.  Be
annoyed by a few items on the "linux plumber's wish list" that make
this rather difficult right now.

sudo would give real root, just like it does today.  No setuid bit needed.

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

Powered by blists - more mailing lists