Jesse I Pollard, II writes:
> pavel-velo@bug.ucw.cz:
>>> Yep. Capabilities in ext2 is just wrong. Using ELF is merely bad.
>>> This is a UNIX clone you know; you can't make it into VMS.
>>
>> Why not? Elfcap is simple hack that does not break anything.
>> Capabilities *are* usefull for simple tasks already. I do
>> not know about VMS, but current system has practical uses.
>
> Elfcap is insecure, and permits the generation of trojan horses.
No it isn't. You obviously don't know how it works.
>>> Ever wonder why? The system is not compatible with UNIX.
>>> It isn't even safe. This is making MAC look easy, since at
>>> least MAC operates "outside" the normal security system.
>>
>> elfcap-ed ping would be slightly more secure than current ping.
>> What is unsafe on capabilities?
>
> That depends on the implementation - an incorrect implementation
> is unsafe. Capabilities are secure.
Capabilities are not secure unless associated with UID and GID,
because of both human and application compatibility problems.
As far as implementation goes, just last week we had a major bug.
>From what little was announced, I believe it was almost exactly
the bug I had predicted: limited capabilities causing privileged
executables to fail.
>>> I know one way to fix all this. It is not nearly as fancy, but at
>>> least it doesn't cause so many incompatibilities. Do the obvious.
>>> Have UID-to-capability and GID-to-capability tables in the kernel.
>>> Load them early in the boot or via a trusted daemon. This doesn't
>>
>> That is just plain ugly. Elfcap is very nice compared to this.
>
> Until you are passed a trojan horse.
No, elfcap isn't that stupid. It is ugly, but it works fairly well.
(it works better than ext2 extensions, which isn't saying much)
>>> have any "way cool" inheritance algorithms to confuse admins and
>>> programs alike. It just works. Across an exec, capabilities must
>>> be fully enabled for compatibility. Capability-aware programs
>>> could disable unneeded privilege as the first step in main.
>>
>> Is not dropping unneeded privileges exactly the thing the
>> other person said he is doing?
Sure, but this must not propagate across an exec. It is unsafe to
have partial privileges except as determined by the admin and/or
author of the program in question.
> Capability lists must be maintained separately from the executable
> image (ie in the inode, or somewhere else) to prevent the importing
> of a trojan containing "elf" implemented capabilities that are not
> authorized by the local facility. Just copying a file does not
> (should not) include copying the capability list along with it.
The capability list really should be copied with the executable. :-)
The elfcap patch assigns new meaning to the setuid bit. If the bit
is set and the file is owned by root, the process is first assigned
full traditional setuid-root power. (nothing different yet) Then,
since setuid-root executables are trusted, the elfcap header is used
to determine what capabilities should be removed and what UID should
be used in place of root.
Oh, but you don't want root having such power? Fine, just get rid
of root's password or change root's UID to 42. You don't have to use
the account if you don't like it. Indeed, you need not have any
process running with UID 0.
This system can survive tar, cpio, and dump. This system can be
blocked on a per-mount basis just like setuid programs can be.
This system can work over NFS -- and don't gripe about the security
of that since I'll just say you could use a physically separate
network to NFS mount from read-only media. Perhaps the best feature
is that existing admin scripts can detect that the executables
are privileged.
The only other workable system involved having the kernel keep
a list of privileged executables. It would do this by keeping
them "open" and immutable from boot to shutdown. The list could
be provided on the kernel command line or by a boot script prior
to entering secure mode.
-
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:28 EST