Jesse Pollard writes:
> On Fri, 16 Jun 2000, [somebody] wrote:
>> Jesse Pollard <pollard@tomcat.admin.navo.hpc.mil> wrote:
>> 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.
>
> With the capability list in the inode, I can just list
> the inode contents and see what privileges it has.
This complaint is at least new and interesting.
Maybe, as an admin, I don't want my users to know which
executables would be good to attack. I'd like to have attackers
set off auditing alarms by attempting to make privileged
programs do things which they are not allowed to do.
Regular users are supposed to be doing their jobs, not investigating
the security policy of the system. Any normal user looking at
capability bits is to be suspected of trying to exploit a hole.
Not that I couldn't just provide privileged executables to read the
bits of course... I just choose not to allow users this ability.
> Granted the setuid bit disables the elfcap, unless run as root....
The "unless run as root" part need not be true. There are many ways
to deal with that:
a. the check is NOT for UID alone; the setuid bit MUST be set
b. panic the kernel if a buggy UID 0 process tries this trick
c. anything else, since no process should have UID 0
As I recall, method "a" is actually implemented.
You keep viewing the "UID 0", "setuid bit" and "elfcaps data"
as separate items that are vaguely related. In particular, you
keep interpreting the setuid bit as merely a way to access an
all-powerful UID. This is not the case. All elements should
be in place for the elfcap feature to activate. Elfcap need not
even require an all-powerful UID at all, but this doesn't matter
since you shouldn't be using UID 0 anyway.
> 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).
No. Even if this were a problem, I wouldn't care because you have
misplaced your trust. Stick to Open Source (TM) so you can have
some hope of actually auditing the code.
-
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:14 EST