> I'm curious, Dr. von Brand; have you considered stickybit + immutable? (as
> explained in my recent treatise to Richard ;-) It solves a lot of
> problems and gives us:
>
> That's actually the best alternative I've heard to date.
>
> My objection to using setuid root as the flag is that this means that
> even if you don't have root account (as Richard Gooch suggests), it
> still is a problem because there are a huge number of executables that
> are setuid root. And presumably, if a setuid root executable doesn't
> have a capability information, then it in effect becomes setuid root
> again. So it makes it easy for an attacker to hide a setuid root
> executable in a capability system. This is why folks would be much
Well, you "just" need utility like lscap which relisably shows what
permissions program is going to run with.
_IF_ you go for ext2-only solution, you may as well add capabilities
into ext2 directly.
> I suppose you could simply make a capibility-enabled kernel ignore the
> setuid bit on setuid root executables that have no capabilities set. It
> still doesn't solve the problem which Stephen brought up which is that
> you might want an executable to be setuid to some userid (such as
> daemon) and yet still have capabilities. So the stickybit + immutable
> is probably the best alternative heard to date.
Well - it changes something. You'll have to go out and tell everyone
"stickybit + immutable is deadly combination". Many times.
I do not have to do such things. setuid-marked executables actually
look more dangerous than they are. WHICH IS RIGHT.
Pavel
-- The best software in life is free (not shareware)! Pavel GCM d? s-: !g p?:+ au- a--@ w+ v- C++@ UL+++ L++ N++ E++ W--- M- Y- R+- 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/