> -----Original Message----- > From: Joshua Brindle [mailto:method@xxxxxxxxxxxxxxx] > Sent: Friday, February 15, 2008 4:26 PM > To: Clarkson, Mike R (US SSA) > Cc: Paul Moore; selinux@xxxxxxxxxxxxx > Subject: Re: Brindle example of labeled IPSec > > Clarkson, Mike R (US SSA) wrote: > > 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; > > > > > > Hopefully this will clear up the questions, though it may sound very > very confusing... > > So, in this article I didn't cover dynamic security associations using > racoon (this was just an introduction on the topic and racoon makes it > more complicated). Therefore I didn't cover the use of SPD entries and > that is why polmatch was never used. Even though polmatch uses the same > object class as the other permissions it is really referring to the > ipsec SPD associations and not the actual associations used for > communication. > > So that explains the polmatch part, hopefully.. > > As for the recvfrom part, in your policy you have: > > corenet_non_ipsec_sendrecv(brindle_client_t) > > > this interface allows a domain to receive from unlabeled ipsec > connections, which means it will work regardless of associations being > present, be sure to remove interfaces like this before testing in > enforcing. > > > True that the non_ipsec interface will allow the client and server to communicate, but it wouldn't be a labeled communication, which means the output of the client and server should look like this: [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 know that it is sending the packets over the labeled IPSec loopback, because it stops working when I remove the SPDs using "setkey -FP" In any case, it quits working when I replace corenet_non_ipsec_sendrecv(brindle_client_t) with ipsec_labeled(brindle_client_t) and do likewise for the server. And I get the following from audit2allow: #============= brindle_client_t ============== # src="brindle_client_t" tgt="unlabeled_t" class="packet", perms="send" # comm="brindle_client" exe="" path="" allow brindle_client_t unlabeled_t:packet send; Is there something else that I need to provide? > 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 > > > > > > Right, I think the idea that we had here was to combine ipsec for > 'course labels with TE and a level range' and netlabel for fine grained > MLS labels. This, of course, was not something I covered in the article. > This should also work fine over loopback. > > > > > -- > > 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. > > > > > -- 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.
