Hi Paul, I didn't make my original question clear enough. Please see comments below. Thanks, Mike > -----Original Message----- > From: Paul Moore [mailto:paul.moore@xxxxxx] > Sent: Friday, February 15, 2008 1:41 PM > To: Clarkson, Mike R (US SSA) > Cc: selinux@xxxxxxxxxxxxx > Subject: Re: Brindle example of labeled IPSec > > On Friday 15 February 2008 3:15:16 pm Clarkson, Mike R (US SSA) wrote: > > I'm running the server client example that Joshua Brindle provided in > > his article on labeled IPSec. > > ... > > > The output of the client and server show that the labels are being > > sent over the loopback, but just to convince myself that the labeled > > IPSec loopback was indeed being used, I flushed the SPDs and SADs > > using "setkey -FP" and "setkey -F". Afterward, I get the following > > output, which is expected when labeled IPSec is not being used: > > > > [mr_clarkson@blade5 test]$ ./brindle_server > > getsockopt: Protocol not available > > server: got connection from 127.0.0.1, (null) > > > > [mr_clarkson@blade5 test]$ ./brindle_client 127.0.0.1 > > getpeercon: Protocol not available > > Received: Hello, (null) from (null) > > > > I need the missing association rules (shown above) to be able to > > apply MLS constraints on the connection between the client and > > server. Any suggestions on how to fix this would be greatly > > appreciated. > > The problem is that you removed all of the IPsec labeling rules from the > SPD when you ran 'setkey -FP'. This means there is no IPsec processing > taking place and hence no labeling. You should be able to flush the > SAD as racoon will repopulate it on the fly, but clearing the SPD > removes the IPsec configuration from the kernel which is something you > probably didn't intend to do. > I understand why there is no labeling after doing "setkey -FP". That was expected. My question is why does the labeling work in enforcing mode, even though my policy does not provide the following rules: allow brindle_client_t ipsec_spd_t:association polmatch; allow brindle_client_t brindle_server_t:association recvfrom; With labeled IPSec over the loopback, I did not have to provide any rules in my brindle_client module or my brindle_server module with respect to the association object class. Without the association rules, the policy doesn't have any way of enforcing MLS constraints, or TE on the client server connections, which is the reason that I set up labeled IPSec over loopback in the first place. Any help would be much appreciated, Thanks -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@xxxxxxxxxxxxx with the words "unsubscribe selinux" without quotes as the message.
