On Fri, 27 Jul 2001, Greg KH wrote: > On Fri, Jul 27, 2001 at 02:42:24PM -0700, Crispin Cowan wrote: > > > > 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. > > Actually at the LSM BOF at OLS yesterday, Peter Loscocco reminded me > that Linus had said at the 2.5 kernel summit that he wanted the hooks to > not be macros or #ifdefs in the code. So the macro approach for hooks > will probably not happen (not that we were thinking it would.) > > greg k-h I remember this comment from the summit, and am not sure if it was aimed at not allowing #ifdef SUBDOMAIN, #ifdef SELINUX, #ifdef JANUS, #ifdef OTHERPROJECT, or if it was aimed at rejecting clearly functional build-time options. Regardless, I think we need to put forth ONE and only ONE interface that addresses as many legitimate security paradigms as possible, without preferring one over the other. I suspect, respectfully, that if this argument was between SubDomain and SELinux, an accomodation would be very high priority, and would be reached. Ergo, if we're going to put hooks in two places, I think we should clearly differentiate between them in the interface. OBVIOUSLY, if we only do after-check functions, the information is redundant and not necessary, but I strongly believe there are before-kernel and after-kernel issues that belong in Stage I, especially if we're going "restrictive-only". Richard Offer eloquently summarized the options. I don't like the IFDEF option he listed near the end of his post... but I *DO* see the need for the *ability* in the interface to "short circuit" the in-kernel checks if the module so desires. Modules with no need (or no desire to allow) this functionality can just return 0 (permit) to the prekernel restrictive only hook and "bad programming" can't return a permission that would stop the in-kernel checks permissively... which would preserve the "simple assurance" argument as I understand it (and I won't get into discussing if this argument has any true value or not.) If we can't get authoritative, dual hooks are a good solution, imho. Also, to circle back again, differentiating them in the structure allows "simple grep" verification... security_ops->prekernel->hook security_ops->postkernel->hook I have heard that there's another project dealing with ACLs, but I wonder if these are NOT Linux Security and if they ARE, shouldn't we give some thought thereto? Respectfully, 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 : Sat Jul 28 2001 - 15:05:27 PDT