On Fri, 16 Jun 2000, Pavel Machek wrote:
>Hi!
>
>> >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
Email: pollard@cats-chateau.net
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 majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Fri Jun 23 2000 - 21:00:15 EST