Re: intercepting system calls

chrisat_private

* 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