Re: Subject: Re: ext3 to include capabilities?

Albert D. Cahalan (acahalan@cs.uml.edu)
Fri, 2 Apr 1999 23:20:21 -0500 (EST)


Santos Halpar writes:
> Albert D. Cahalan" <acahalan@cs.uml.edu> wrote:
>> G. Sumner Hayes writes:
>>> Albert Cahalan <acahalan@cs.uml.edu> wrote:

>>>> 1. Put capabilities information in the executable header.
>>>> 2. Mark the executable setuid root.
>>>> 3. Have the kernel check for #1 if #2, and prefer #1 if present.
>>>
>>> Of course, you've completely busted up security.
>>
>> Nope, think about the system a bit more. It isn't so stupid.
>>
>> if(setuid){
>> if(root_owned && cap_header) use_cap_header();
>> else use_setuid_bit();
>> }
>
> I understand that. Read my concern again. I don't understand how
> your system can possibly make my (already installed) 2.0.x kernel
> ignore the setuid bit. I have 2.0.x around for stability, so putting
> random patches into it isn't really an option. It seems like your
> system will run programs with capabilities on 2.2.x but full-blown
> setuid on 2.2.x,

One doesn't give capabilities to random executables. One uses them
in place of existing setuid-root settings. Consider this program:

-rwsr-xr-x 1 root root 14148 Jan 10 1998 /bin/ping

Right now it is setuid-root, with full capabilities.
With my proposal, it gets far fewer capabilities.
If you revert to the old kernel, you should get the old security.

You really need a setuid-root setting that is ignored by newer
kernels, so that you can still run an old kernel with traditional
security. Without this, /bin/ping and others won't run on old kernels.

> which opens up the security holes I'm concerned about
> when running the most stable (for the moment :) and secure kernel.

No, you get back the old holes (if any) when you run an old kernel.

> Same thing with mount; I never let /bin/mount be suid, but I'd be
> willing to give it a mount capability (if there were one; full
> admin capability is a bit too much for my taste). So when 2.?3?.x
> is running, peons could mount/umount the floppy; with 2.0.x it'd be
> like it is now -- no mounting for non-root.

Of course, a buffer overflow would still grant root and full
capabilities. (mount an ext2 floppy with privileged executables)

BTW, this is Red Hat 5.0 mount:
-rwsr-xr-x 1 root root 34424 Jan 10 1998 /bin/mount

> Basically, it seems like your system doesn't allow a secure fallback
> for 2.0.x machines. It promotes capabilities-having bins to suid
> ones under old kernels, which is a major bug IMO.

It is a minor missing feature. You should not grant capabilities
to executables you don't trust, and you should not run crummy
old kernels. I had indeed assumed that you would only be reducing
the capabilities that current setuid-root executables have, not
granting capabilities to new poorly-trusted executables.

When replacing setuid-root with capabilities, you certainly do
want a fallback to the old setuid-root system.

> Your idea does limit the fs data needed to one bit, and that's
> something I don't mind. Using the suid bit as you suggest is
> bogus, though. The sticky bit would work if it were limited to root,
> but that's not an assumption that's workable in an NFS environment
> (correct me if I'm wrong).

The sticky bit would work fine over NFS. In that case, there must be
a header flag to disable setuid operation. This is because /bin/ping
and others must be setuid-root when running with an old kernel, but
should not be root when they can just get the needed capabilities.

I prefer the setuid bit though, because it will be noticed by scripts
that look for suspicious executables. It is much less likely that a
script will notice an executable with the sticky bit set. (but this
is still better than a strange new file attribute)

Well, which do people prefer? (sticky bit or setuid bit)

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