Yes, I think Crispin has succinctly summed it up: irrevocably closing the LSM prevents commercial customers from using security modules other than that provided by their Linux distributor. As Sarbanes-Oxley and other regulatory laws require these customers to use "standard kernels", the result is a rather dreary form of vendor lock-in, where the security framework is coupled to the distribution. Though it would require a somewhat undesirable complexity of CONFIG_ flags, it should be possible to construct flexibility enough for everyone to get what he wants. For example, it should be possible to configure kernels with a single security framework hard-linked, AND it should also be possible to configure kernels such that the default security framework could be completely replaced at boot time by another, be it out-of-tree module, or other. I agree entirely that preserving this form of freedom for the end user makes Linux a much stronger technology than not. For one thing, the consequences of closing LSM are fairly certain to irritate enterprise commercial customers, which is probably a sign that the technology has taken a wrong turn. Tommy F. Crispin Cowan <crispin@crispincowan.com> wrote:-
| Len Brown | [PATCH 05/85] ACPI: Add "acpi.power_nocheck=1" to disable power state check in pow... |
| Andi Kleen | [PATCH] [2/50] x86_64: use core id bits for apicid_to_node initialization |
| Greg KH | [GIT PATCH] driver core patches against 2.6.24 |
| Andrew Morton | 2.6.23-rc1-mm1 |
git: | |
| Gregory Haskins | [RFC PATCH 06/17] ioq: Add basic definitions for a shared-memory, lockless queue |
| Arjan van de Ven | Re: [GIT]: Networking |
| Jarek Poplawski | [PATCH] pkt_sched: Destroy gen estimators under rtnl_lock(). |
| David Miller | Re: mac80211 truesize bugs |
