> From: Crispin Cowan > > Christoph Hellwig wrote: > > LSM does have a careful design. The design goal was to permit loadable > kernel modules to mediate access to critical kernel objects by user > level processes. By providing such a facility, LSM enables arbitrary > security policies and policy management engines to be implemented as > loadable modules. This solves the "make one size fit all" problem of > diverse interests lobbying Linus to adopt one security model or another > as the Linux standard. The LSM design saves Linus from having to make > such a choice by allowing end-users to make their own choice, meeting a > goal stated by Linus nearly two years ago. ==== A security model that mediates access to security objects by logging all access and blocking access if logging cannot continue is unsupportable in any straight forward, efficient and/or non-kludgy, ugly way. LSM is a collection of hack & hooks thrown together in an ad-hoc manner to support those people who were able to lobby their specific security policies. Some security people were banned from the kernel devel. summit because their thoughts were deemed 'dangerous': fear was they were too persuasive about ideas that were deemed 'ignorant' and would fool those poor kernel lambs at the summit. Also unsupported: The "no-security" model -- where all security is thrown out (to save memory space and cycles) that was desired for embedded work. LSM also doesn't support standard LSPP-B1 style graded security where mandatory access checks are logged as security violations before DAC checks are even looked at for an object. At one point a plan was proposed (by Casey Schaufler, SGI) and _\implemented\_ (team members & prjct lead Linda Walsh) to move all security checks out of the kernel into a 'default policy' module. The code to implement this was submitted to the LSM list in June 1991. This plan was shot down as "too radical". It wasn't what the "kernel programmers" wanted. "They" would never accept it and therefore, LSM wouldn't accept it without prior approval from the "kernel programmers". When such approval was sought, the seeking party was drawn and quartered for having the temerity to actually ask the question (since asking the question pointed out the failings of LSM to meet its original design goals). > > >The real problem is adding mess to the kernel. > > > Christoph's problem is likely that he doesn't like the design. Fair > enough, can't please everyone, but a lot of effort went into that > design. --- True...alot of effort went into building the Titanic as well. The modular security model was implemented via macros and cleaned up the logic of the kernel code by moving toward single exit points that could allow consistent release of acquired data structures and locks depending on where failure occurred. That alone made the code more readily understandable and maintainable. Removing security policy from the code into separate modules also made validation of security considerably easier. So...of course, it wasn't wanted. LSM may implement some number of policies, but it is neither robust nor easy to use. Only recently was it decided not to require that every security module to know about every hook. That was also suggested almost 2 years ago because the current setup makes the implementation of security policies *MUCH* more complicated...and, theoretically, inherently less provably secure. l. walsh _______________________________________________ linux-security-module mailing list linux-security-moduleat_private http://mail.wirex.com/mailman/listinfo/linux-security-module
This archive was generated by hypermail 2b30 : Sun Feb 09 2003 - 19:04:06 PST