jmjonesat_private wrote: > On Thu, 26 Jul 2001, Crispin Cowan wrote: > > > int rv1 = 0, rv2=0; > > > > > > if (... in-kernel check fails...) > > > rv1 = -EPERM; > > > > > > rv2 = security_ops->hook(rv1, ...); > > > > > > if (rv2) return rv2; > > > if (rv1) return rv1; > > Allowing the module to override a restriction with a permission is precisely > > what makes it an authoritative hook. > > Yep. This suggestion does NOT allow the module to override a restriction > with a permission that will return to the kernel. Look again... that's > the ONLY advantage of my suggestion over Dr. Wagner's. You're right. My apologies. I mis-read the code. > I admit some > disadvantages... like more lines of code in the kernel side of the patch. > It gives the module information, but leaves logic in the kernel that does > NOT allow permissive override. It is rather complex. If we go with the macro approach to hooks, then it might be feasible, but even then it is scary. This code snippet has two local variables and is stateful. That makes it rather tricky to implement and use safely in a macro. Crispin -- Crispin Cowan, Ph.D. Chief Scientist, WireX Communications, Inc. http://wirex.com Security Hardened Linux Distribution: http://immunix.org Available for purchase: http://wirex.com/Products/Immunix/purchase.html _______________________________________________ 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 : Fri Jul 27 2001 - 15:08:58 PDT