James Morris wrote:

On Fri, 29 Sep 2006, Paul Moore wrote:

quoted

quoted

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.

Ok, I'd still really like to see a worked example of just Netlabel + 
secmark/connseckmark, to see what happens to the connection marks.

Fair enough.

It 
seems that the connection mark should always be correct, and restored to 
the packet.  In which case, what happens when a CIPSO label on an 
established {connection} ...

The following would happen, in order, in selinux_skb_flow_in() (I'm
ommitting the IPsec relevant portions of this function for clarity):

1. A NetLabel SID would be generated using the secmark as the
"base_sid"; this means that the NetLabel would be the concatenation of
the secmark's TE context and the NetLabel's MLS label.  The secmark is
not yet modified.

2. The NetLabel SID would be avc checked against the secmark:
    avc_has_perm(nlbl_sid,
                 skb->secmark,
                 SECCLASS_PACKET,
		 PACKET__FLOW_IN,
                 NULL)
   Note that in practice this is basically just a MLS label check.

3. If the NetLabel SID != 0 the secmark would be replaced with the
NetLabel SID.

I am trying to make NetLabel behave in a similar fashion as to how
labeled IPsec works in the secid patches; I believe the above steps
acomplish this.  If not please let me know and I'll make the necessary
changes.

... or related packet doesn't match ...

Not sure what you mean by "related packet", but if the check in step #2
fails then the packet would be dropped.  The only case where I can see
this happening is that if the MLS/MCS constraints did not allow the
flow_in permission.  This allows administrators to set specific MLS
labels for any iptables "object".

... or you get no CIPSO label (e.g. ICMP from intermediate router) ...

If there is no packet label that NetLabel recognizes and NetLabel is
configured to allow unlabeled traffic then the NetLabel SID generated in
step #1 above would be 0.

Or, is would you be always 
overwriting secmark/connsecmark labeling, and if so, how/why are you using 
them?

I think I addressed that above.

FYI: in between emails I'm working on a patch against Venkat's secid
patches which implements this, hopefully Venkat can roll this patch into
his secid patchset so this is all committed/rejected at once.

-- 
paul moore
linux security @ hp