On Fri, 2007-08-31 at 15:32 +0100, David Howells wrote: > Stephen Smalley <[EMAIL PROTECTED]> wrote: > > > That's how mandatory access control is supposed to work; otherwise, a > > flaw in A can leak the descriptor to B at will in violation of security > > policy. > > Yeah, but by making it impossible to have the flaw, you've also made it > impossible for A to validly pass to B a file descriptor B wouldn't otherwise > be able to access directly, but should be able to access on behalf of A. > > To put it another way, how does A now legitimately pass on to B the grant of > rights A had on that specific file descriptor?
It doesn't, that's what the _Mandatory_ part of Mandatory Access Control is all about. See the third paragraph from wikipedia, on MAC: """MAC's most important feature involves denying users full control over the access to resources that they create. [...] """ http://en.wikipedia.org/wiki/Mandatory_access_control > I don't think you can practically change the security attached to the file > struct, > > With respect to execve(), imagine that program A (a shell, say) opens a file > to use as a stdout for program B, which it then proceeds to exec. Imagine, > however, the process's security label is changed during the exec of B and this > disallows B from writing to its stdout. Is this correct behaviour since it is > differs depending on whether SELinux is in enforcing mode or not? Or is there > some way around this in SELinux? (I presume this is what > flush_unauthorized_files() does). This is correct, and often happens with respect to stdout (see allow_daemons_use_tty etc.). You might also be asking how you can run B in the same security context as A, and you can do that by calling setexeccon() with the result from getcon(). But that is very likely to affect more than just writing to stdout. Or you could call fsetfilecon() on stdout from A, so that it would be in a context that B could use, but that might not be allowed (or just be a bad idea). -- James Antill <[EMAIL PROTECTED]>
signature.asc
Description: This is a digitally signed message part
