Re: intercepting system calls

chrisat_private

* David Wagner (dawat_private) wrote:
> 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.
> 

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.

> 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().

don't forget fork() ;-)

-chris

_______________________________________________
linux-security-module mailing list
linux-security-moduleat_private
http://mail.wirex.com/mailman/listinfo/linux-security-module