* Stephen Smalley (sdsat_private) wrote: > > On Mon, 4 Jun 2001, Casey Schaufler wrote: > > > I guess that's my point. Sure, you can kludge it up > > so that it sorta works the way you'd like in this case, > > but it sure ain't generally useful. > > I'm merely limited by the existing capable() interface, > which doesn't pass object information for relevant objects. > Of course, we could propose extending the capable() interface > (thereby allowing our capable hook to also pass object > information, thereby allowing our modules to implement > the kind of functionality I would like). But that seems > like something that should be pursued separately and > not something that we should depend on for LSM. In a sense that's the direction of the current code. Many calls to capable are replaced with hooks that provide modules with relevant object information. We've already discussed the pros/cons of a generic hook interface, I'm not confident we could come up with a nice looking extension to the capable interface without splitting it up into calls like cap_fowner() instead of capable(CAP_FOWNER). But even with this, you get the heinous offender, CAP_SYS_ADMIN which is the catch all and I think the interface would require a bunch of void pointers. I think if we want to consider supporting permissive policies, we should plan for it right now. -chris _______________________________________________ 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 - 18:53:21 PDT