Messages in this thread | | | Subject | Re: caps in elf headers: use the sticky bit! | Date | Mon, 19 Apr 1999 17:30:54 -0400 | From | Horst von Brand <> |
| |
"Albert D. Cahalan" <acahalan@cs.uml.edu> said: > Theodore Y. Ts'o writes:
[...]
> You claimed that the setuid-bit meant an executable would run as root. > This is not true, as anyone following the discussion would know. > > > a program may need to > > be setuid "daemon" (or some other non-root UID), so that it has the > > ability to access files owned by a particular uid, as well as have some > > capabilities set.
> > Therefore, using setuid root is insuficient. Q.E.D. > > No, not "Q.E.D." at all. This is idiotic. All options have major flaws. > That includes filesystem support, the sticky bit, PGP...
Please elaborate...
> Let's look at the processes on a normal Linux system first. > > $ ps -Nu root,albert,luser > PID TTY TIME CMD > $ ps -NU root,albert,luser > PID TTY TIME CMD > $ > > The daemons don't run as "albert" or "luser". They run as root. > There are exceptions on some systems, but a root-only solution > will cover the vast majority of daemons.
We aren't talking "normal Linux systems", we are talking "capability secured Linux systems" here. What makes you think that nobody would ever run named(8) as user named, group named, so it (via normal permissions) can only read the zones for which it is responsible (and nothing else!), while named-xfer(8), running as user named-xfer can write over the ones it is slave server for, but nothing else? The daemons today run as root because currently it is the only way to get the capabilities they need.
> Being setuid to a non-root user is usually a stupid idea anyway. > Not counting ext2-specific hacks, it gives the right to turn the > original executable into a trojan. This is why games are not setuid > to a "games" user for their score files.
S[UG]ID was invented _precisely_ to enable some processes to have powers above and beyond the ones the invoking user has. If this is _so_ broken as you claim, the SUID root stuff is a even much worse risk!
Truth is, only SUID root gives you access to widely useful extra capabilities, so it's the most used.
> Our choices include: > > * Incompatible filesystem hacks
Nope. ext3 will always be compatible with ext3. You can't expect ext2 or VFAT or NTFS or NFS or CODA to be able to handle highly sensitive binaries if they don't handle capabilities sensibly, so there isn't a problem there at all.
> * Insecure sticky bit hacks > * Incomplete or ugly setuid-root hacks
Exactly!
> * Inconvenient VMS-like hacks
Yep.
> * Inefficient PGP-based hacks
Double yep.
> As I've said before, we don't have to choose one. We can let the admin > choose zero or more hacks for each mounted filesystem. One only needs > a way to indicate trust. For a vendor-supplied CD-ROM, that might be > everything on the disk. Some people may trust anything owned by root.
Please. This means including _several_ incompatible kludges into the system, that interact in unknown ways, to make it "more secure"? You can't be serious. -- Dr. Horst H. von Brand mailto:vonbrand@inf.utfsm.cl Departamento de Informatica Fono: +56 32 654431 Universidad Tecnica Federico Santa Maria +56 32 654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513
- 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/
| |