I have just been asked for advice on whether SE Linux is Linux specific, and therefore whether code related to SE Linux should always be stored with other Linux specific code instead of being in the main branch of certain free software projects.
One example of SE Linux access controls being implemented on a different OS is the work to port SE Linux to Mac OS/X. Here is a paper on the topic presented at the SE Linux Symposium 2007, and the main site is at http://sedarwin.org. One thing I have been doing is trying to get some friends interested in doing similar work for GNU Hurd (there are some similarities between Darwin and HURD so the work done on Mac OS/X “Darwin” will help the HURD effort). I believe that The HURD has the potential to offer significant security benefits due to the micro-kernel design. One significant problem area in computer security is kernel security flaws, if the kernel can be split into a set of independent processes that run with minimal privileges then the scope of such problems is dramatically decreased – and the possibility of upgrading parts of a kernel on a live machine is provided. As people such as Linus point out there is a performance overhead to micro-kernels, but most machines are idle most of the time anyway. I believe that reliability and security are more important than getting the last 10% of system performance for most machines. The success of Xen is evidence that features other than maximum performance are desired.
Another example of SE Linux access controls on a non-Linux platform is the MAC framework in the TrustedBSD project. This implements SE Linux access controls on top of FreeBSD. From reading the documentation it seems that the amount of changes required to the SE Linux code base for implementation on TrustedBSD was significantly smaller than the changes required for Darwin.
Sun is also apparently considering adding type-enforcement to Solaris. It’s yet to be seen whether this happens and if so whether it is compatible with SE Linux.
So it seems that a significant portion of the SE Linux code base is portable, and in particular the user-space code should port well. The interfaces for and methods labelling files etc should port well between platforms. Therefore I recommend not having SE Linux code split into Linux specific trees and instead having a compile option to enable SE Linux support.
[…] Is SE Linux only for Linux? » This Summary is from an article posted at etbe on Thursday, August 30, 2007 I have just been […]
Hello,
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.
could the reference policy be reused?
Marcus: The paper about the SE-Darwin work which was presented at the SE Linux Symposium reports that they had to do a lot more work than would be required for a monolithic kernel OS (such as Linux or FreeBSD). This extra work may differ from what is requrired for the HURD (I don’t know enough about either system to determine this), but it would surely be some benefit over the previous situation of only having SE Linux code for a monolithic Linux kernel.
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.
Hi Russell,
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
About performance: I am not going as far as saying that “Servers are easy”, but servers typically have a relatively static configuration and load. Take as a counter example the interactive desktop. Say I am using a soft-phone, and then start up a video editor, or “locatedb” thinks its time to update its database. Then for a pleasant user experience you still want to have quality of service guarantees for the soft phone. Now, for VoIP it’s not too hard because that is not I/O bound at all. But if you have two concurrent I/O bound operations, like locatedb and video editing, you are in a tough place.
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.
[…] una piattaforma non specificamente orientata a Linux bensì basata su codice BSD. Coker si dice particolarmente soddisfatto della portabilità del codice SELinux in quanto, leggendo la […]
http://www.tuxjournal.net/?p=722
A comment at the above post has an English translation of the original TuxJournal post.