>> No, not "Q.E.D." at all. This is idiotic. All options have major flaws.
>> That includes filesystem support, the sticky bit, PGP...
>
> Please elaborate...
You are simply blind to the huge flaws in your pet solution.
I only claim that the flaws in my solution are tolerable.
> 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.
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.
>> 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.
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.
>> * Insecure sticky bit hacks
>> * Incomplete or ugly setuid-root hacks
>
> Exactly!
You do get a choice between incomplete and ugly. You can embed UID info
in the executable if you wish.
>> * Inconvenient VMS-like hacks
>
> Yep.
>
>> * Inefficient PGP-based hacks
>
> Double yep.
All of the above are important options. Nothing is obviously the best.
Every admin should get to choose tradeoffs that are appropriate for
their local environment.
I could see running PGP-signed executables off of an otherwise untrusted
server when a more trusted server is unavailable.
>> 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.
BTW, the above is starting to look like FUD. Stick to the facts please.
-
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/