I've spent (nearly) the last two days looking at the new patch as closely as I can (I'm sure many are grateful for my relative silence.) It seems more workable to me than the previous patch. Authoritative combines the needs of audit, permissive, and restrictive. I'd think if we move to restrictive-only we need to come up with a general solution for permissive and audit, as well, even if it largely "remains to be implemented." This will add more potential hooks into the core-kernel, but dramaticly clarifies the placement of hooks and their function, and presents the *possibility* of something like a "grep" verification. If the 10 calls that were changed to add kern_retval in dummy_ are truely representative of everywhere the kernel has an opinion that we can grab, then the kernel is much less opinionated than I'd thought :), and the impact is quite minimal. Capabilities, really, are a "security solution that landed in the core kernel in the pre-LSM primeval soup". I think pulling as much of it out of there as we can and settling it on the OUTSIDE of our interface evolves it into the paradigm we're trying to develop, and allows it to be more easily discarded... or enhanced in the future. If it had been centralized in the first place, it wouldn't be the problem that it is. Since it wasn't, it's now spread throughout the "body" of the kernel-creature, and leaving it there just makes it more likely to grow and change and bite us in the butt in the future. Intercepting capable() and moving everything BEHIND it possible to a module seems to be "the best of the bad choices", to me... including any kernel side data structures. Doing it now is difficult, but doing more later may be much MORE difficult, and having it in a module allows an easier excision. Allowing module stacking that can recapture that functionality also simplifies module composition in the "do no harm" case. I am very concerned about leaving the kernel "less secure" in the event the LSM module load fails. If we concentrate capabilities, or anything else, we should make sure it loads if the kernel loads. This argues, in my mind, for concentrating it into security.c (as dummy_ or default_) or some intrinsic part of the kernel, for now. I can see too many scenerios (including, but not minimally, admin-error) that can result in a "worse off" kernel, at present. Heck, let me be the "dumb?ass"... when I ran the first benchmarks, I forgot to insmod capability_plug.o... anybody willing to bet the ranch that I'm not the only one who will make that error? Protect we idiots. JUST READ DR. COWAN'S COMMENT... Divide and conquer. To get a "grep test" level of ease-of-verification, you either have to impose a return value that can be scanned in the module or divide the interface to it's four basic components: capabilities, restrictive-only, permissive-only, audit, I think. Mixing apples with oranges the way the "authoritative" model does pushes all of it to the module side, imho. I hope you can come up with a better solution... I just don't see one. Even separating into 4 subinterfaces and linking "authoritative" to 3 of the four, with some kernel side "result enforcement" improves the situation somewhat. An authoritative function can return "permissive" and rely on being blocked by the interface if it's in a restrictive context. Elegance be darned, we've thought through the issue largely, let's preserve that thinking in the interface, somehow. 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 : Thu Jun 14 2001 - 11:21:46 PDT