lkml.org 
[lkml]   [1999]   [Apr]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: caps in elf headers: use the sticky bit!
Hello Pavel,

On Wed, 14 Apr 1999, Pavel Machek wrote:

> > Now, I assume that our goal in putting caps in the elf headers is
> > to give us true capabilities support for elf binaries. At least, that is
> > _my_ goal. If that is _your_ goal as well, then here I will prove that
> > setuid0 will not work at all, even on a local ext2 fs. It has to do
> > with
>
> My goal is not to provide true capabilities. My goal is to provide
> usefull extension to elf headers in such way that it can be used now.

Ok, then let me show you why it's a lot less useful than stickable, with
another concrete example: named(8). You say it should be fine for an
executable to have all of inheritable flagged, I say that named should
_only_ have CAP_NET_BIND_SERVICE, all others dropped. All system services
should still run this way, otherwise we're as open to remote-root exploits
as we were before. True capabilities were well thought-out to give us a
better security model, IMHO. If you just go and completely break the
capabilities model, the setuid0 solution just gets worse. (storing uid
and setuid bit in headers is ugly, too, which is another reason I rejected
setuid0 as a solution)

> > This means that, not only is the permitted set important for a
> > file (which works fine under setuid0), but also important is the
> > inheritable set; i.e., setting the inheritable set should be a
> > priviledged
>
> I do not see why setting inheritable set should be privileged.

Now do you see? If it's not priviledged, then we haven't really made
progress. It's the principle of least priviledge we're aiming at, here,
and all binaries able to inherit all caps doesn't follow this principle.

> In traditional unix, every utility has inheritable set set to FULL by
> default. I do not think it is good idea to change that.

As I've said, capabilities support is an obvious and large departure from
traditional UNIX security. It's also better, IMHO.

> > Let's consider the chown(1) program, for a nice, concrete example.
> >
> > - CAP_CHOWN is the capability required for changing the owner of a file.
> >
> > - The CAP_CHOWN cap should be flagged in the inheritable set of the chown
> > binary, and if it's also flagged in the inheritable set of the parent
> > process, chown(1) should be capable of setting the file owner.
>
> I just think that CAP_CHOWN should be set in nearly any utility,
> including utilities users compile themselves.

What about CAP_SETFCAP?

> > - With the stickable solution, the file is marked +t and immutable, which
> > is a priviledged operation but otherwise harmless; with setuid0, you have
> > to make chown(1) setuid root! If you _don't_ require setuid0 on binaries
> > with an inheritable set, you open yourself to normal users being able to
> > create binaries that can inherit all the caps from it's parent
> > process.
>
> ...which is completely ok in my eyes.

I hope you see differently now.

> > > PS: Sorry, immutable bit just is not correctly supported these days.
> >
> > What do you mean by this, btw?
>
> I mean that utilities like tar _do not support_ bits like immutable,
> today. So you could really add new flag 'capability enhanced' instead
> of overriding immutable.

OK, well, if you've read my next message then you know we've got this
licked. (I say 'we' because it was Eric Biederman's idea to tie in the
immutable bit; the sticky bit just provides nice compatibility properties)

cheers,
David

- --
David L. Parsley
Network Specialist
City of Salem Schools


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:51    [W:0.117 / U:0.152 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site