On Tue, 31 Jul 2001, Crispin Cowan wrote: > Here's some hook placement issues that do come up, following a discussion with Chris > Wright: I assume this is the list of concerns to which you referred. I apologize if it is not. > > * 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. Stage I "sales-worthiness" requires this. I don't LIKE it, but I haven't seen any argument that pushes it over the fence to "well, we gotta do it now", other than "it's the right thing to do", which would sell ME, but is a bit vague, imho, to build a consensus on: right and wrong being contextually variable things. Of course, the KD's may slam us against a wall and ask why we didn't do this. Something to consider, even briefly. Especially since we've said it here and they're almost certainly listening. If this interface fails to get accepted (a real possibility), we're all hosed. I think resolving the DAC/MAC MAC/DAC issue NOW is impossible, and while it's an important issue, authoritative hooks lay the groundwork for solving it later... the magnitude of "later" being arguable. > * 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. "unless we place a LOT" vs. "unsure of how many additional". I see a few places where we might have to add hooks, maybe more than a few but far less than a "lot". I'm not convinced the "new" hooks will outnumber the current ones. Small modifications to the kernel code that concentrate the results with a jump will probably suffice, or just scanning for returns and placing a hook there that "processes" the return value in many places. Something fewer than 100, I think (that being the current number of new hooks required to implement a before AND after model.) Maybe FAR fewer. There are 400 people on this list. If we move to authoritative, require each evaluate 1/4 hook... the manpower is minimal. :) FLIPPANT, I know, but I suspect a few will dig-in to re-locate many, thereby relieving most of the community of the effort. (( In Essence: Sorry Chris, We'll help all we can. )) > > 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 > Sincerely, 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 Aug 01 2001 - 15:54:39 PDT