Re: Brindle example of labeled IPSec

[Joshua Brindle <method@manicmethod.com>]

Clarkson, Mike R (US SSA) wrote:
>   
>>>> 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()
>>
>>     
>
> That's the same as corenet_non_ipsec_sendrecv(). They both just call
> kernel_sendrecv_unlabeled_packets().
>   

perhaps just call kernel_sendrecv_unlabeled_packets then?



--
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.