Re: caps in elf headers: use the sticky bit!

Albert D. Cahalan (acahalan@cs.uml.edu)
Mon, 19 Apr 1999 04:28:02 -0400 (EDT)


Theodore Y. Ts'o writes:
> From: "Albert D. Cahalan" <acahalan@cs.uml.edu>

>> Clearly you have missed a large chunk of the discussion.
>
> And again, clearly you have missed the discussion where it has been
> pointed out repeatedly that this is insufficient;

Well, I tried to be polite... (granting you an excuse)

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...

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.

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.

Our choices include:

* Incompatible filesystem hacks
* Insecure sticky bit hacks
* Incomplete or ugly setuid-root hacks
* Inconvenient VMS-like hacks
* Inefficient PGP-based hacks

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.

Trust is an administrative policy decision. The trust mechanism is
barely related to the purpose it is used for.

-
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/