Chris Wright wrote: >Of course, to date, this is exactly the type of thing that has been >called policy and punted to the security module. The framework is >intended to be as thin as possible (read: dumb) and pushes all sense of >policy to the module. > I agree with Chris. LSM was designed to push as much policy as possible out of the LSM interface itself and into the modules. This design was deliberate, precisely because of a lack of consensus as to what the nature of security policies should be. LSM's goal is to provide a common API for access control policy engines, not to provide any policies of its own. As is, LSM is already capturing a great deal of common work that used to be duplicated among many security enhancing systems, in that they do not each have to implement and chronically forward-port their hooks into the Linux kernel. To further capture common function, the obvious solution is for modules to share code. Many modules are GPL'd, so you can just copy and modify them as you see fit, so long as your resulting module is also GPL'd. Further, there is the Stacker module, which is intended to allow more than one module to be loaded into the kernel at once. This allows one module to depend on another to implement needed functionality. Your proposals sound like worth-while policies to implement as a module, although I confess I do not yet fully understand them. But they definitely do not belong in the LSM interface. We have gone to a lot of effort to keep the LSM interface policy-neutral. Crispin -- Crispin Cowan, Ph.D. Chief Scientist, WireX http://wirex.com/~crispin/ Security Hardened Linux Distribution: http://immunix.org Available for purchase: http://wirex.com/Products/Immunix/purchase.html
This archive was generated by hypermail 2b30 : Mon Nov 04 2002 - 22:14:08 PST