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

Joshua Brindle jbrindle at tresys.com
Tue Oct 3 19:29:00 UTC 2006


Joshua Brindle wrote:
> James Morris wrote:
>> On Tue, 3 Oct 2006, Eric Paris wrote:
>>
>>  
>>> I think there is going to need to be a policy change that I'm actually
>>> talking with Dan about as I type this e-mail.  I think we  need
>>>
>>> allow $1 unlabeled_t:packet { flow_in flow_out };
>>>
>>> to be added to policy to allow things to work as they did.  I'll post
>>> again as soon as we have a policy that appears to let normal networking
>>> work in enforcing.
>>>     
>>
>> We need this policy in rawhide before the kernel patches are merged 
>> upstream, so we can note the required policy version associated with 
>> the patches.  We've do not want to kill Andrew Morton's box again 
>> with this kind of thing.
>>
>>   
>
> 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.
>
> 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. 
> Racoon also needed setcontext for unconfined_t unconfined_t (not sure 
> what the source and target mean here)
>
> 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
>
> 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
>
> no matter what context the server is running in.
>
> 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) 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.




More information about the redhat-lspp mailing list