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?
>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.
_______________________________________________
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 - 16:36:42 PDT