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)
> > 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.
> > 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.
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.)
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.
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.
<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.
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>
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.
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?
-- Aaron Denney -><-- 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:11 EST