Re: Brindle example of labeled IPSec

[Joshua Brindle <method@manicmethod.com>]

Clarkson, Mike R (US SSA) wrote:
>   
>> -----Original Message-----
>> From: Joshua Brindle [mailto:method@manicmethod.com]
>> Sent: Friday, February 15, 2008 4:26 PM
>> To: Clarkson, Mike R (US SSA)
>> Cc: Paul Moore; selinux@tycho.nsa.gov
>> 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@hp.com]
>>>> Sent: Friday, February 15, 2008 1:41 PM
>>>> To: Clarkson, Mike R (US SSA)
>>>> Cc: selinux@tycho.nsa.gov
>>>> 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?
>
>   

I think corenet_sendrecv_unlabeled_packets()

>> 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@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.