Re: intercepting system calls

From: Chris Wright (chrisat_private)
Date: Fri Apr 13 2001 - 17:32:50 PDT

  • Next message: Chris Wright: "ideas on interface (was Be careful please)"

    * David Wagner (dawat_private) wrote:
    > Chris Wright  wrote:
    > >It is possible to imagine a scenario where passing file descriptors is
    > >ok for some files and not others.  Program A can open more files than
    > >program B, and can pass some open files.  We want to prevent it from
    > >being tricked in to passing B a file that B can't open, A can open, and
    > >B should never be reading.  i.e. it's ok to pass a socket fd or a fd to
    > >/tmp/whatever, but not one to /etc/shadow.
    > 
    > This seems likely to be not too common -- I can't think of any
    > programs off-hand that will open a file for you on request and
    > pass you back a fd, although I'm sure there must be one or two.
    > Given this, I'll note that there are two potential alternatives
    > to mediating read()/write():
    >   - Mediate recvmsg(), to ensure that B can't recieve any fds.
    >   - Mediate connect()/etc. to ensure that B can't get a connection
    >     to any such program A that will return a fd.
    > 
    > Note that I don't have any objection to providing support for
    > modules that want to mediate read()/write() for whatever reason.
    > Even if it's not my favorite policy, the whole point of this
    > project (if I understand correctly) is to build a mechanism
    > that is as policy-independent as possible.
    > 
    > However, my main concern is to make sure that modules that don't
    > want to mediate read()/write() won't have to pay the cost for
    > those who do.  In other words, if your module doesn't care about
    > read()/write(), then I'd like it to be the case that reads and
    > writes execute at full speed, with no noticeable performance impact.
    > Would this do the trick?
    
    yes, we need the hooks, it is up to the module to implement them.  i'm
    afraid it won't be zero overhead...but whatever it takes to follow
    function pointer and immediately return success ;-)
    
    > 
    > >don't forget fork() ;-)
    > 
    > Yes, you're right.  If you want to enforce different rules for
    > children than for the parent, you have to do a number of things
    > to "clean up" the state of the child...  Thanks.
    
    we support different rules for child than parent, and thus need this as
    well.
    
    -chris
    
    _______________________________________________
    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 Apr 13 2001 - 17:37:49 PDT