Linux security non-modules and AppArmor
Posted Jun 28, 2007 4:54 UTC (Thu) by jamesm
Parent article: Linux security non-modules and AppArmor
There's more to this than pathnames. Unfortunately, an important issue that has been lost in discussions is that of security architecture.
SELinux is a security framework. It's not simply one particular security model, but an architecture for composing different types of security models in a coherent manner.
It is analogous to the VFS or the networking stack, rather than a specific filesystem or network protocol.
One of the outstanding issues with AppArmor being merged upstream is how it relates to the kernel's security architecture. The idea with SELinux, from the start, has to been to extend the old Unix DAC model with an extensible framework, to allow Linux to accomodate a wider variety of security models (such as RBAC and TE).
One key concept with this framework is that it is "policy flexible". That is, it implements a clean separation of mechanism and policy. So in addition to supporting multiple security models, each of these can be deployed in a manner suiting a wide range of requirements (including notions of "good enough" security which allow simpler policy).
Another key concept is re-use of mechanisms. The policy, auditing, labeling and enforcing frameworks are cleanly abstracted so that different types of security models can be integrated into the overall framework. Policy for the entire system can be designed and analyzed in a complete and coherent manner, while a consistent set of APIs and abstractions are provided to applications, and a common set of libraries and tools are used for development and management.
Note that the literature shows that composition of different security models is a potentially dangerous area, and that subtle and entirely unexpected security issues can be introduced without appropriate overall control. LSM cannot thus be thought of a scheme for security module compostion, as it lacks any common infrastructure: it's just a large bunch of hooks littered throughout the kernel. OTOH, SELinux was actually designed to do this in a way that allows the resulting compound security policy to be fully analyzed. And by design, I mean the result of decades of advanced (NSA) research, with prototyping in several OSs followed by volumes of technical analysis. What we see with SELinux is simply the decsion to transfer the results of all of this work into a general purpose operating system, and the fact that it was done upstream in Linux should tell you something about the level of clue.
Anwyay, without going too deeply into the design, I hope I've now established the idea of SELinux as a security architecture and some aspects of its bona fides as an architecture.
The problem, the deep problem we face now is that as long as LSM remains, SELinux will remain as "just another" security module, and it will never be considered a first class component of the kernel. Kernel developers will forever have to deal with the weak semantics of LSM, without understanding what is supposed to be going on behind the hooks, and quite understandably, not bother thinking too deeply about extended security. SELinux provides much stronger semantics as an in-kernel API, and can provide a consistent conceptual model for general kernel developers in the same way that the existing DAC code does now. Related is the user experience, where again, application developers, sysadmins and other technical folk will generally see extended security as an optional pluggable idea with weak semantics, that they will continue not to buy into because of this.
Linux needs to provide clear semantics and conceptual models; be it security, networking, filesystems, drivers or pretty much anything where different types of models can be deployed.
If we continue the analogy of the network stack: imagine that a decision had been made years ago to make the whole stack pluggable. What we would have now, I believe, the network kitchen-sink from hell, with no underlying design or consistency. We'd likely have merged every bad idea to make it into a thesis or marketing brochure: sysv streams, TOE, hare-brained and half-assed research projects, and enough snake-oil to power the world for a decade. And who would bother maintaining it all?
It simply would not have been possible to develop systemic network improvements such as Netfilter, IPsec, advanced routing & traffic control, nor would there be a foundation for the performance work applied across the stack, or for genneral infrastructure improvements that people have been working on recently.
To put it another way, we would not have been able to evolve what is arguably the best network stack ever. Recall Van Jacobson's comments on it at LCA06: "The people who take care of the stack know what they're doing and do good work", "... Linux has the fastest and most complete stack of any OS". With the LSM approach, this is never going to be said for Linux's security core.
Further imagine how pluggable stacks would have played out at the distro level, and where it would leave the users in terms of compatabilty and consistency with Linux networking. It would also be unsupportable upstream:
"Routing doesn't work! I add the default route and everything stops."
"Uh, which network stack are you using, and is it even in the kernel?"
"I don't know :'-(" <- note, user crying
I think we're about to make this mistake with security: by not adopting SELinux as the security framework; by avoiding real architectural discussion; by allowing technical issues to be framed politically; and by not listening to people who know what they're talking about.
to post comments)