Messages in this thread | | | Date | Wed, 14 Apr 1999 13:57:42 +0200 | From | Pavel Machek <> | Subject | Re: caps in elf, next itteration (the hack get's bigger) |
| |
Hi!
> 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/
| |