Re: Port of secure fd handling to LSM

From: Crispin Cowan (crispinat_private)
Date: Tue Aug 07 2001 - 19:15:40 PDT

  • Next message: Greg KH: "Re: Problems with some of the current hooks"

    Casey Schaufler wrote:
    > Richard has addressed the arguement which was presented.
    If that's what you actually believe, apparently not clearly enough.  Most readers
    appear to believe that Richard's module proves the counter-point: that fd's are
    not required for an access control policy.
    > We have one, and I realize that it's taboo to reintroduce audit (audit bad,
    > smell funny) but it's a very real policy component. I'm sorry that y'all have
    > decided that by itself it's not enough of an arguement.
    Audit:  stage 2.
    I'd say "'nuff said", but apparently not.  Let me make it VERY clear:  I LIKE
    audit.  *I* believe that it is a necessary part of a strong security system.
    However, I also believe that there is a strong prejudice in the Linux kernel
    community against audit.  They believe that audit is very expensive and don't
    want to support it.
    This stage 1/2 business is a sneaky plan to break down that prejudice.  Stage 1
    demonstrates to the kernel community that LSM can operate in the kernel without
    unduly damaging performance.  This builds our credibility.  Then in stage 2 we
    propose to add audit, using all the usual arguments for the importance of audit
    to security, and bargaining from a position of credibility and strength, having
    shown that LSM works.
    > We're trying to demonstrate that audit is not the only scheme which might use
    > fds, and having done so we now get "oh, that's not what I meant".
    Unfortunately, what you appear to have demonstrated is that audit is in fact the
    only policy that requires fd's.
    > Golly Hoppers! What more to do?
    Wait for stage 2 :-)
    > How about a policy which requires all STDIN be logged? Or is that too much like
    > audit? How about a policy which requires
    > ...Now, do we need a sample implementaion of this, would that be pointless, or
    > unnecessary?
    See the above plan that talks about "credibility"?  Critical to that is that the
    stage 1 LSM patch is lean & mean.  It should contain nothing that is not
    absolutely required to support access control policies.  To that end, any feature
    included in LSM 1 should be justified with some actual access control module that
    someone might actually want.
    My request to Richard to build the Solar Designer stdin/out/error module for LSM
    was an earnest attempt to help SGI provide a legitimate access control
    justification for this important feature, that you "just happen" (nudge nudge
    wink wink) to need for audit.  This effort has apparently failed, as not even
    Solar Designer's hack actually requires the fd's to be passed as you want.
    > And if we can't do what we need to do, we don't win, we lose.
    > I understand that you don't win if fds get passed,
    Not at ALL!  "We" (LSM - SGI) don't "win" if fd's aren't in LSM 1.  As you wisely
    said earlier, if LSM is not accepted into Linux, we ALL lose.
    > but I don't understand how it is you lose if they do. This has been our concern
    > (gripe, if you will) all along, that there is no substantive reason to deny our
    > needs, only a claim that we don't need them.
    The basis is the stage 1/2 plan, which is designed to simultaneously maximize the
    chances of LSM being accepted at all, and of audit being accepted eventually.
    Access control now, audit later.  It really isn't that complicated.
    Crispin Cowan, Ph.D.
    Chief Scientist, WireX Communications, Inc.
    Security Hardened Linux Distribution:
    Available for purchase:
    linux-security-module mailing list

    This archive was generated by hypermail 2b30 : Tue Aug 07 2001 - 19:20:02 PDT