Re: Assurance, permissiveness, and restriction

From: Titus D. Winters (titusat_private)
Date: Mon Jun 04 2001 - 13:37:14 PDT

  • Next message: jmjonesat_private: "Re: Assurance, permissiveness, and restriction"

    > > 1. Political difficulties should not be considered in the design of
    > > software.  Anyone that says otherwise is trying to avoid a flamewar.
    > > Personally, I'd rather fight the flamewar battle personally and let
    > > someone else do the development if that's what it takes to get it done
    > > right the first time.
    >
    > I don't understand this argument.  I don't mind flamewars, but LSM
    > is worthless to us if it is not accepted into the Linux kernel.  So
    > we have to consider how acceptable our solution will be to the Linux
    > kernel developers.
    
    But if something substandard that is going to have to be extended again is
    accepted into the kernel we haven't helped that much either.  This is open
    source we are talking about, not pushing something insane past managment.
    If we can demonstrate that there is a need for this (and anyone that
    _can't_ demonstrate a need for security needs to watch the news from time
    to time), and show that it isn't harmful, it should not be impossible to
    accomplish.  If it just takes a knockdown drag out flamewar on the main
    kernel dev list, then that's what it takes, but we need to put out the
    best version of this that we can.  Planning on making n versions of
    this so that we can get it through is just a waste of time, both ours and
    the main developers.  Lets push to get done what we know now needs to be
    done, and then we can _be_ done.
    
    > Where's the real argument for moving all of the base logic out of
    > the kernel?  Identify exactly what project needs it, and why it
    > can't be supported adequately through separate hooks (including
    > the capable hook for permissive behavior).
    
    Robustness - anything you can code can be implemented as a security
    mechanism, even parity of your system clock if that's what you want.
    
    Cleanliness - all the security logic is in one place, easy to find, easy
    to work with.  Furthermore, we aren't adding in the intuitional complexity
    of storing what the kernel thinks should be done passing it in to the
    module, and then reacting to that.
    
    Simplicity - This way we don't need to double up hooks (hook_permissive,
    hook_restrictive, etc).
    
    I don't think we need to be thinking about the modules that are
    specifically being developed now, we were chartered to develop a framework
    that could be worked with that didn't enforce any policy.  This is the
    most applicable approach to that to date.
    
    > I can't see us devoting resources to such a significant effort when
    > it doesn't provide any benefits for our security modules and it
    > doesn't help our case to the Linux kernel developers.
    
    It is no more significant than anything else we are doing, the way I see
    it.  If it's the amount of coding effort that's the worry, I'll take care
    of it myself.
    
    The bulk of the complaints that we've been getting are political in the
    worry that the kernel developers might not like it that we are messing
    with stuff so deep.  I think we need to worry about the technical
    obstacles (developing the durned thing) more than let our theoretical
    concerns about political issues govern our contribution.
    
    -Titus
    
    
    
    _______________________________________________
    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 - 13:38:55 PDT