|
http://lwn.net/Articles/239962/
Long-time LWN readers will know that the Linux security module (LSM)
API is
controversial at best. To many, it has failed in its purpose, which is
enabling the development of competing approaches to hardened Linux
system;
the only significant in-tree security module remains SELinux.
Meanwhile,
the LSM interface is easily abused; since it allows the insertion of
hooks
into almost any system operation of interest, it can be used by other
modules to provide non-security functionality. The LSM symbols are
mostly
exported GPL-only, but it is still possible for binary-only modules to
abuse the LSM operations - and, apparently, some have done so.
SELinux hacker James Morris has been pondering this issue recently; he has also noticed that the in-tree security modules (SELinux and the small module implementing capabilities) cannot be unloaded. So, he asked, why implement a modular interface at all? He has posted a patch which turns LSM into a static API with no exported symbols. With this patch applied, any needed security "modules" must be built into the kernel; there is no longer any way to add them at run time. There have been a few complaints, but, from your editor's point of view, it does not seem like anybody has come up with a compelling reason why it must be possible to unload security modules. Instead, it has been pointed out that maintaining a coherent security state in the presence of unloadable modules is nearly impossible. So this patch would appear to have reasonably good chances of being applied. The only question, perhaps, is whether the developers feel the need to provide an extended warning period for developers and users of out-of-tree security modules. One such module is AppArmor - the GPL-licensed security mechanism distributed by Novell. AppArmor has remained out of the tree for a long time while its developers have tried to address the various comments which have been posted over the years. A new AppArmor patch has been posted; many things have been fixed, but one of the core points remains: AppArmor still uses a pathname-based mechanism for its policy enforcement. This approach sits poorly with developers - especially those in the SELinux camp - who think that pathnames are an inherently insecure method. In their view, the only truly secure way to control access to objects is to put labels on the objects themselves. It seemed that this dispute had been resolved at the 2006 kernel summit, where it was determined that the use of pathnames was not enough to keep AppArmor out of the kernel. That has not stopped people from complaining, though, and those complaints redoubled when another pathname-based approach (TOMOYO Linux) was posted recently. If AppArmor does get into the mainline, it will have to be over the objections of developers who feel that is providing false security to its users. Andrew Morton appears to want to resolve this issue and get it off the mailing lists; he sees two alternatives: a) set aside the technical issues and grudgingly
merge this stuff as a service to Suse and to their users (both of which
entities are very important to us) and leave it all as an object lesson
in how-not-to-develop-kernel-features. [...]
b) leave it out and require that Suse wear the permanent cost and quality impact of maintaining it out-of-tree. It will still be an object lesson in how-not-to-develop-kernel-features. It seems that Andrew would rather not be in the position of delivering object lessons on how not to develop kernel code by whatever means; he concludes with this request: Sigh. Please don't put us in this position
again. Get stuff upstream before shipping it to customers, OK? It ain't
rocket science.
At the 2006 summit, Linus took a clear position that the use of pathnames for security policies seemed reasonable to him. Given that, along with the fact that AppArmor is being widely distributed, and it seems that, sooner or later, this module should find a home in the mainline - even if it is no longer in modular form.
Linux security non-modules and AppArmor Posted Jun 27, 2007 22:54 UTC (Wed) by jamesm (guest, #2273) [Link] 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.
|
