On Wed, 6 Jun 2001, Stephen Smalley wrote: > > On Wed, 6 Jun 2001, Chris Lundberg wrote: > > > Chris (Other Chris): Move kernel logic into a default security module. > > Chain (or in some VERY restricted cases replace) onto that default module > > for everyone elses modules. > > Could you clarify what you mean by "kernel logic"? (Same question to > each person who is advocating moving the kernel logic into the modules). At the risk of losing the advantage of vagueness, here's my definition: Any logic that is specifically in the kernel to impose security restrictions or permissions (capabilities or DAC, or anything else) should, logically, revert to the SM in LSM. Putting ALL security into the module concentrates it in one realm, thereby 1) focussing the interested eyes on that realm and 2) relieving the core kernel developers from having to "think it through" by "pushing" it to the LSM. Political reasons now suggest to me that "purely" pushing this is not advisable. Practical reasons (allowing us to leverage Linux-Privs) remain the same either way, imho, since if we+Linus "t'rew it all out" we could move the Linux-Privs project to a module, where we can also leverage it. > For example, does "kernel logic" include all >500 calls to capable(), > including cases where capable() is called by itself rather than > being in compound logic? Or would you be satisfied simply to > have the compound logic statements plus the guts of the capable > function in the module, leaving many of the simple capable() calls > unchanged? Also, what part of permission() constitutes "kernel logic"? > Is it just the vfs_permission logic? What about when the file system > implementation defines its own permission routine for its inodes? > Does "kernel logic" just mean the call to inode->i_op->permission, > or does it mean all of the permission routines in the various > filesystem implementations? Simply, in my mind, leave the functionality in the kernel. Any check of any kind that was there for SECURITY PURPOSES, bounce to the module. UID checks, EUID checks, PID checks, CAPABILITY() checks, anything else. Security is not "functional" it's a decision on if the function should be allowed. If (forbidden || not-permitted || the-old-way) does nothing for functionality except limit it, the whole "permissive" thing is relative to the pre-existing intrinsic kernel security, and if you move it ALL out, you get restrictive only (with difficulties in verification.) > > -- > Stephen D. Smalley, NAI Labs > ssmalleyat_private > I see how the "total" argument is politically unsupportable. But I'd like to keep as MUCH of it as possible in the "core design" of the LSM interface, leaving the implicit option later to move more and more and more... satisfies my philosophy AND current needs. J. Melvin Jones |>------------------------------------------------------ || J. MELVIN JONES jmjonesat_private |>------------------------------------------------------ || Microcomputer Systems Consultant || Software Developer || Web Site Design, Hosting, and Administration || Network and Systems Administration |>------------------------------------------------------ || http://www.jmjones.com/ |>------------------------------------------------------ _______________________________________________ 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 : Wed Jun 06 2001 - 11:01:02 PDT