> Ain't it fun trading e-mail in a few minutes across the planet?
> Heh...
Well, considering how fast we fill mailboxes on 1000+ people
subscribed on linux-kernel.... I'll merge two mails to one in order
not to fill peoples mailboxes at too big speed.
> > > > Well - it changes something. You'll have to go out and tell everyone
> > > > "stickybit + immutable is deadly combination". Many times.
> > >
> > > Yes, but consider _who_ will be the pioneers to first check the "CAP-ELF
> > > support (experimental)" box in kernel configuration. The help should say
> > > "Don't check this box without knowing what you're doing; it completely
> > > changes the UNIX security model. For documentation, see..."
> >
> > Yes. And with my suid scheme, I could just compile it into kernel
> > unconditionally, and would not need to tell anyone. See the
> > difference?
>
> But, as far as I can tell, setuid0 only helps us with binaries that were
> formerly run full setuid-root, where the stickable solution secures
> executables that formerly were just _run_ by root. I do _not_ want
> binaries to inherit everything.
Sorry. Not acceptable. This is too big change in semantic. When I run
emacs as root, I want it to use all capabilities I have. When I run
cat /dev/zero > /dev/hda as root, I do not want kernel denying
operation because cat does not inherit "RAW DISK ACCESS"
capability. Sorry.
Still, if you took a look with code, you'd see that header is
read/used unconditionally. So lowering privileges always work. So if
root takes care and only uses executables containing the right header
(which do not need suid 0), he can get protection you wanted.
Pavel
[NEXT MAIL]
> > 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
Ok, so you include capability header into named but don't mark it suid
0. Dropping privileges always work. Or you just put
loose_capabilities() at beggining of named's main().
Even if named has no capabilities, it is _still_ dangerous. It has uid
0 => it can send a signal to your init, and it can write to
/etc/passwd - because both init and passwd are owned by uid 0.
> 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)
Agreed that storing uid in headers is ugly. I probably do not
understand capabilities model. I've seen paper, but I do not see why
it is good thing.
> 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,
Look at code, privileges are dropped even if no suid 0 is present.
Pavel
-- I'm really pavel@atrey.karlin.mff.cuni.cz. Pavel Look at http://atrey.karlin.mff.cuni.cz/~pavel/ ;-).- 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/