On Fri, Jun 16, 2000 at 09:25:42AM -0500, Jesse Pollard wrote:
> 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....
s/run as root/run with those capabilities raised/.
> 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).
If you can't read the executable, you can't install it. Unreadable
binaries should really not be supported...
> >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.
This is a valid point. Being tied to one executable format is bad. But
ELF is designed for extensibility. I can't imagine any format which
would replace it not being as extensibile.
> >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.
Yes, setting capabilities is not restricted. But, having the system pay
any attention to them is restricted. So you audit on making a binary
setuid root... Never let root log in, and have trusted binaries to let
certain groups perform what administrative tasks are necessary. It ain't
MAC, but it is an improvement on the current common situation without
too much upheaval. Note: changing the capability list is a write to the
file, so will clear the setuid bit.
> >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).
Eventually yes. It also totally incompatible with 90% of the utilities
out there. It will be a while before it is a viable 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.
Set, no. Ones that matter will be a subset of those that are setuid
root. Writing an extension to find will be necessary whether we store
capability lists in the inode or in the executable.
> 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.
The setuid bit *is* cleared on write.
4$ touch foo
4$ chmod +x foo
4$ chmod u+s foo
4$ echo "write" > foo
4$ ls -l foo
-rwxr-xr-x 1 wnoise users 6 Jun 16 13:14 foo*
At this point, the capability list, while not cleared, becomes a
mere suggestion to the admin that the binary only needs the listed
privileges.
> I am a bit paranoid (the systems I try to protect are high target items).
> 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).
And the owner of a file can set the setuid and sticky bits. The raw
inode isn't accessable by the user, but almost every field is.
> >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.
Right. Culture clash. I want my users to get use out of the system, you
want your user's to be secure even when they are actively being stupid.
I think that is a quixotic goal. Security always comes at the expense
of usability, so must be a tradeoff. And far too often usability is
destroyed for minimal or no security gain.
> 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.
Oh, I totally agree. I see capability lists as a way to get setuid
programs closer to correct.
> [ snip description of TFM in unicos ]
All very nice. How much kernel support is necessary for this situation
though? Why can't this all be done in userland? Don't let anyone get a
root shell. Have a bunch of binaries to grant the required caps to the
proper people, and which log everything.
It's not the model you want, but it is a step forward. And it is a
mostly compatible step forward.
-- 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:13 EST