>> You are simply blind to the huge flaws in your pet solution.
>
> What are they, please? I do know that metadata capabilities are disruptive
> to the userspace. I also know that a capability-secured Linux distribution
> _will_ have to go through some pain in userspace anyway. Why not do it in
> one large step instead of several small ones?
Linux distributions will _never_ take that step. That just kills it.
There is little reason to add security features that will not be used.
>> I only claim that the flaws in my solution are tolerable.
>
> I claim interim solutions should be out in anything that wants serious
> consideration as a security measure.
You might as well give up any hope of enhanced security in that case.
>> Daemons really aren't interesting. They are started in exactly one way
>> from exactly one place, without any worry about a hacked environment.
>> There are no untrusted ancestor processes to worry about.
>
> If I can run named(8) from my account, I can do what I want to the
> environment of the resulting process. Besides, if I can exploit a buffer
> overrun or some other security flaw, I'm home free if the daemon isn't
> secured.
If you run named, it will fail. It would not get the privilege it needs.
Assuming you can still overrun it before the failure... who cares?
You get to crack into your own account.
>> Since daemons have such nice properties, I can execute them in any
>> odd way I please:
>
>> /sbin/usercap named NET_BIND_SERVICE /usr/sbin/named
>>
>> That was very easy and quite boring.
>
> What does usercap(8) do, exactly? Concentrate on how it verifies that this
> is a legitimate run.
Init scripts need some property (any property) that an admin login
does not have. That should not be hard to arrange.
> Does named(8) always have to be run this way?
Sure. Change runlevels if you want to start or stop named.
> What happens if I run named(8) with the wrong capabilities by accident?
Eh, how and why would you do this? For maximum UNIX compatibility,
something really bad should happen when an admin makes a mistake.
> Now multiply by a dozen daemons on the typical system. Then add in the
> stuff launched from inetd(8).
This is all trivial. Linux distributions can ship with it ready.
You should not have to bother with starting daemons.
>>>> Our choices include:
>>>>
>>>> * Incompatible filesystem hacks
>>>
>>> Nope. ext3 will always be compatible with ext3. You can't expect ext2 or
>>> VFAT or NTFS or NFS or CODA to be able to handle highly sensitive binaries
>>> if they don't handle capabilities sensibly, so there isn't a problem there
>>> at all.
>>
>> You are brushing away some _serious_ problems. You would completely
>> throw away all hope of compatibility with everything.
>
> Not "all hope". I agree that much compatibility would have to be abandoned,
This will never be accepted. Imagine the screams if Red Hat were to
ship a system that was totally incompatible with UNIX. It won't happen.
> but there have been no arguments that convince me that there is a way
> around it, nor a list of exactly what would be affected and how.
>
> I see the following compatibility problems:
>
> (a) All software that manages installation of files and such. That will have
> to change anyway.
> (b) All software related to backup/restore, as far as it handles security
> sensitive data or binaries.
> (c) All system daemons
(d) All filesystems, including non-Linux ones like NFS.
(e) You can't even disconnect the network cable and have the system
owner (with full rights anyway) boot an old kernel.
Gee, the setuid-root hack has no such trouble.
>> You might as well in fact run NT. It has a capabilities system and it
>> includes filesystem support for security features. After all, you are
>> willing to throw away all UNIX compatibility.
>
> No, I'm not. But the issues have to be considered carefully if we want a
> Unix-like system with capabilities, particularly how much Unix we will have
> to sacrifice in the end for capabilities. Perhaps it's not even worth it,
> who knows.
It's not even worth it, unless you can keep enough compatibility for
a normal Linux distribution to add the enhancements.
>>>> As I've said before, we don't have to choose one. We can let the admin
>>>> choose zero or more hacks for each mounted filesystem. One only needs
>>>> a way to indicate trust. For a vendor-supplied CD-ROM, that might be
>>>> everything on the disk. Some people may trust anything owned by root.
>>>
>>> Please. This means including _several_ incompatible kludges into the
>>> system, that interact in unknown ways, to make it "more secure"?
>>> You can't be serious.
>>
>> I am serious. You are free to choose the zero option. Disabled features
>> don't interact very much.
>
> Zero option _does_ interact, as using capabilities is a change that is (by
> its nature) very invasive to the whole setup. And several options that
> might be on or off independently just give rise to a auditor's (tester's,
> developers, sysadmins', ...) nightmare through combinatorial explosion:
> There are at least 4 different ideas here (SUID + headers, Sticky +
> inmutable, extra "is capable" bit, full capabilities in metadata), this
> gives 16 different combinations when turned on and off.
The auditor says "no way, choose one" if he needs to. (but he does not)
The situation isn't really so bad. You don't get a combinatorial
explosion, because nearly every option does the same thing. Either
an executable is trusted or it is not. This is a boolean. It does
not matter why the executable is trusted.
If both filesystem support and a "root-owned is trusted" hack are
used together, and they are found on the same file, you could do:
a. Choose the filesystem data.
b. Choose the executable data.
c. Choose the subset of bits.
d. Choose the superset of bits.
e. Prevent execution and log the event.
>> BTW, the above is starting to look like FUD. Stick to the facts please.
>
> I try to. But as soon as I ask for clarifications, there seems to be just
> handwaving.
Some things are just unimportant.
Example 1: Scripts are unimportant. Linux already ignores the setuid
bit for security reasons. Obviously it would ignore capabilities too,
for the same security reasons.
Example 2: The ability to be setuid to non-root with capabilities is
unimportant. We can't do that RIGHT NOW, so complaining about the
failure to provide such a feature is as silly as complaining that
the /proc filesystem allows covert channels. (and if it really matters,
there is an ugly way around the problem)
There are other examples. One must hand-wave away the useless noise.
It is a waste of bandwidth to answer all the silly little challenges,
many of which have been asked multiple times.
-
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/