On Sun, 2 Sep 2001, Crispin Cowan wrote: > Greg KH wrote: > > >On Sat, Sep 01, 2001 at 07:25:03PM -0400, jmjonesat_private wrote: > > > >>I had not thought this was the "policy", at this point, but rather had > >>believed that SGI was reviewing "some authoritative" and had responded > >>positively to a limitted application. > >> > >>If it's a complete "NO", I will procede forward based on that. > >> > >Come on people. We went over this months ago. > > > JMJones was correct in labeling this issue "conditional": that is > precisely what was decided at the BOF: SGI would demonstrate the > viability of authoritative hooks as a solution to a variety of their > problems by showing what additional patchwork would be needed to make > the authoritative hooks "authoritative enough" to address their needs. > > If SGI did this, for some problematic cases, and the solution isn't too > gross, then we'll go authoritative. Otherwise we revert to restrictive. This seems a wise strategy. I believe that SGI has commented positively on "some authoritative." No desire, here, to sink the ship with "non-demonstrably-useful" authoritative hooks. I reacted (perhaps too "instinctively") to Greg's assertion that this is not the way that LSM is going... it MAY be, partially, and with major trepidation, the way SOME hooks MIGHT go, if there's a demonstrable usefulness that outweighs the cost. With regard to submission of patches, I now realize that submitting the restrictive_only instead of the authoritative case (whichever is SMALLER) is probably the smart way to go... let's argue the NEED to go bigger, rather than the size or type. As far as SGI's feedback, I have seen messages that say "some useful", others "nominal", and the information I have is that this is acceptable to my advisors mechanically, if not philosophically. > Here I fully agree with Greg: if it is vitally important that your > module manages all processes, including those that run before modules > are loaded, then it is your problem to either walk the process table and > do something about it, or opt to compile in your module. I agree that it is vitally important that a module manages all processes, therefore, I believe it is a "common concern" that LSM should have a mechanism to so do. If it's doable from the module side (as Greg's subsequently posted code suggests), then it need not be intrinsic in the interface, but a discussion of it, and, perhaps, a documented example, is beneficial. > > 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 > > Please note that I do NOT believe EVERYTHING possible needs to be addressed explicitly in the LSM interface. I *do* believe that everything *noted here* needs to be evaluated fairly deeply before we abandon support in favor of the the "smallest/least intrusive" method. If there's a mechanism already existing "below the surface" to implement, then rejection is appropriate. Slow, But Not Unreasonable, 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 Sep 04 2001 - 12:19:52 PDT