On Fri, 16 Jun 2000, you wrote:
>Jesse Pollard <pollard@tomcat.admin.navo.hpc.mil> wrote:
>> Elfcap is insecure, and permits the generation of trojan horses.
>
>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.
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).
>> > 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.
>
>*cough*. That is a gross simplification. Security is a process, not a
>product. Capabilities, can be a useful tool in securing systems.
I'm all for capabilities - just not bad implementations.
>> > That is just plain ugly. [UID/GIDS mapping to capability lists]
>> > Elfcap is very nice compared to this.
>>
>> Until you are passed a trojan horse.
>
>And how is this a problem of _elfcap_? Any random binary can be a
>trojan. How does elfcap exacerbate this? It doesn't. If you run
>untrusted binaries from a process with raised capabilities, then you are
>vulnerable. elfcap will not change this. If you run untrusted setuid
>binaries, you are vulnerable. elfcap will not change this.
Elfcap hides the privileges that are going to be used. I don't have to
be able to read an executable to examine the inode bits.
It also means that the kernel is being tied to one executable format
too. If something "better" than ELF format comes along then suddently
it has to do the "capset" thing, which may not be the best for the format.
I have found that separation of duty provides better overall security.
ELF is designed to provide a program load capability. It isn't designed
for security.
>The only real thing that elfcap does not provide is automatically
>dropping capabilities that a privileged process may have upon executing
>another. But you haven't made this point. And you can make it the
>problem of the calling process. Less secure, in that it is easy to make
>a coding mistake, but it really shouldn't be a problem.
>
>> No. Dropping unneeded privilegets by mandatory use of the capability
>> masking is what he wants, but is not necessarily done properly which
>> leaves incorrect privileges available.
>
>Right. And elfcap has the kernel do it at the direction of the admin,
>rather than trusting the generator of the binary.
>
>> 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.
>
>Copying a suid file gives you a suid file, with the current set of
>tools. I'd argue that the principle of least surprise would imply
>copying "capabilities" as well. (As we should all know, these aren't
>really capabilities.)
That is "least surprise" but is also "least secure". One of the things
necessary is that the ability to set capabilities must also be restricted.
elfcap doesn't allow that.
>
>If you don't want a possible trojan to have any capabilities, take off
>the suid bit. Then it won't matter one bit what the elfcap header has.
>
>You apparently want a system where UID 0 is not special. That's not
>going to happen for a while, but elfcap does let you get close. Things
>that would be setuid 0 are still setuid 0, but now have additional
>restrictions placed on them by elfcap.
I've used such systems in the past, and I've tried hacking them. Without
physical possession of the system it becomes very close to impossible
(at the time, even the NSA hackers didn't get in).
It is coming (at least as an option).
>You also seem to be arguing that administering such a system would be a
>pain, because you need new tools to look at the capability lists. This
>is also true for your pet proposal of keeping them in the filesystem, as
>none of the fileutils will know how to get this information.
The only reason it is a pain is that it is not possible to locate those
executables that have elfcap set capabilities. Capabilities should be
cleared whenever the executable is written. Even the setuid bit should
be cleared, and I count that as a weakness that it isn't done now. It
IS a common weakness.
><flame>
>I've seen many e-mails by you blathering on, and not one of them seemed
>to have a valid point. I'm tempted to killfile you, but I'm having too
>much fun laughing.
glad to provide some entertainment.
>The only way I can think of you as a reasonable person is if you think
>that elfcap is meant to handle restricting capabilities. That is how it
>is implemented, but it is meant to handle raising capabilities.
></flame>
I am a bit paranoid (the systems I try to protect are high target items).
>Another mechanism for forcibly lowering capabilities would be nice
>and useful, and I agree that it would need to be stored outside the
>binary. I don't think the inode would be a good place though, as that is
>traditionally under the control of the owner (save atime), and this is not.
That is one of the reasons the inode entry, or in-memory, versions are better.
I like the inode since the inode is NOT accessable by the user, any more
than the in-memory version. The advantage the inode entry has is the
filesystem database is already designed to control access, and capability
(I consider setuid and sticky bits to be capabilities).
>Further, this is (should be) per-executor information. Surely you can
>imagine two people on the same system wanting to trust a given binary
>differing amounts?
To a limited degree. The security administrator is the one that has to
approve of the executable in the first place, the secondary person
has less to say about it.
As a side note that may explain part of my position -
I don't like privileged root - too many people tend to get it just to
do things that should be delegated:
tape handling, batch job control, print control, resource allocation
user support and security control
The current "standard" UNIX has no way to delegate other than by setuid
programs which are difficult to get right.
I have used "trusted facility management" - Cray UNICOS with the TFM flag
set, which removes root as a privilege source. Root only owns most of
the binaries in the system, but cannot assign capabilities since it has
none. The security manager account is responsible for audit control
(separate from SYSLOG, and records anything that the kernel considers
a security "event"). The security manager account assigns the capabilities
needed for all other executables (and users), BUT it cannot add executables
to root controled directories (must have write access).
This creates a separation of duty. root for managing most of the files
that support the system, security admin for administering the security.
They work together to create new kernels (capability called "install").
Configuration files that control security are labeled by the security
admin to prevent root from modifying them.
Delegation is accomplished by collecting the capabilities that are needed
to perform the various rolls that are still missing: operator, user support,
and users.
operator - shutdown the system, queue management, resource
control
user support - switch user (debugging help), user login
administration (sometimes, but not to include
security administrator, root, or operator..
cannot assign privileges to users...)
users - no special capabilities
User support is the hardest to delegate because it is the hardest to
define.
-------------------------------------------------------------------------
Jesse I Pollard, II
Email: pollard@cats-chateau.net
Any opinions expressed are solely my own.
-
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:12 EST