David Wagner wrote: > > Stephen Smalley wrote: > >I would suggest that a number (but not all) of the LSM hooks > >need both pre- and post- hooks so that the module can both > >authorize/deny the operation and maintain state. > > I agree. My experience seems to agree with yours: Janus uses > post-hooks in a few places to maintain state. > > Note my proposal earlier for special cases of hooks: > int check_foo(args); // pre-hook, for checking policy (can return -EPERM) > void before_foo(args); // pre-hook, for maintaining state > void after_foo(args); // post-hook, for maintaining state > Much of the Janus functionality falls into some combination > of these three simple categories, without needing interposition > in full generality. I agree as well, although I believe that anywhere a decision is made, then enforced, a post-hook is necessary for things like auditing so that the eventual result can be recorded if so desired. Regarding the check-foo and before-foo hooks, I like this too because it gives a "hooker" (as someone so eloquently put it) a chance to mix policy decisions. (e.g. policy A says deny the request, but policy B says it's OK). We gather up the decisions in check_foo(), then enforce them in before_foo(). I can see mixing capabilities and some sort of MAC in this way, with capabilities allowing MAC bypass. Scott _______________________________________________ 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 : Tue Apr 24 2001 - 12:28:56 PDT