[redhat-lspp] Labeled IPsec localhost problems

Thu Feb 1 01:33:22 UTC 2007

On Wed, 2007-01-31 at 17:32 -0500, Paul Moore wrote:
> On Wednesday, January 31 2007 4:33 pm, Joy Latten wrote:
> > On Tue, 2007-01-30 at 23:14 -0500, Paul Moore wrote:
> > > > By the way, I ran one last night with labeled ipsec over ipv6 with
> > > > your patch and happy to report the stress test completed a 15 hour
> > > > run successfully. So at least no regression on that front.
> > >
> > > Great, thank you for testing this.  Out of curiosity, how many times
> > > during the test did the phase-2 SAs get re-keyed, i.e. what was the SA
> > > lifetime?
> >
> > ISAKMP SA lifetime is 30 minutes and IPSEC SA is 15 minutes. And test
> > ran for 15 hours sending streams of udp and tcp packets. I also had
> > both esp and ah configured to be used.
> 
> Good to know thanks.  I wanted to make sure we were hitting the IKE 
> negotiation code and it looks like we hit it quite a few times.
> 
> > > That is exactly the problem I am concerned about too ... using the
> > > standard IPsec selectors of src,dst,proto,port I'm not sure there is a
> > > way to differentiate connections between two localhost addresses in all
> > > cases; for example, what happens if you want to label ICMP traffic across
> > > localhost?
> >
> > Ok, I am going to talk myself through this, I apologize ahead of time
> > if it is too much info and I will skip over stuff since xfrm process is
> > kind of a lot to me. :-)
> 
> It's a lot for anybody to wrap their head around :)
> 
> > This is not exclusive to loopback. What if I have a traffic stream
> > 10.1.1.1->10.1.2.3 and I have specified a separate ipsec policy for each
> > upper layer protocol, udp, tcp, and icmp. This gives me 3 pairs of
> > policy entries (6 entries altogether) with exact same info except for
> > the upper-layer protocol. Well, in regular ipsec, this will result in a
> > single pair of SAs, that will be used for icmp, udp, and tcp traffic.
> > This single pair of SAs will be associated with all 3 pairs of policy.
> 
> Actually, if you configure the SPD such that you have a separate policy for 
> UDP, TCP, and ICMP between two hosts then you will get three SA pairs, one 
> pair for each protocol.  The protocol type is part of the IPsec selector (see 
> RFC 2401).
> 
Yes, that is correct, IF there is a protocol type specified. 

rfc2367 states that if the ports are non-zero, then the
sadb_address_proto, normally zero, MUST be filled in with transport
protocol's number. So, unless you have specified ports, this field will
be zero. 

I did try this earlier and got the results I told you about earlier.
Try the following policy for an example. 

spdadd 10.1.1.1 10.1.2.3 tcp
-P in ipsec
esp/transport//require; #ah/transport//require;

spdadd 10.1.2.3 10.1.1.1 tcp
-P out ipsec
esp/transport//require; #ah/transport//require;

(create 2 more pairs and use "icmp" and "udp" instead of "tcp") 

> > Now with labeled ipsec, the only difference is the security context.
> > The security context is the "selector" that differentiates xfrms.
> > So, instead of a single pair of xfrms, we could possibly have many.
> > And the code takes care of this. To find correct xfrm, we do a
> > xfrm_selector_match() and if successful, then do a
> > security_xfrm_state_pol_flow_match(), which checks to see if (flow->sid
> > == xfrm->id) then avc_has_perm(check for association:sendto) permission.
> > This ensures we get correct xfrm for the flow. Otherwise return error
> > and continue to step thru xfrm list until you find another one whose
> > selector matches and try again. If there is none and we have a policy,
> > then call racoon.
> 
> This gets to my original question about if the SELinux context was fully 
> integrated into the IPsec selectors, it looks like it has - that is good.  
> Have you verified this behavior over loopback?  One of us should ...
> 

I have to a small degree. I run all the stress tests in enforcing mode.
I did a ping and ssh before starting tests, so there were about 6 other
SAs in database before starting stress tests which creates I think 2 or
4 more. Of course a more populated database, would provide a better
test... Also, I think tests would not start if correct SA was never
found...

> > Now with loopback the concern is we will have two exact SAs per
> > security context. I am thinking that if they are exact, what does
> > it matter which one gets used. We just want to make sure we use SA
> > that has the correct security context and this will get done
> > via security_xfrm_state_pol_flow_match() per what I said in above
> > paragraph.
> 
> If two SAs have the exact same selectors, including SELinux context, then it 
> probably shouldn't matter which one gets used.  I'm still slightly concerned 
> about the AH/ESP sequence number but it's been so long since I have played 
> with IPsec issues like this that I only have vague reasons why this would be 
> a concern.
> 
> > Venkat or anyone, please correct me if I am off on this 
> > or missing something. Regardless of which SA of the pair
> > gets used, the SPI will ensure we pull up corresponding SA for inbound.
> 
> I believe you are correct, the SPI should solve the bulk of the problems for 
> the inbound case.  However, like I said earlier, it's the outbound case that 
> I am more concerned with as it is relies more heavily on the IPsec selectors 
> to ensure the correct SA is used.
> 
> That said, it would be nice if Venkat could weigh in on this issue.
> 
> > Now because of the policy->bundle feature, I think one of the SAs
> > of the pair will always end up being used for outbound and the other
> > for inbound processing. Again, unless I am missing something, I
> > think it won't matter which of the 2 gets associated with inbound or
> > outbound policy->bundle since they are exact.
> 
> Well, I think the typical case is for each SA in a bundle would have a 
> different context.  Using the client->server model I would expect one SA to 
> have a "client_t" context while the other would have a "server_t" context.
> 
> > Switching back to regular labeled ipsec, I have noticed in a
> > client->server model, "ssh" for example, 4 pairs of
> > SAs get created per security context. A pair for server and a pair for
> > client. I have noticed, when sending, the client security context is
> > used. Upon receiving, the server needs to have recvfrom permission to
> > use client SA. Correct SA will always get pulled up because of spi.
> >
> > Switching to loopback, this should work ok too. (i tried it and it did)
> 
> Okay, good.  Sorry to belabor the point, but did you verify the SPI from 
> packets sent by the server?  For example, were the server's ACKs using a 
> different SPI than the client's packet?

No problem, I too share your concern that we catch any holes.
Ok, I tried it again to answer your question. Unfortunately, using
tcpdump I could not readily distinguish the server's packet from the
client's, however, during the whole session I saw only two SPIs. I
mapped one spi to the client/sysadm_ssh_t's SA and the other to the
server/sshd_t SA. This appeared correct to me. I am thinking that this
set will always get used, and because loopback is not really
bidirectional, the other set may never get used. (4 SAs get created per
previously stated observations.)

In case anyone wants to try, I use following ipsec policy and with
latest selinux policy from Dan Walsh. You must also patch racoon with
Paul's patch.

spdadd 127.0.0.1 127.0.0.1 any
-ctx 1 1 "system_u:object_r:ipsec_spd_t:s0-s15:c0.c1023"
-P out ipsec ah/transport//require;

spdadd 127.0.0.1 127.0.0.1 any
-ctx 1 1 "system_u:object_r:ipsec_spd_t:s0-s15:c0.c1023" 
-P in ipsec ah/transport//require;

I used ah so I could see more info in the tcpdump. :-)

> > As for sequence numbers, their use is optional and we can
> > specify/document that when using loopback, we recommend you do not use
> > them since loopback has guaranteed delivery. Because yes, packets can
> > get dropped when using sequence numbers and window size.
> 
> Good to know.
> 
> > And last but not least, I started a labeled ipsec over loopback stress
> > test last night. So far it has been running for 15 hours.
> > isakmp lifetime is 30 minutes
> > ipsec sa lifetime is 15 minutes
> > esp used over tcp and udp.
> >
> > I have noticed only one thing that I am concerned about.
> > I have not yet figured out what it means. Although pfkey ADD fails, I
> > believe the new SA has been entered because when I dump the databases, I
> > notice the new spis in the SAs.The old ones are gone...
> >
> > My log file has the following. I think it occurs for each rekeying.
> >
> > Jan 31 15:12:46 tim-hv4 racoon: INFO: IPsec-SA expired: ESP/Transport
> > 127.0.0.1[0]->127.0.0.1[0] spi=29906937(0x1c857f9)
> > Jan 31 15:12:47 tim-hv4 racoon: INFO: IPsec-SA expired: ESP/Transport
> > 127.0.0.1[0]->127.0.0.1[0] spi=200715915(0xbf6ae8b)
> > Jan 31 15:12:47 tim-hv4 racoon: INFO: initiate new phase 2 negotiation:
> > 127.0.0.1[0]<=>127.0.0.1[0]
> > Jan 31 15:12:47 tim-hv4 racoon: INFO: respond new phase 2 negotiation:
> > 127.0.0.1[0]<=>127.0.0.1[0]
> > Jan 31 15:12:49 tim-hv4 racoon: INFO: IPsec-SA established:
> > ESP/Transport 127.0.0.1[0]->127.0.0.1[0] spi=211935989(0xca1e2f5)
> > Jan 31 15:12:49 tim-hv4 racoon: ERROR: pfkey ADD failed: File exists
> > Jan 31 15:12:49 tim-hv4 racoon: INFO: IPsec-SA established:
> > ESP/Transport 127.0.0.1[0]->127.0.0.1[0] spi=251963520(0xf04a880)
> > Jan 31 15:12:49 tim-hv4 racoon: ERROR: pfkey ADD failed: File exists
> 
> I saw that too, like I said, the patch was simply a proof-of-concept showing 
> what needed to be done to allow racoon to negotiate with itself; there is 
> still work that needs to be done before it is ready for actual use.
> 
I think we should figure out why this is happening. And then you should
send it to the ipsec-tools list. They are far more expert than I and may
be aware of things I am not.

By the way the loopback stress completed a 16.5 hour run. Only problem I
saw was that message. 

Joy