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
<[email protected]>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
