> -----Original Message-----
> From: pavel-velo@bug.ucw.cz [mailto:pavel-velo@bug.ucw.cz]
> Sent: Thursday, January 02, 1997 8:19 PM
> To: Theodore Ts'o; mrwizard@psu.edu
> Cc: linux-kernel@vger.rutgers.edu
> Subject: RE: Ke: Process Capabilities on 2.2.16, Sendmail problem
> revisited
>
>
> > Ok guys, this isn't going to work. The 2.2.16 patch
> pretty much took the
> > inheritable set and threw it out the window. At least
> before, you could
> > mask an entire capset and not have to worry about suid
> programs getting
> > elevated caps (if the program was capabilities
> 'smart'). Now we're back to
> > the uid 0 is root no matter what situation. Instead
> of fixing exec(), you
> > broke capabilites. Grr! I've been trying to track
> this down, here's what I
> > see.
> >
> >Yes, that was deliberate. The problem is that allowing
> an attacker to
> >arbitrarily deny privileges to setuid root programs is dangerous.
> >CAP_SETUID isn't the only case where this could cause problems.
> >Consider what might happen if some program was denied
> CAP_CHOWN (and
> >didn't check for return values so it didn't notice that
> it failed), for
> >example. You could argue that the program was broken,
> but it was a
>
> What about: in order for setuid to work, your CAP_INHERITABLE
> has to be full? If you try to exec setuid program and your
> inherutable set is not full, you should get -EPERM (just like
> in case when programbeing ptraced tries to exec setuid program).
>
Good idea. The only problem here is if a program is non-uid 0 and has some
capabilities, you might want to limit suid capabilities. (I do it in my
apache patch)
How about a check when capset is called, such that if you want to change the
inheritable set, and we're in compatibility mode, you have to have something
in your permitted set (this can only be obtained from a setpcap from a root
process, or by being root), or have CAP_SETPCAP (redundant, but complete).
I'd be happy with that as it wouldn't break existing programs and yet would
be secure.
Joe
-
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/
This archive was generated by hypermail 2b29 : Thu Jun 15 2000 - 21:00:30 EST