Re: Ke: Process Capabilities on 2.2.16, Sendmail problem revisited

From: Jesse Pollard (
Date: Sat Jun 17 2000 - 19:03:41 EST

On Fri, 16 Jun 2000, Pavel Machek wrote:
>> >You keep on asserting that, but never bother to justify it beyond handwaving.
>> >Security is relative. Is elfcap more or less secure than normal setuid-root?
>> >(I would say clearly more secure, but I can't claim infallibility)
>> Less secure - The reason I think so:
>> 1. Given elfcaps are stored in the header of an executable.
>> 2. some executables cannot be read
>> 3. That means I cannot see what privileges are granted if I run the
>> executable, even if I'm just a user.
>It is certainly not less secure than regular setuid: by analogy, you
>can have non-readable setuid program. And how do you know what
>capabilities it will use?

If it is setuid it will use any/all privileges given the uid.

>> With the capability list in the inode, I can just list the inode
>> contents and see what privileges it has.
>> Granted the setuid bit disables the elfcap, unless run as root....
>> The problem still occurs if root is not allowed to read the executable
>> for some reason. Suddently the executable has privileges I do not want
>> it to have, nor to give it. This usually happens when I have to install
>> someting in the blind (binary install tools type of problem).
>If root is not allowed to read capability header, why should he
>execute it? If root sees unreadable setuid program, should he execute
>it? Certainly not. If root sees unreadable setuid elfcap program,
>should he execute it? Not, too -- he can't even determine if it is
>elfcap program. So I did not make situation any worse.

The problem is some blind install tools will use it. They exist, and will
continue to exist (and I don't like it :).

>Okay, shell we agree that this is not worse than current situation?

I Never ment that it was worse. I just see it as limiting future development,
both of capabilities and the executable format.

Jesse I Pollard, II

Any opinions expressed are solely my own.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

This archive was generated by hypermail 2b29 : Fri Jun 23 2000 - 21:00:15 EST