On Wed, 6 Jun 2001, Stephen Smalley wrote: > > On Wed, 6 Jun 2001, Chris Lundberg wrote: > > > Oi! That is a bunch of stuff to think about... My basic stance, from a > > theoretical, nonimplementational point of view is that all of the logic in > > the kernel should be able to be overridden completely, and that the > > cleanest way to do it in the long run is have the kernel take care of the > > work, whereas the security modules should take care of _all_ of the > > questions as to whether or not it is allowed. > > This sounds fine if you are writing a new kernel. It doesn't sound > so good if you are modifying an existing kernel that is being > actively developed by many different developers (with a variety > of forked variants) and actively used by many applications that > depend on certain assumptions about the basic security model. > > It sounds like you're taking the most extreme position. Replace > all calls to capable() and permission() and all DAC logic with > calls to security hooks. Move the complete implementation of > permission() into the module, including filesystem implementations > of the inode permission routine. One thing you may not have > thought of: moving the attributes used by the base logic into > the opaque security blobs maintained by the modules, e.g. > real uid, effective uid, file system uid, saved uid, > ditto for gids, group set. Of course, that means moving > all code that uses those attributes into the modules, > which also affects things like accounting and quotas. All, permissive, restrictive, capabilities, quotas, accounting, share a common goal... to impose restrictions on functionality. If there were NO restrictions, we'd end up with "Windoze" :) Permissive, restrictive ... are "during the fact", capabilities are "permissive before the fact" quotas are "restrictive before the fact" and accounting is simply "hey, what happened?", although it may feed back to more "positive" security... either the admin or the module. Combining these needs "willy-nilly" in a compact solution implies cost in one area where it doesn't need to be in others, unless you stack modules in such a way to let the cost be "determined" by the implementation. > > This doesn't seem reasonable to me as an approach for LSM. > I suppose there may be some middle ground, e.g. replace > calls to capable() with calls to hooks when we want finer-grained > support, move vfs_permission into the module but leave the file system > inode permission routines in the file systems, and move the DAC > logic into the hook functions when we can colocate the hook calls with > them. YES. Let's find the "most minimal middle ground" and run with it. There's a lot of brain-power here. We *can* come up with an "optimal" solution. I've never been more sure of anything in my life. Let's put more weight on "clever" and less on "easy." My experience is that Linus sees 23 levels farther ahead than most people and, as a result, will buy a "better solution" over a "less-better". > But I'm uneasy about the resulting mixed model, and > I'm not sure it is preferable to my proposed model. Admission: I'm not SURE either, but, if a better model arises in the next week or so, I think it's to all our benefit. As far as it being "mixed", my argument for separating it out with different hooks "unmixes" it, I think. If it doesn't, let's come up with a model that DOES. > > -- > Stephen D. Smalley, NAI Labs > ssmalleyat_private > 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 - 12:53:35 PDT