Okay, I'm beginning to be overwhelmed with the options again, so let me summarize where we are (for my own benefit) and see if I've got it right. A) There is clearly a desire to support restrictive-only, restrictive-permissive, and permissive-only (possibly) modules with the LSM interface. B) Nearly everyone agrees that, in *some* context, the pre-LSM kernel security logic must be preserved exactly as is... somewhere. C) The main "bone of contention" seems to be where "somewhere" is, and if it is to be "required" or "optional". Some wish to keep it in the kernel and add the module results to the logic in the same manner we have it now. The problem with this approach is that you create a logical conundrum by having to decide if it's AND or OR, NAND or NOR when inserting the module results into the logic. Because much of the logic supports the "dually" permissive/restrictive capability_plug, this muddies the waters. Some think that dividing the hooks into two sets of hooks, one permissive, one restrictive, all in the kernel, is the answer. This complicates the interface, but, as Mr. Wagner points out, it doesn't have to make too much of a mess if the implementation is clever. Some would rather move the existing logic out of the "kernel proper" to a shared space. The options here seem to be a shared source code library, a stackable module, or something-inbetween (flip-flop kernel logic?). I think the "leave it ALL up to each individual module" has somewhat died in committee. D) Considerations relevant to the "where issue" are verification, acceptability and accessability to the kernel developers, and points of philosophy. Chris Wright gave us a clear list of 3 possible solutions. Can somebody refine it, now, to a list of fewer-than-five options that we can, perhaps, use to form a consensus and start moving forward again? Have we actually eliminated any of the original three, or just merged them back into a continuum of "some of one, some of another, a little of factor X"? I do better on multiple choice tests than essay questions. 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 : Mon Jun 04 2001 - 06:28:32 PDT