A comment at the above post has an English translation of the original TuxJournal post.

What kills you in such situations is *not* the overhead due to message passing. It’s the fact that you don’t even know where to send which messages to, because resource usage is heavily decentralized and the small core does not know which resource is associated with which activity, and thus can not even apply good heuristics. Reliability and security concerns restrict the number of feasible protocols further to a very limited set.

There is something intrinsically global about re-balancing the shared system resources, that does not lead itself easily to compartmentalization and isolation. The main known solutions to these problems involve real time strategies that lead to dramatic underutilization. Our (new, untested) approach is more conservative: We retain global control about resource distribution and just try to allow users to define more involved policies than what is currently provided by Unix-like kernels (see the papers on walfield.org). If that is sufficient, remains to be seen.

not sure if this is the ideal channel to discuss these things. I hope we can chat about this over a beer sometime ;)

The paper “Security-Enhanced Darwin: Porting SELinux to Mac OS X” describes mechanisms, but does not suggest policies. I can’t see how they can exploit the described mechanisms to formulate sensible policies (that doesn’t mean it isn’t possible, I just can’t see it from reading the paper). But then, I have studied capability systems extensively while I paid little attention to ACL or RBAC systems. Take for example the following claim: “This port send right permits the owner to start and stop the task, kill the task, manipulate the memory space and otherwise administer the task. [...] The SEDarwin project must include additional non-bypassable security mechanisms to prevent misuse of Mach IPC services.” A typical response to this from a capability-mindset would be that instead the granularity of object capabilities was chosen wrongly in the first place. If this answer is correct or not is impossible to tell without knowing what security policies should be expressable and enforcable.

The Hurd itself uses capabilities and ACLs (the latter mostly to control filesystem access, but note that the filesystem is de-facto the global name space for all widely accessible objects). A principal is identified by a capability that is associated with labels in the authentication server. That auth server provides a three-way handshake protocol for a capability exchange: The client can get a capability from the server (indirectly via the auth server) and the server gets the labels the client holds from the auth server. But note that no policies are enforced centrally, instead, servers are responsible for implementing any policies themselves. And clients can delegate authority discretionally. That particular mix is also not without problems, so we are playing with other possible solutions as well. But most of our attempts go into the direction of relying *less* on access control lists, rather than more of them, by changing the granularity of object capabilities and modifying the system structure to adapt.

Can you point me to some basic papers on SE Linux, not about mechanisms, but about policies: Which policies are desired to be expressable and enforceable? Maybe if I understand better what use cases the SE Linux crowed is trying to support I can understand better why you think this is important, and if (or how) these use cases are relevant/addressed in the Hurd.

Thanks,
Marcus

Rest assured that I know how difficult it can be to determine security boundaries.

I agree with your point about peak performance. However again the peak performance is much greater than needed for most applications. I have recently been installing a number of small server machines and using second-hand P3 machines. No-one manufactures new machines that give low power use while still having the basic server features (such as RAID). Old P3s provide more than enough power for that application, and as they will be used for years without much in the way of upgrades the more security options the better!

Fernando: With some modifications. I believe that the TrustedBSD people added extra capabilities which required some minor changes.

A couple of remarks: The current version of the Hurd uses GNU Mach, so it shares with Darwin Mach as a common historical ancestor. That’s as far as the similarities go. Work on Mac OS X/Darwin has zero impact on the Hurd, which is a multi-server system, while Mac OS X is single-server as far as I know.

It is true that a multi-server design based on a microkernel has potential security advantages (as well as other potential advantages, like quality of service guarantees). These advantages have been realized in embedded systems and special purpose systems several times now in the last decades. It is, however, unknown if these advantages can be scaled up to general purpose desktop and server systems. By the way, separating the system into multiple components is not enough to reduce the impact of security flaws. You also need to actively reduce the reliance set of components and impose tighter recovery boundaries, something that is easier said than done. Success is not automatic. Kernel security flaws are important, but in practice most problems seem to come from application failures these days. Except for device drivers (see Microsoft’s Singularity efforts), but those are more a reliability concern than superficially a security concern.

It is a grave mistake to think that because most machines are idle most of the time, performance considerations can be ignored. Most people do not need to care about average performance, but they care very much about peak performance. And good peak performance under varying system loads is a very hard problem, and it is even harder if the system is decomposed into many isolated components. Fact is that there are only a few strategies known to deal with this problem, and none of them are fully satisfying.

Xen supports a few select very specific usage scenarios (virtual hosting, mainly) which appeal to some huge commercial interests. Xen’s success falls short of supporting evidence for microkernel-based system strategies beyond virtual hosting.

None of this applies directly to SE Linux. Traditionally, microkernel systems have been associated with the capability based authentication rather than access control lists, for some good reasons.