On Wednesday, March 28 2007 3:42:57 pm Joy Latten wrote:
> On Wed, 2007-03-28 at 10:48 -0400, Paul Moore wrote:
> > On Tuesday, March 27 2007 10:37:44 pm Paul Moore wrote:
> > > On Tuesday 27 March 2007 9:02:38 pm Joy Latten wrote:
> > > > I think I know why this is happening. In your example, the policy has
> > > > a context of "system_u:object_r:ipsec_spd_t:s0", thus it will only
> > > > work at s0. Everything else will not match the policy and thus go out
> > > > as unlabeled because by default we allow unlabeled packets. (That is,
> > > > the boolean allow_unlabeled_packets is on by default. You must turn
> > > > it off if you don't want any unlabeled packets going out.) It should
> > > > do this for tcp and udp.
> > >
> > > That sounds reasonable, but I think it's rather misleading because TCP
> > > connections automatically generate a new SA with the correct context,
> > > at least doing the same thing as outlined in my original mail works
> > > with TCP.
> > >
> > > > In my policy, I have a context of
> > > > "system_u:object_r:ipsec_spd_t:s0-s15:c0.c1023" to catch everything.
> > > >
> > > > I tried it with my policy and sent udp packets and it worked ok.
> > > > Please try this and let me know if it does or doesn't work for you.
> > >
> > > I will try this out when I get in to work tomorrow.
> >
> > I tried this (making the MLS range from SystemLow to SystemHigh) and it
> > did work as you described. However, I'm still concerned that labeled
> > IPsec treats TCP and UDP differently ... I don't want to be the one who
> > has to explain this to users over and over again.
> >
> > Now I'm off to try the latest 2.6.20.x kernel.
>
> Hmmmm... I am on lspp 70 kernel and policy version 38.
I'm using lspp.70 for the kernel and policy 2.4.6-45.el5 ... not sure if the
policy rev makes a difference or not.
> I entered policy with following context,
> system_u:object_r:ipsec_spd_t:s0
>
> I used nc to test both udp and tcp connections.
> My id on both machines is:
> uid=502(testuser) gid=502(testuser) groups=502(testuser)
> context=testuser_u:user_r:user_t:s15:c0.c239
>
> tcp and udp are acting the same for me. Neither attempt
> resulted in an SA. I got avc denied msgs for "polmatch" permissions
> on the policy, thus leading to no policy being found and packets going
> out as unlabeled.
Okay, I apologize ... I've been trying to recreate this for about an hour now
and for the life of me I can't seem to recreate the behavior I was
describing. It looks fine now. I have no clue ... /me scratches head
> How are you testing as far as user, commands, etc...?
> Perhaps I can try to duplicate your scenario.
Well, I still did find one thing that was a bit odd, perhaps you can help
explain it to me. When I use the following SPD (where A and B are IPv4
addresses, with the other end having the same policy but a shift in
direction):
spdadd A B[5300] tcp
-ctx 1 1 "system_u:object_r:ipsec_spd_t:s0"
-P out ipsec ah/transport//require;
spdadd A[5300] B tcp
-ctx 1 1 "system_u:object_r:ipsec_spd_t:s0"
-P out ipsec ah/transport//require;
spdadd B[5300] A tcp
-ctx 1 1 "system_u:object_r:ipsec_spd_t:s0"
-P in ipsec ah/transport//require;
spdadd B A[5300] tcp
-ctx 1 1 "system_u:object_r:ipsec_spd_t:s0"
-P in ipsec ah/transport//require;
spdadd A B[5300] udp
-ctx 1 1 "system_u:object_r:ipsec_spd_t:s0"
-P out ipsec ah/transport//require;
spdadd A[5300] B udp
-ctx 1 1 "system_u:object_r:ipsec_spd_t:s0"
-P out ipsec ah/transport//require;
spdadd B[5300] A udp
-ctx 1 1 "system_u:object_r:ipsec_spd_t:s0"
-P in ipsec ah/transport//require;
spdadd B A[5300] udp
-ctx 1 1 "system_u:object_r:ipsec_spd_t:s0"
-P in ipsec ah/transport//require;
... and connect from B to A running netcat using both TCP and UDP I find that
both the UDP and TCP connections use the same SA on the host generating the
traffic. Based on the SPD above I wouldn't think that to be the case ...
--
paul moore
linux security @ hp
--
redhat-lspp mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/redhat-lspp
