On Wed, 6 Jun 2001, Chris Wright wrote: > * jmjonesat_private (jmjonesat_private) wrote: > > On Wed, 6 Jun 2001 sarnoldat_private wrote: > > > > I have 4 > > > > security_ops->capabilities > > security_ops->restrictive > > security_ops->permissive > > security_ops->audit > > > You still have not convinced me that there is an value in splitting the > restrictive and permissive hooks apart like this. I am strongly in > favor of a single hook with authoritative control. Okay, I'll give it one more minimal try. By splitting the structure, you achieve uniformity in the implementation, separating the different areas currently under debate. By giving ONE hook PERMISSIVE or RESTRICTIVE control, not AND, you can argue assurance in any module with a restrictive service function but no permissive service function using a variation of Dr. Cowan's "grep" utility. You allow "more permissive" "more restrictive" "totally permissive" and "totally restrictive" modules without necessarily implying more overhead to one or the other and enforce it in the logic that remains in the core kernel. By imposing symmetry in the structure, but not in the current implementation, you allow more hooks in the future to implement any unimplemented controls at the cost of 8 or 16 bytes (depending on how long a pointer is) and clarify the API so programmers know EXACTLY what is allowed as a return. You clarify, for argument, the placing of any hook, and avoid (largely) having to "meld" our logic into the core kernel. BTW, I like Stephen Smalley's idea about reverting some of capabilities and excising some other places, leaving the "capable()" call as our main "hook". At least I *think* that's inherent in his proposal. Capabilities are a pain, just because (I think) the designers didn't argue to conclusion the points we're discussing now, and unless you move them ALL to "permissive", where they're also a pain, but centralized and potentially discardable. I think, unless you move the kernel logic (see previous post) out to the module and make the entire interface "restrictive only", this is the clearest route to both "most general" and "most flexable". if we end up with security_ops->capabilities security_ops->restrictive security_ops->audit from here, we leave open the possibility of adding "permissive" later, but it costs 4 or 8 bytes and some "thinking", and slipping it in now means we have a mechanism for "forward progress." I'll gladly apply resource to the "thinking." > > -chris > 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 : Wed Jun 06 2001 - 12:36:38 PDT