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

[Joy Latten]

On Wed, 2006-10-04 at 14:41 -0400, Venkat Yekkirala wrote:
> > > 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).
> 
I was playing around and noticed the same behaviour. I did a ping, which
resulted in kernel sending acquire to racoon. 
I needed "allow sysadm_t ping_t association:setcontext". I had newroled
to sysadm_r when I did the ping and my SA's context was ping_t.
I am guessing in above case, context that started program was
unconfined_t (I think method said he did runcon.) and program which
caused acquire was unconfined_t too.

I have not yet applied the new policy patch, but does it take care of
this?
 
> > >
> > > 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
> 

I saw this too with my ping example, except mine needed
"allow unlabeled_t sysadm_t association:polmatch". I noticed
this occured as the last deny on initiator and first one on receiver,
not that it means anything. Again, I will apply new set of policy
patches and see what happens. 

> 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.
> 

I noticed something else, and this is perhaps my not understanding
something. In my spd on both sides, the security context was
"system_u:object_r:passwd_t:s2", my SAs, on both sides were created with
"root:sysadm_r:ping_t:s0-s15:c0.c1023". Shouldn't the mls label in my
spd be honored in SA? Should SA be allowed an mls label of s0 or S1, in
this case? Or is it just as long as the "polmatch" succeeds?

In the code security_xfrm_state_alloc_acquire() we pass the fl->secid,
which will be used to acquire the mls label for the SA. I am not sure I 
understand this? Also, when does fl->secid get set on output or do we
care? The only place I see it get set is in
security_xfrm_decode_session(), which eventually gets called via
xfrm_policy_check()/xfrm4_policy_check (which I think gets called on
input) or xfrm_route_forward(). So, for example, my ping created a
packet on output, and I think security_xfrm_decode_session() hasn't been
called. I am not sure what fl->secid will be if not 0... So,
"s0-s15:c0.c1023" was passed in the acquire for the SA. Is this ok or
right?

I need to test labeled ipsec in mls for lspp and need to understand. 

Joy