On Sat, 1 Sep 2001, Greg KH wrote: > On Sat, Sep 01, 2001 at 06:46:36PM -0400, jmjonesat_private wrote: > > I don't have any specific response to this assertion, but, respectfully, > > ask for someone (even Greg ;)) to clarify "the direction LSM is heading", > > hopefully with regard to: > > My opinions: > > > 1) authoritative hooks: YES, NO, CONDITIONAL (how?) > > No. I've already talked about why I feel this way. Please see the > archives. 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. > > > 2) DAC bypass (as an option), YES, NO, CONDITIONAL (how?) > > Do you mean the MAC before DAC discussion? > Personally I don't care. But I like the current DAC before MAC > implementation that LSM seems to follow. I mean DAC (or, more accurately, IN-KERNEL checks) should execute and then provide the result to the module, which can return a code that is authoritative, if desired. This allows, ummmmm, not bypass, but override. While this is not optimum for my project, it is acceptable. My module can replicate the DAC logic and add it's own "spin", and make a decision based upon that code... and log the discrepancy against the in-kernel logic accordingly. I don't know how LSM can support this without SOME authoritative hooks, but, then again, a set of "DAC decision" hooks that simply record the result but don't allow override might be between the two positions. If the current "decision/consensus" is restrictive_only, that answers my question. I don't think this is the case, unless the "consensus" is weighted according to individual. > > > 3) Support for loadable modules NOT compiled into the kernel (I've > > seen some "not an issue because we're suggesting compiling in" > > discussions that have short-circuited (perhaps not intentionally) > > issues that may be relevant to allowing a module to slide into > > a system that has run for a while before the module is loaded. > > > > YES, NO, CONDITIONAL (how?) > > Yes. This support is there right now. You just have to get the logic > correct in your module, being able to handle the tasks and other objects > that were created before your module was loaded. Yes, and No. Tasks may run before the module loads and some of the "rebuttals" toward void blobs have been aimed at "it doesn't matter" with the "compiled in" consideration. I'd think that a mechanism to init blobs reliably without conflict would be a consideration if this support was to be applied. I admit I haven't looked "very closely" at the patch with this regard... our prototypes assume that a NULL is an un-allocated blob and don't deal with locking. We DID see locking as a consdir-able issue and hoped it would get more discussion. Of course, if others have progressed farther and determined it to not be an issue, that's the power of open development, and we are grateful. > > And if you want to recommend that your module be compiled into the > kernel (like SELinux does) that's your option. Yes, that's true, but is a little "smelly" of one-module-think. I am one, and I think there are others, thinking along lines of stackable/loadable modules that can rise and fall. If LSM is really SSM (standard security module) and we're developing a standard, let's name it such... it might be easier to sell. Sorry, a little overboard for this list. > > > I'm dealing with developers in my project that insist that it may be > > necessary for us to "branch", and create a patch that removes LSM and > > reapplies a specific patch to the kernel to address our functionality. > > I'd rather not go that direction, but a few things that may be necessary > > are probably going to need a "plus-patch", and some other things that are > > admittedly possible, but require significant "manipulation" with the > > current patch may be better done with "plus-patches." > > A branch of a patch, and I thought I had heard of everything :) > Fine, all the lsm work is opensource, and if it doesn't meet your needs > in certain ways, feel free to change it for your own usages. Just > respect the current license and everyone will be happy. The LSM project has explored and implemented an excellent solution to a variety of modules/policies. There have been several mentions of policies and modules that may be "going left." I can see that the "big names" working here wouldn't need some of the "leftward" options, but I readily admit that WE are working on one, and don't believe that we're the only ones. Perfect Solution: LSM addresses our needs. Moderate Solution: LSM addresses most of our needs, and we apply a very small patch to extend it to our needs, which, hopefully, will be considered in Stage 2 or Stage 3 (or whatever) by LSM. Extreme Solution: remove LSM and apply our own patch. I don't think this should be "evil" to the big-interests here... since they all have had to apply proprietary patches to date. > > Did this help? > Yes, very much, but I still hope for other responses... if for no other reason than to coordinate and agree-by-consensus some of these points for LSM > thanks, > > greg k-h > 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 : Sat Sep 01 2001 - 16:27:28 PDT