[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