On Tue, 31 Jul 2001, Crispin Cowan wrote: > Valdis.Kletnieksat_private wrote: > > > On Tue, 31 Jul 2001 13:46:01 PDT, Crispin Cowan said: > > > The "simple assurance" property is something that David Wagner and I value > > > highly. It is the idea that if there are only restrictive hooks (see amazingly > > > long preceeding discussion) then logic errors in a module cannot result in > > > system security breeches that are worse than what would happen without the buggy > > > > Or phrased differently, you want "fail-closed" rather than "fail-open" in case of a > > module *bug*, but are *not* worried about actual *malicious* code. Am I reading > > you correctly here? > > Yes, you are reading me correctly. > > > > > * Do something to get the pure simple assurance property back. This is > > > likely to be brutally difficult, as it will involve change call-by-referece > > > interfaces into call-by-value interfaces, which is highly unnatural in C. > > > Not recomended. > > > > Worse than that - you need an entire marshalling scheme, because you may be passing > > in a struct by value that contains pointers to other structs, so it gets VERY ugly? > > VERY ugly. I think we can stop convincing ourselves that option 1 is not > acceptable. I just listed it as something that is obviously desirabe but not > attainable. It is the straw man against which other proposals are measured :-) > > > > > * Shrug. Ok, so the simple assurance property is not as simple as we would > > > like. Tough noogies :-) We still get a measure of bug tolerance from the > > > strictly restrictive nature of the LSM interface. > > Bug tolerance is a good thing.. > > That was the motive behind the "simple assurance" argument in the first place. IMHO, > it still applies, but in light of JMJ's observations, it applies less than it did > before. > > > > OK... riddle me this: Do any of the various contingents have security models/plans > > that would *not* be recast in terms of authoritative hooks (possibly in conjunction > > with internal programming style guides such as "always set EPERM first, and clear > > it if it SHOULD be allowed")? Are all flavors of permissive/restrictive doable via > > authoritative, or is there some subtle issue regarding hook placement/etc? "Riddle This" thoughts are extremely valuable to me. :) > > Here's some hook placement issues that do come up, following a discussion with Chris > Wright: > > * MAC/DAC sequence: making the hooks authoritative means universally doing the > DAC checks first. To be authoritative, the hook must be the very last thing > checked before access proceeds. SGI may not like this. Well, with regard to avoiding DAC checks if MAC checks fail, you're probably right (request more specific response from SGI), but with regard to audit needs, I think Casey previously said something like "we can live with this, but it's not optimum." More specific SGI statement of opinion is needed. > * Being fully authoritative: there are code paths where an early DAC check that > fails short circuits out of the kernel. With our current hook placement, we > won't catch all of those short circuits out of the kernel. Therefore, the hooks > won't really be universally authoritative, unless we go place a lot more hooks. > Chris is unsure of how many additional hooks would need to be placed. Seems obvious: stop it from short circuiting and force it to the hook. Only means the hook should be placed instead of a "return", unless I misunderstand. This/these places are a special case that should be considered as seriously as anything else we've considered. > > 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 > 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 : Tue Jul 31 2001 - 17:36:25 PDT