Re: Port of secure fd handling to LSM

From: Greg KH (gregat_private)
Date: Tue Aug 07 2001 - 18:32:39 PDT

  • Next message: Crispin Cowan: "Re: Port of secure fd handling to LSM"

    On Tue, Aug 07, 2001 at 11:48:34AM -0700, Casey Schaufler wrote:
    > David Wagner wrote:
    > > 
    > > richard offer  wrote:
    > > >But the argument was that fds are not useful for any policy.
    > > 
    > > No, I think you're mis-stating the argument.
    > Richard has addressed the arguement which was presented.
    The argument was:
    	Only audit needed the fd passed to all of those different hooks.
    	For all other security projects, the struct file was more than
    Someone brought up the point that possibly the OpenWall like protection
    of the low fd numbers might need the fd passed in the hook, and Richard
    has proven that no, it is not needed.  Thanks Richard!  Give that man a
    > 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. 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".
    > Golly Hoppers! What more to do?
    Prove that some _real_ project besides audit needs to know the fd.  Not
    a "made up" one.  But something that exists today, that does not entail
    > How about a policy which requires all STDIN be logged? Or
    > is that too much like audit? How about a policy which requires
    > STDIN to be the physical console device for processes with
    > uid=0? That's actually very reasonable in a server
    > environment, and you need both the inode (to get the device number)
    > and the fd (to check for stdin) to enforce that.
    Hm, I remember such a looney project existing for Linux in the past.
    Does anyone remember the name of it?
    Remember, you can determine from the struct file if the file being
    accessed is stdin :)
    In fact, I still think you can get anything you want from the struct
    file (dup(2) isn't a good argument, simply scan the file pointers for
    _all_ matching instances, not just the first one, if you want to do such
    a check.)
    > 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, 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.
    Ah, no one is denying that audit needs this.  Just that we aren't doing
    audit right now.  Your persistence is inspiring :)
    greg k-h
    linux-security-module mailing list

    This archive was generated by hypermail 2b30 : Tue Aug 07 2001 - 18:35:39 PDT