[redhat-lspp] Re: RHEL5 Kernel with labeled networking

[Venkat Yekkirala]

> > Using these kernels I'm getting some interesting denials. I labeled 
> > the spd's with system_u:object_r:ipsec_spd_t:s0 so that it would be 
> > discernible from any socket contexts that may appear.
> >
> > First I had to add a polmatch rule for unconfined_t to 
> ipsec_spd_t, so 
> > far it makes sense.

Yes.

> >
> > Next I need polmatch on unconfined_t to unconfined_t, I 
> assume this is 
> > because the SA is going to be labeled unconfined_t, seems 
> reasonable.

If you have the contraints from the policy patch I posted last night
applied to your policy, you won't need the above allow rule.

> > Racoon also needed setcontext for unconfined_t unconfined_t 
> (not sure 
> > what the source and target mean here)

The source should be racoon (running in unconfined_t?) and the
target is the new SA context (unconfined_t I suppose).

> >
> > the denial I totally don't understand is:
> > audit(1159877238.937:35): avc:  denied  { polmatch } for  
> > scontext=system_u:object_r:unlabeled_t:s0 
> > tcontext=root:system_r:unconfined_t:s0-s0:c0.c255 tclass=association

This can happen if, for example, iptables rejects an "unlabeled"
packet with a TCP Reset. The reply packet flow will derive its
label from the original packet (unlabeled in this case).

Other examples are where an outgoing packet would derive its label
from an incoming packet are:

- icmp messages
- tcp resets generated by tcp.
- tcp aknowledgements when the socket is in time_wait and SYN_RCVD states.

One thing to keep in mind is that secid reconciliation occurs AFTER all
the IPSec xfrm(s) are applied (decrypted, decompressed, etc). So the
label a packet has at the point a response is generated (expect the last
2 tcp in the above) might not have been reconciled, and thus could be
carrying whatever label has been defined via secmark.

> >
> > there is no unlabeled anything, except for a non-ipsec connection 
> > which isn't being used, I don't understand how this would 
> happen at all.
> >
> > After all that it isn't working as expected. the SA's get set up 
> > correctly based on the initiators socket (I'm using 
> semanage_t in this 
> > case) but the reciever SA's aren't set up with the 
> receiving process 
> > socket context so I get:
> >
> > Received: Hello, root:system_r:semanage_t:s0-s0:c0.c255 from 
> > root:system_r:semanage_t:s0-s0:c0.c255

Is the context after Hello, the context returned by getpeercon?

Also, where are you getting the "from" context from?

> >
> > no matter what context the server is running in.

Likely because you are running in permissive mode. ANY process can now
"sendto" the same SA.

> >
> > Further, once that SA is created all domains can use it and 
> it retains 
> > the same context, if I rerun the client in unconfined_t I still get:
> >
> > Received: Hello, root:system_r:semanage_t:s0-s0:c0.c255 from 
> > root:system_r:semanage_t:s0-s0:c0.c255
> >
> > I am running in permissive (I'd hope that wouldn't affect 
> this but I 
> > can see how it could)

In fact it does.

> because my policy doesn't yet have 
> flow_in and 
> > flow_out permissions (any chance to get a policy patch? :) )
> >
> > Am I off base here, is this the expected results? 
> On the bright side localhost connections seem to work well:
> # ./client 127.0.0.1
> Received: Hello, root:system_r:unconfined_t:s0-s0:c0.c255 from 
> root:system_r:semanage_t:s0-s0:c0.c255
> 
> so getpeercon got the right answer on both sides.

Are you able to rerun the tests AFTER applying the
constrains from last night's policy patch and while
in enforcing?