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:-
| Peter Zijlstra | Re: Problem with ata layer in 2.6.24 |
| david | Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3 |
| Bart Van Assche | Re: Integration of SCST in the mainstream Linux kernel |
| Andi Kleen | Re: [patch] Add basic sanity checks to the syscall execution patch |
git: | |
| Johannes Schindelin | Re: git on MacOSX and files with decomposed utf-8 file names |
| Junio C Hamano | Re: [PATCH resend] make "git push" update origin and mirrors, "git push --mirror" ... |
| Morten Welinder | Re: [Census] So who uses git? |
| Steven Grimm | Segmentation fault in git-svn |
| GVG GVG | ssh_exchange_identification: Connection closed by remote host |
| frantisek holop | nptd regression in 4.2 |
| Josh Grosse | Re: Real men don't attack straw men |
| peter | ntpd not synching |
| Jim Winstead Jr. | Re: Root Disk/Book Disk Compatibility |
| Dong Liu | Re: CXterm for LINUX |
| erc | HARDWARE COMPATIBILITY LIST |
| Douglas Graham | Re: Buggy omit-frame-pointer? |
