Re: Making forward progress

From: jmjonesat_private
Date: Fri Oct 05 2001 - 16:05:38 PDT

  • Next message: Casey Schaufler: "Re: [RFC] 2.4.11-pre4 patch"

    Golly, Seth, you get an A+ on this response, it's chock full of analysis.
    Well done.
    
    On Fri, 5 Oct 2001, Seth Arnold wrote:
    
    > As a response to jmjones's recent question asking what is left, I felt
    > it might be useful to look at Stephen's todo list from a little while
    > back, and see just how much progress has been made since then. :)
    > 
    > On Thu, Aug 02, 2001 at 12:05:02PM -0400, Stephen Smalley wrote:
    > > 1) Move all hook calls after the DAC logic.
    > 
    > Hmm. This appears to have been mostly done, as long as we allow some
    > fudging on the definition of 'DAC'. :)
    
    I think this has been done in every case where it is consistant with the
    original intent.  Since Mr. Smalley positted it, can he "sign off"?
    
    > 
    > > 2) Complete the capability module, as this is
    > > an important selling point for LSM.  This means
    > > moving the capability-specific logic from
    > > access, capget, and capset into the module,
    > > possibly moving the capability bits from
    > > linux_binprm and task_struct (and perhaps
    > > some of the network-related structures) into
    > > the security blobs, and fixing any remaining
    > > kernel references to the capability bits.
    > 
    > Well, our capabilities module still looks an awful lot like the
    > built-in capabilities support already in the kernel -- at least, it
    > doesn't do anything with the security blobs. Whether or not recoding to
    > support using the security blobs is a good idea or not, I just don't
    > know. Stephen, now that you have had a week's experience or so with the
    > second LSM-based release of SELinux, what do you think of the current
    > capabilities module?
    
    Hrm.  I think the capabilities module that LSM currently has does emulate
    the original code fairly exactly.  I think this answers the importance of
    having it.  As far as "more" ... in essence, actual extension of security
    to the kernel... I thought the argument was that specific changes for
    restriction only would be useful, and any changes that
    accidentally/coincedentally supported anything else are okay, but any
    changes for OTHER reasons would be discouraged/rejected.
    
    Security blob support, for a mostly permissive interface, should be
    considered extremely carefully, imho.
    
    > > 3) Continue to define and implement 
    > > additional networking hooks based on our experiences 
    > > with using the current networking hooks for our various modules.
    > 
    > I have no idea about progress on this front -- I don't know much about
    > the Linux networking code. I know I would appreciate it if someone could
    > assure me that the information available in the networking hooks allows
    > for dropping packets, mangling packets?, modifying the security state of
    > processes, based on rules including task information, interface,
    > addresses used, etc...
    
    I agree.  Can the authors/commiters of that functionality write a few
    lines on that topic?
    
    > 
    > > 4) Consider hooks for miscellaneous operations like
    > > nfsservctl, quotactl, bdflush, swapon, swapoff, stime/settimeofday,
    > > syslog, prctl (some of these had hooks defined in the SGI
    > > patch).
    > 
    > Hmm. We've got nfsservctl, quotactl, bdflush, swapon, swapoff, syslog,
    > and prctl covered. There isn't anything for the stime/settimeofday, not
    > that I could quickly see anyway. (There is a capable() hook in
    > do_sys_settimeofday, however...) Are there other miscellaneous
    > operations that still need hooks? :)
    
    Agreed, within the specified "restrictive" sense.
    
    > 
    > > 5) As previously recommended by Chris Wright:
    > > a) Review all current hook calls for placement, error handling,
    > > and parameters.  With respect to parameters, be sure that
    > > we aren't passing user space pointers or at least explicitly
    > > mark such parameters.
    > 
    > Good idea.
    > 
    
    Good idea, but I suspect that, except for the userspace pointer issue,
    this is not "provable" but, rather, demonstrable.  I think we're mostly
    there as far as LSM-local solutions are concerned... if there are any
    others, let's hope the KD's point them out.
    
    > Are there any hooks that people would like to nominate for removal? :)
    
    ?  What is the critera for removal?
    
    
    > 
    > > d) See if we can make the file system hooks consistent in their
    > > usage of struct vfsmount vs. struct super_block.
    > 
    > Hmmm. There appear to be five uses of struct super_block and five uses
    > of struct vfsmount. I don't know enough about the individual hooks to
    > tell if this is fine, or indicitive of trouble.
    
    Who knows?  Anybody?
    
    > 
    > Not on this list, but also important -- higher level documentation. The
    > SELinux team put together some decent enough high level docs; perhaps
    > they should be reviewed again with the light of trying to provide more
    > background/history/context for the project? (It might be the docs are
    > fine enough as they are. :)
    
    The comments added to security.h seem to be consistant with the
    documentation needs of a presentation, imho.  More documentation is both
    necessary and desirable, imho, from comments to a "HowTo" to a "Dummies
    Guide" (no violation of any copyright/trademark inteneded), but I don't
    necessarily think them advisable or necessary *NOW*.  After all, whatever
    is bundled in a dummies guide will get the scrutiny of Linus and the KD's,
    as well as LSM, before acceptance.  "Spin" may matter in the sale.  I
    expect to present after-acceptance documentation, but not until the
    "politics/spin" is determined.
    
    AFTER the sale, spin is important, too, but it can be "fixed" by LSM.
    
    As a testimonial, the current documentation is more than adequate for me
    to evaluate and decide if the current hooks are desirable/useful for my 
    application.  If any further clarification for anybody on this list is
    necessary, speak now, please. :)
    
    >
    Comments? 
    > 
    
    See Above,
    J. Melvin Jones
    
    
    Proposed: LSM is ready to start the "sale".  Are there any voices against
    that position, and WHY?
    
    |>------------------------------------------------------
    ||  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 : Fri Oct 05 2001 - 16:06:51 PDT