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.
--
redhat-lspp mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/redhat-lspp
