On Fri, 13 Jul 2001, Chris Wright wrote: > i agree that a broken module is a broken module is a broken module. yes > it's all kernel code. i think crispin is referring to the simple > assurance property being...even if i really screw up my own access > control logic i am not making the kernel any less secure than it was. > and the only way i can really screw things up (besides the fact that i > have access to all of kernel memory) is in the capable call. this isn't > failsafe meaning if i dereference a NULL pointer i will failsafe, this > is more like i won't give away the farm with one bad logic error. > (kinda hand wavey i know, it's friday evening ;-) This "simple assurance policy" is not necessarily true. Saying "no" is not always the best way... for example a "let 'em into a honeypot area until we figure out who they are" sort of strategy. Example, the Ramen Virus/Worm. There's not much to be lost by letting it in, telling it that it has planted the /dev/.lib files and that the rc.d files have been changed. It may take 3 or 4 or 5 consecutive combinations of change to "trip" the security... and permitting the first 2 or 3 or 4 will let you identify the beast. Of course, you don't commit the file changes while you're looking, but "permissive" is useful/necessary here "to catch a thief"... and while other means may suffice in this specific case, the future holds other examples. The ability to say "yes" (and lie) is a very powerful ability. > > > > I'm betraying a certain naivete as regards the kernel political process, > > I'm sure, but I would like to see as eventual goals of this project the > > ability for an _administrator_ (not a module creator or kernel hacker) > > to implement policy on his system by integrating (potentially several) > > modules, each one capturing some portion of the intended policy; the > > ability for an administrator to use security modules from (potentially) > > many different sources _at the same time_; the ability for an > > administrator to use particular modules at different points (read: the > > ability to gracefully load and unload modules without effecting other > > modules). These goals point to an expanded effort along the lines of > > JMJs chaining, but also to an abundance of hooks admitting of > > permissiveness as well as restriction. > > this is a fine goal. we are trying to focus on mainline kernel > acceptance. linus has already voiced a strong opinion against module > chaining. we provide a mechanism to support it that essentially > offloads all of the hard parts of module compostion to the module > developer so that it is not inherent in the kernel code. I agree it's a fine goal and that module stacking begins to address it. Linus, being an intelligent person, will evaluate his opinions against stronger arguments and modify them as he goes through his life. Any intelligent person does: this process is called "acquiring wisdom" and I have faith in Linus to abandon opinions when there is proof they may be incomplete. He hasn't failed us before. Don't worry about Linus, or even, more abstractly, the "Kernel Developers"; worry about your proof. Linus ain't stupid, but he IS smart. Are we working for Linus, or working WITH Linus for Linux? Are we trying to get just a "yes" or actually an LSM that is RIGHT? > > cheers, > -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 : Tue Jul 17 2001 - 15:04:43 PDT