On Fri, 16 Jun 2000, Aaron Denney wrote:
>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/.
Thats what I thought.
>
>> 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...
All it takes is a chmod go-r to create one. I as a user would not
be able to see the elfcaps then.
>
>> >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.
It might be extnsible, but there may be no unused header fields. That
would make it nonportable.
>
>> >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.
Should be, but it isn't now. Minor complaint about the current setup.
>
>> >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.
Most utilities don't care. Or do you have something special in mind?
The only utilities that I can think of that would be usefull with
knowlege of capability bits are "ls" and "find". And I don't see a
problem with having two versions of ls/find - say lsc and findc (easy
to type...).
>> >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*
oops - I screwed up. I REALLY screwed up.
>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.
That is true currently - and having the user able to set the setuid bit (or
sticky bit on a directory). I have found a "make" package that got distributed
with a trojan within the install procedure - it gave the make executable
setgid. Fortunately, this was found in a users directory so it didn't/wasn't
installed by root (or suddenly make would have been setgid to sys...)
>> >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.
In the end, it is the management that determines the security policy.
It is up to the system to be able to enforce what management decrees.
>
>> 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.
1. Very little - the major overhead seen has to do with the audit log.
It tends to grow very fast when full logging is enabled (17 MB/minute
tested - Crays are very fast - every syscall, every write,.... done only
for demonstration).
2. None of it can be done in userland, since that allows for it to be
bypassed through user/operator error. It is a B1 capable (without
the mathmatical validation) system.
3. When the TFM is enabled, a root shell does allow for a denial of
service, but any attempt to modify security tagged files is logged
and blocked. What has happend (due to a root level operator error)
was that the system chose to shut itself down. It did take a couple of
hours to fix (system was up on the backup root while the damaged root
was rebuilt).
4. Lets see,,, there are eight, but I use only use the first six:
setucat - set active capabilities for current process
spset - set capabilities on files (devices too)
spget - decode full capability list (includes MAC labels too)
udbsee - show full user database (passwd record + resource control
and security labels) a very extended shadow file support
udbgen - set user database entries
reduce - able to read the audit log
auditd - the daemon that records the audit logs
select - sets the audit events that will be logged
There are two more, but those are only used during a system installation
from source, and they have to do with setting the initial privileges
on the above executables (must be done in single user mode I think).
Now there are the daemons and plain old su (su must be capable of setuid)
The daemons (telnet/ftp and friends) get capabilities to setup a user
but these, and login, are going to be changed anyway (mostly via PAM).
rshd/rlogind should be modified in the same way. I am assuming the
model includes user authorized, active, and inheritable capability sets
>It's not the model you want, but it is a step forward. And it is a
>mostly compatible step forward.
Oh yes, it is definitely better than current. It just has what I consider
severe drawbacks for continuing advancement. I know SGI wants the finished
product to undergo some level of validation and certification.
-- ------------------------------------------------------------------------- Jesse I Pollard, II Email: pollard@cats-chateau.netAny 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:13 EST