From: chanson@TrustedCS.com (chanson at TrustedCS.com)
Date: Mon, 16 Feb 2009 10:18:34 -0500
Subject: [refpolicy] [PATCH] refpolicy: Add missing network related
	MLSconstraints
References: <20090212211531.619341973@hp.com>
	<170D6ABBBA770349AA49582A86FCED15BA0199@HAVOC.tcs-sec.com>
	<49962F60.3090206@schaufler-ca.com>
Message-ID: <170D6ABBBA770349AA49582A86FCED15BA02BB@HAVOC.tcs-sec.com>
To: refpolicy@oss.tresys.com
List-Id: refpolicy.oss.tresys.com

 
I realized I was imprecise in my description of "network object" when
writing this. I was more specifically referring to enforcement of
"Network / Host Level Access Decisions" of packets entering/exiting the
system. I concur that Trusted OSes have allowed trusted processes to
change socket attributes, such as labels, or read higher level data as
Glenn and you have mentioned. This coincides with the existing MLS
networking overrides in the MLS constraints today.

-Chad

> -----Original Message-----
> From: Casey Schaufler [mailto:casey at schaufler-ca.com] 
> 
> chanson at TrustedCS.com wrote:
> > Traditionally network objects in a MLS system are not 
> usually subject 
> > to the usual privilege overrides.
> Hum. That wasn't true of Trusted Irix where sockets were the 
> network objects.
> Of course, you can only apply privilege on the sending end 
> because the privilege state isn't transmitted.
> 
> On Smack the network object is the process, and privilege is 
> required to muck with the attributes of your own sockets, but 
> otherwise it's the same, again the privilege isn't getting 
> transmitted, so you can't determine if it's there on the other end.
> 
> If you want to transmit the privilege state, and SELinux 
> (appears to) allow that, you really ought to allow for that 
> on the other end.