James Morris wrote:

On Fri, 29 Sep 2006, Paul Moore wrote:

quoted

James Morris wrote:

quoted

Ok, can you please explain it further?

i.e. show me what the policy looks like, exactly what the user is trying 
to achieve, and explain what happens to each packet exactly in terms of 
labeling on the input and output paths.

All right, here is my take on it, perhaps Venkat can chime in too.

Thanks, that cleared up many things, but how does this interact with 
CONNSECMARK?

Please provide some example iptables rules, SELinux policy statements, 
racoon config and netlabel config.  I need to understand exactly what 
happens to each packet in, say, an FTP session and how you envisage the 
configuration.

Hopefully Venkat can talk to the iptables rule, policy statements, and
racoon config.  He has the best understanding of how this works with the
secid patches.  There really is no specific NetLabel config as the
NetLabel config only specifies how to create the explicit packet label
(CIPSO IPv4 option) using the socket's SID.  NetLabel, like SECMARK, is
just a packet labeling mechanism.

I think the key thing to remember is that the only change brought about
by the pseudo-code I posted earlier is that the secmark's MLS label
would be adjusted to match the value of the NetLabel (CIPSO option)
assuming it passes the avc flow_in checks.

Here's a sample scenario for the above (let me know if this is not how 
you expect this to be used):

Say that the SA is labeled "secret" and you have two FTP clients 
connecting to a server via xinetd on this SA.  Each client additionally 
labels their packets via CIPSO as secret:c1 and secret:c2 respectively.  
xinetd launches an FTP server for each at the correct level.

I believe Venkat can address this.

-- 
paul moore
linux security @ hp