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