Re: [PATCH] Version 3 (2.6.23-rc8) Smack: Simplified Mandatory AccessControl Kernel

[James Morris]

On Sun, 30 Sep 2007, Andrew Morton wrote:

> So with the information which I presently have available to me, I'm
> thinking that this should go into 2.6.24.

I think the decision to merge Smack is something that needs to be 
considered in the wider context of overall security architecture.

Smack itself looks fine.  It seems like clean code with interesting ideas, 
and appears to be based upon sound principles.

Merging Smack, however, would lock the kernel into the LSM API.  
Presently, as SELinux is the only in-tree user, LSM can still be removed.

LSM's weak semantics and pervasive deep hooking of the kernel means that 
we'll have to continue dealing with several unpleasant issues, such as the 
abuse of the API by out of tree vendors, with a proliferation of 
binary/proprietary modules which typically maladapt the API for arbitrary 
purposes and/or use dangerous techniques.  We will continue to waste 
resources maintaining this capability for them.

On a broader scale, we'll miss the potential of Linux having a coherent, 
semantically strong security architecture. I have written about this in 
some detail before: http://lwn.net/Articles/240019/

Briefly, SELinux is a security architecture.  It provides an extremely 
high degree of flexibility, in terms of both the types of security models 
implemented, and security policy for those models.  It allows controlled 
composition of different security models, with a common policy language 
framework, allowing the entire system to be analyzed.  The same ideas and 
even code can be reused beyond the kernel as post-DAC security is extended 
into databases, the desktop, distributed applications etc.  It is a 
framework which provides a structured, coherent view of the security of 
the OS (and ultimately, the entire distributed environment).

If LSM remains, security will never be a first class citizen of the 
kernel.  Application developers will see multiple security schemes, and 
either burn themselves trying to support them, or more likely, ignore 
them.
 
Core kernel developers will continue to not have enough information to 
understand what the LSM hooks in their code are supposed to be doing, 
leading to long term maintenance issues and potential security problems.

LSM will remain a magnet for bad ideas.  There's a reason we don't have 
pluggable network stacks, and we are lucky to have had a unified 
networking framework maintained by people who know to say no to things 
like STREAMS and TOE.  I would question whether this quality of 
maintainership would exist if the networking core was simply a bunch of 
deep hooks into which people dumped arbitrary custom stacks.

LSM will prevent us from making systemic improvements to security, as 
there will be no common security architecture.  Things like Netfilter 
would not have been viable with a kernel which simply provided a bunch of 
hooks for networking stacks and an assortment of implementations.

Much of this we have learned from the experience of LSM, and I think it 
has been valuable for that, but I think we need to consider now whether we 
are going to continue down this track in a permanent manner.


- James
-- 
James Morris
<jmorris@xxxxxxxxx>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/