Re: SELinux security and passed file descriptors

[James Antill <jantill@redhat.com>]

[-- Attachment #1: Type: text/plain, Size: 2095 bytes --]

On Fri, 2007-08-31 at 15:32 +0100, David Howells wrote:
> Stephen Smalley <sds@tycho.nsa.gov> 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 <jantill@redhat.com>

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]