Other Topics [BOF Notes]

jmjonesat_private

Just to put a few thoughts/ideas out of thread (not sure I 
know where they all should be put.)

1) Making hooks authoritative and providing them with the 
   DAC decisions solves my problems.  With that said, 
I don't really CARE where DAC resides.  I am building a 
stackable module group, not a single monolithic solution.

1A) where it's particularly impossible to do this, the short-circuit
    solutions (depending on implementation) seem good.  Mr. Smalley's
suggestion of applying capabilities to this purpose is interesting... will
it ALWAYS work?

2) I'd RATHER DAC not have to be determined before mymodule
   (MAC?!?!) gets the result.  I'd much rather be able to build a DAC
module and interleave that with my module-family.  Since a few minutes of
sampling suggests these checks are pretty trivial (cost/impact-wise), and
my thought is that preserving them will be common case for a few years,
leaving them in-kernel for "Stage I" (I don't think there's really such a
plan, but to reference the "now" case) is acceptable to my solution. 

3) I still see restrictive-only as being a valid "policy".  I hope that
   the solutions presented don't inhibit that, and will build a "single
stage" (non-multiplexing, but stacked) solution, that I will release
freely and can be used to impose this.

4) I still don't see a "hard need" for an int in security_syscall, but I 
   believe (if it's only convention and not *enforced* in the patch) that
the cost is nearly-zero and, since it's needed by more than one solution,
not wrong.  Also, since we're talking 2 or 3 "functional" arguments, and
my world is largely i586, I don't see it has any arguable performance
impact to add it.

5) Is it really a binary decision for LSM-OUT patching or LSM-IN?  Would
   an intermediate solution (patching LSM-OUT where valuable but leaving
it IN in the "standard" kernel) be a totally ridiculous strategy? 

   I come down firmly between greg's opinion and stephen smalley's
   position on this point.

6) A hard "no" on moving kernel logic out seems a little extreme, to me.
   For the purpose of discussion, can we separate DAC from MAC some way
and  define OAC as "in-kernel logic that would have to be left if we move 
DAC out but not in-kernel".  I think I may be arguing for two different
things.  I don't want to leave "bloody stubs" (sorry) in the kernel, but I
think there are checks that are logically mobile without leaving such.

7) I think Ted's advice is good and shouldn't be dismissed lightly.

Again, I am concerned about providing an interface that is truely general
to competing strategies.  I think that the MORE general we end up, the
MORE likely Linus will accept it... and the MORE likely he'll trust us in
the future to argue out conflicts.  

--------

I am encouraged by the notes that Crispin posted about BoF, and very
encouraged about some of the results being incorporated, but I am still
confused about a few things. 

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