Re: File descriptors: LSM should support them in phase 1.

From: Crispin Cowan (crispinat_private)
Date: Wed Jul 25 2001 - 17:18:03 PDT

  • Next message: Crispin Cowan: "Re: MAC before DAC vs DAC before MAC"

    "KRAMER,STEVEN (HP-USA,ex1)" wrote:
    
    > Exactly.  The SGI folks appear to be trying to play by the "rules of the
    > game", vague as they may be.  On the one hand, they are told to not
    > pollute phase 1 with audit and wait for phase 2, and on the other hand
    > they are being told that phase 2 is nowhere near a certainty.
    
    Yes, that's the case.  There is a significant resistance in the linux
    kernel community to paying for audit.  I don't agree with that, but I
    don't get to change it. The 2-phase plan is my attempt to deal with it, to
    get us half a loaf (access control) with low risk, and play to get the
    other half a loaf (audit) by showing that we can do the right thing
    without causing lots of problems.
    
    To do that, we must keep phase 1 squeeky clean: no unnecessary stuff in it
    at all.  No pre-audit features.  The only way to get fd's into phase 1 is
    to justify it with an access control module that uses the feature.
    
    
    > After all of this, Crispin says that audit can't be included in LSM
    > phase 1 at all and have LSM accepted into the kernel.  Is this still the
    > case?  Will any amount of audit functionality in phase 1 be acceptable?
    
    IMHO, no, audit stuff will not be acceptable in phase 1.  That was the
    feedback we took away from the meeting with Ted Ts'o in Boston in June.
    
    
    > If not, why is there -any- phase 1 audit work being done?
    
    Beats me.  I thought we said plain and clear "no audit in phase 1", and
    SGI came back with an audit patch for phase 1.  There was even a long
    thread with that subject.
    
    
    > Why call for SGI to split the patch into smaller patches and lead them
    > on?
    
    So that we can pick out the pieces that can be justified as access control
    features.
    
    
    > Does anyone know the chances of a phase 2?
    
    That's really hard to know.  It will be much easier to know once we try to
    sell phase 1 to the kernel group.
    
    
    > If it is small, that is, if the kernel developers are giving us 1 window
    > of opportunity and then closing the door, pre-phase 2 work should not be
    > added to phase 1.
    
    By and large, the kernel guys don't even know about this phase 1/2 stuff,
    other than Ted Ts'o.  I don't recomend explaining it to them in the
    context of a complaint about "Crispin is being dictitorial" because it
    will just give them the impression of a bait-&-switch scam.  If someone
    does feel the irrepressable need to get independent confirmation, please
    contat Ted Ts'o privatly, and not via a public post to LKML. One of the
    worst things we can do is present an image of bickering factions to the
    kernel community.
    
    
    > If on the other hand, phase 2 is very probable if phase 1 is accepted,
    > it makes sense to put the fd hooks in now to avoid API disruption.
    
    IMHO, what maximizes the chances for phase 2 (and for phase 1) is for
    phase 1 to be as lean and mean as possible.  That definitely means not
    putting in anything that has no purpose except phase 2 place holders.
    
    
    > Perhaps if we got consensus in this group on phase 1 LSM scope,
    
    Scope == access contorl modules.
    
    
    > and the odds of a phase 2,
    
    Unknowable, other than "lower than the odds for phase 1", and "heavily
    influenced by the reception phase 1 gets."
    
    
    > we could proceed with a clearer view by all as to which patches are true
    > candidates for phase 1.  I see no such consensus at this time, which is
    > why we have this circular discussion.
    
    There appears to be a steady consensus between Immunix, SELinux, and
    Janus, which is fairly natural since we're all doing access control
    modules.
    
    Crispin
    
    --
    Crispin Cowan, Ph.D.
    Chief Scientist, WireX Communications, Inc. http://wirex.com
    Security Hardened Linux Distribution:       http://immunix.org
    Available for purchase: http://wirex.com/Products/Immunix/purchase.html
    
    
    
    
    _______________________________________________
    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 : Wed Jul 25 2001 - 18:20:46 PDT