[...]
> 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/