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

From: Pavel Machek (pavel@suse.cz)
Date: Fri Jun 16 2000 - 14:13:45 EST


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?

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

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

-- 
I'm pavel@ucw.cz. "In my country we have almost anarchy and I don't care."
Panos Katsaloulis describing me w.r.t. patents me at discuss@linmodems.org

- 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