Re: Port of secure fd handling to LSM

From: Casey Schaufler (caseyat_private)
Date: Tue Aug 07 2001 - 11:48:34 PDT

  • Next message: Greg KH: "Re: Port of secure fd handling to LSM"

    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.
    >  (At least, that wasn't
    > *my* argument.)  The argument was that there seems to be little reason
    > to pass the fd into, for example, the read() hook.  I can't think of a
    > plausible access control policy that this is necessary for.
    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?
    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.
    Now, do we need a sample implementaion of this,
    would that be pointless, or unnecessary? 
    > I hope I don't have to say that the LSM list is not about whose ideas win
    > -- it is about a joint endeavour to learn how best to support access control
    > policies in Linux.  The more we learn about this, the more we all win.
    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.
    Casey Schaufler				Manager, Trust Technology, SGI
    caseyat_private				voice: 650.933.1634
    casey_pat_private			Pager: 888.220.0607
    linux-security-module mailing list

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