On Fri, 8 Jun 2001 jmjonesat_private wrote: > 1) where there is no logic accessable a kern_retval that > reflects "what the kernel would have done, > Pass a "kern_retval" item that reflects this. Things could > change in the future with kernel-side / LSM API side > co-evolution and we NEED to know on the LSM API side. > Perhaps, to be explicit, #define -ENOKERNOPINION or something or > a global variable KERNELSECURITY in the "manner" of errno without > passing anything? Tighten up where and what, somehow. I don't see any real value here. If you want to always pass a kern_retval for consistency in the interface, then I'm willing to go along, although I don't think it is necessary given the inherently diverse nature of the hook interfaces. But if there is no kernel decision to pass, then you should pass zero, just as in the case where there was a kernel decision but it authorized the operation. > 2) *Always* pass, even if it's "no opinion", a kern_retval. I can go along with this suggestion, but I don't think it is necessary. > 3) NEVER include a LSM function call explicitly in compound logic in > the core-kernel. No argument here, except for existing usage of capable() and permission(). > 3) If we can't clearly place a single "compound authoritative" function, > separate it into two functions. A concrete example, please? > 4) Wrap the functions in security_ops that employ this > method, somehow, so we COULD add other subinterfaces > in the future, example I still don't see this as useful. Also, keep in mind that the entire security_ops structure may be flattened at some point to eliminate the extra level of indirection. > 5) For GODESSES'S SAKE, protect security_ops SOMEHOW, or this API is only > e pluribus unum and vulnerable to "total replacement" from ANYWHERE > in kernel space. Provide a "non-functional copy", provide a module > check for revelation, SOMETHING. The idea of a global export just > seems to introduce too many new vulnerabilities. As others have already said, this doesn't introduce any new vulnerabilities. -- Stephen D. Smalley, NAI Labs ssmalleyat_private _______________________________________________ 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 Jun 08 2001 - 13:35:27 PDT