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

From: Albert D. Cahalan (acahalan@cs.uml.edu)
Date: Wed Jun 14 2000 - 12:39:54 EST


Jesse I Pollard, II writes:
> Pavel Machek <pavel@suse.cz>:

>>> When I install software, I try to install it as non-root.
>>> This prevents the normal creation of setuid binaries that
>>> I don't know about. The number
>>
>> Fine. You have no problems with elfcap, then. Noone has setuid 0 bit,
>> you don't have to examine anything, elfcaps are nop.
>
> THEY ARE NOT - I may use them as root. Someone else may use them as root.

Well, that would be pretty stupid of you, wouldn't it?
Why in hell are you running trojan binaries as root?
Why did you give this clueless "Someone else" admin power?

Just as programming languages can not prevent bugs, security
systems can not prevent complete administrative abuse.
Not even MAC can prevent this kind of error... if an install
program asks you to grant it MAC override, do you do so?

> they may have passed the initial testing and appear as quite normal
> applications UNTIL they are run as root. Even on a system with root
> having no privileges, suddenly this program becomes privileged.

See, there is your mistake. It is foolish to think that it is
practical to have root without privileges. Just disable the account.
(set the password entry to '*' or adjust the kernel as desired)

One should also maintain control over setuid executables by blocking
their creation, blocking their use with mount options, auditing the
use and creation, etc.

>>> of binary only installation software is very large, since many vendors do
>>> not want the installation procedure modified. Since I can't look at the
>>> binaries before installation, I can only look at them afterward. elfcap
>>> makes it necessary to examin every file (executable or not) to search for
>>> trojan horses with improper capability assignments.
>>
>> No. Just search executable being setuid 0 for trojan horses. Elfcap is
>> nop for binaries not being setuid 0. Take a look at code.
>
> did. and I repeat:
>
> NO ELFCAP. not secure, not reliable, not auditable.

Oh bullshit. You've not proven any of that. I can well imagine
that one might think elfcap is ugly, but it gets the job done.
It is just horrible to require exotic filesystem features and
exotic backup tools when they shouldn't be needed at all.

As of now, the only other practical proposal was the one that
involved registering privileged executables with the kernel,
using an in-memory set of capabilities and an immutable bit.

It is about time that you admit elfcap gets the job done.

-
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 : Thu Jun 15 2000 - 21:00:34 EST