Scott Leerssen wrote: >I disagree with this scenario. In trusted programming, there are often >times when you want to gain access to a file/socket via a privileged >process and then pass along the descriptor to an less privileged >process. Yes. But even here, monitoring read()/write() is unnecessary for most practical purposes. Suppose you're worried about program A passing a fd to program B. There are two cases: - Program A is untrusted. Then you should just apply your security policy to program A, so that A can't open() the fd in the first place unless it meets your policy. Then there is no need to check for read()/write() by either A or B. Note that if A and B are colluding and if A can open file F, it doesn't matter whether you allow passing fd's or not. Program B can just ask A to do the file operations on F on its behalf, and there's nothing you can do to stop this. There's no point trying to prevent A from passing on its privileges to its cohorts. - Program B is trusted. Then one possibility is to allow B to enforce your policy itself, and make sure that B won't return a fd to A unless that should be allowed by your policy. Alternatively, you can stick a firewall proxy between A and B to mediate all requests from A to B. Observe also that the only way to pass fd's to another process is via sendmsg() and recvmsg(), so if you want to prevent fd-passing you can do so by mediating just these calls. This alternative approach eliminates the need to mediate read()/write(). _______________________________________________ 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:10:49 PDT