> > Please elaborate...
> 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?
Besides, the base conception (What capabilities are needed?) pain isn't
over yet, and the discussion on how to structure userspace and the needed
tools hasn't even started in earnest
> 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.
> > We aren't talking "normal Linux systems", we are talking "capability
> > secured Linux systems" here. What makes you think that nobody would ever
> > run named(8) as user named, group named, so it (via normal permissions) can
> > only read the zones for which it is responsible (and nothing else!), while
> > named-xfer(8), running as user named-xfer can write over the ones it is
> > slave server for, but nothing else? The daemons today run as root because
> > currently it is the only way to get the capabilities they need.
> 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.
> 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. Does named(8) always have to be run this way? What
happens if I run named(8) with the wrong capabilities by accident?
Now multiply by a dozen daemons on the typical system. Then add in the
stuff launched from inetd(8).
> >> 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,
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
(b) means tar(1), cpio(1), and their ilk; possibly also stuff like cp(1).
Most of the change would be "simply" to make them capability-aware (i.e.,
find out current capabilities) and do the system calls to restore them
afterwards. I haven't looked at the sources, but I'd guess they do handle
permissions in some centralized way when restoring, the same code should be
quite easy to extend to handle capabilities too. For tar(1) and cpio(1)
there are file format issues to consider. But somebody here said HP used a
cute trick: The file foo appears twice, the first version is just
capabilities which HP's tar(1) interprets and others simply overwrite with
the file itself during unpacking.
(a) and (c) I don't see any way around. Rest of the stuff (the bulk of what
makes up any system) should not need any change at all, AFAIKS.
Plus, you need special tools (a la chmod(1) or some such) for managing
capabilities.
How do other capability-aware Unices do this? What do the relevant
standards say?
> 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.
[...]
> >> 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.
> 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.
-- Dr. Horst H. von Brand mailto:vonbrand@inf.utfsm.cl Departamento de Informatica Fono: +56 32 654431 Universidad Tecnica Federico Santa Maria +56 32 654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513
- 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/