Messages in this thread | | | Date | Tue, 13 Apr 1999 12:57:50 -0400 (EDT) | From | "Theodore Y. Ts'o" <> | Subject | Re: caps in elf, next itteration (the hack get's bigger) |
| |
Date: Tue, 13 Apr 1999 12:31:14 -0400 (EDT) From: "David L. Parsley (lkml account)" <kparse@salem.k12.va.us>
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 happier being able to make UID == 0 have no special capabilities worth speaking about.
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.
- Ted
- 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/
| |