On Mon, 4 Jun 2001, Titus D. Winters wrote: > I still maintain that the way to go here is to push it all into the module > and make the default module contain the current kernel logic. > > The points I would like to make are: > > 1. Political difficulties should not be considered in the design of > software. Anyone that says otherwise is trying to avoid a flamewar. > Personally, I'd rather fight the flamewar battle personally and let > someone else do the development if that's what it takes to get it done > right the first time. I don't understand this argument. I don't mind flamewars, but LSM is worthless to us if it is not accepted into the Linux kernel. So we have to consider how acceptable our solution will be to the Linux kernel developers. We also need to limit our scope or we will never get anything done. Many of the participants in LSM only need a set of hooks to be added that allow them to enforce additional access control restrictions. The capabilities logic can be moved out of the kernel simply by changing the guts of the capable() function and the capability processing in execve and the capability system calls to call hooks. That also allows other modules to implement permissive behavior in the same way as capabilities (Someday, it would be nice to have finer-grained permissive behavior, e.g. process in domain D can override discretionary read restrictions on files with type T, as in DTOS, but that isn't on the critical path). We don't really need to change the existing capable() calls - we can simply insert new hooks calls where needed. Auditing can be supported through appropriate post- hooks. Where's the real argument for moving all of the base logic out of the kernel? Identify exactly what project needs it, and why it can't be supported adequately through separate hooks (including the capable hook for permissive behavior). I can't see us devoting resources to such a significant effort when it doesn't provide any benefits for our security modules and it doesn't help our case to the Linux kernel developers. -- Stephen D. Smalley, NAI Labs ssmalleyat_private _______________________________________________ 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 : Mon Jun 04 2001 - 11:15:30 PDT