Brindle example of labeled IPSec

Brindle example of labeled IPSec

[Clarkson, Mike R (US SSA)]

I'm running the server client example that Joshua Brindle provided in
his article on labeled IPSec.

 
http://securityblog.org/brindle/2007/05/28/secure-networking-with-selinu
x

I'm running this example on a single host using labeled IPSec over the
loopback interface. I've created brindle_server and brindle_client
domains, which I've included at the bottom of this email.

What's confusing are the rules that I did NOT have to provide. 

Here are the rules that I would have expected were required on the
client side, but are missing:
allow brindle_client_t ipsec_spd_t:association polmatch;
allow brindle_client_t brindle_server_t:association recvfrom;

I would expect equivalent rules to be necessary on the server side as
well. However, without these rules, the client and server work fine in
enforcing mode. Here is the output of the server and client:

[mr_clarkson@blade5 test]$ ./brindle_server
server: got connection from 127.0.0.1,
root:staff_r:brindle_client_t:SystemLow-S
ystemHigh

[mr_clarkson@blade5 test]$ ./brindle_client 127.0.0.1
Received: Hello, root:staff_r:brindle_client_t:SystemLow-SystemHigh from
root:staff_r:brindle_server_t:SystemLow-SystemHigh

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.

I've included the setkey cmds and policy module rules below for
reference.

Here are the setkey cmds that I execute to create the SPDs:
spdflush;
flush;
spdadd 127.0.0.1 127.0.0.1 any
-ctx 1 1 "system_u:object_r:ipsec_spd_t:s0-s4:c0.c255"
-P in ipsec esp/transport//require;
spdadd 127.0.0.1 127.0.0.1 any
-ctx 1 1 "system_u:object_r:ipsec_spd_t:s0-s4:c0.c255"
-P out ipsec esp/transport//require;


contents of brindle_server.te:
------------------------------------------------------------------
policy_module(brindle_server,1.0.0) 

## This module is designed for the brindle_server processes,
## which is a simple server used to test Labeled IPSec

################################
    # Declarations

  type brindle_server_t;
  domain_type(brindle_server_t)

  ## Access to shared libraries
  libs_use_ld_so(brindle_server_t)
  libs_use_shared_libs(brindle_server_t)

  miscfiles_read_localization(brindle_server_t)

  ## Type of the exec, which is the entrypoint into brindle_server_t
  type brindle_server_exec_t;
  files_type(brindle_server_exec_t)
  domain_entry_file(brindle_server_t, brindle_server_exec_t)


  ## allow transitions from staff_t to brindle_server_t
  gen_require(`
    type staff_t;
  ')

  userdom_entry_spec_domtrans_unpriv_users(brindle_server_t)
  domain_auto_trans(staff_t, brindle_server_exec_t, brindle_server_t)

  ## allow brindle_server domain to use sshd file descriptors
  ssh_use_fd(brindle_server_t)

  ## Allow brindle_server domain to use newrole file descriptors. Needed
  ## if we newrole to a new shell before running 
  seutil_use_newrole_fds(brindle_server_t)

  ## allow brindle_server domains to use staff_devpts_t 
  userdom_use_user_terminals(staff, brindle_server_t)

  ## allow brindle_server_t to send a SIGCHLD signal back to the shell
process
  ## to notify the shell that the brindle_server_t child process has
ended
  allow brindle_server_t staff_t:process sigchld;

  fs_search_auto_mountpoints(brindle_server_t)
  files_read_etc_files(brindle_server_t)
  files_search_home(brindle_server_t)
  fs_search_nfs(brindle_server_t)
  files_search_usr(brindle_server_t)

  ## These aren't really needed
  ##allow brindle_server_t security_t:dir search;
  ##allow brindle_server_t security_t:file read;
  selinux_get_enforce_mode(brindle_server_t)
  ##allow brindle_server_t selinux_config_t:dir search;
  ##allow brindle_server_t selinux_config_t:file { read getattr };
  seutil_read_config(brindle_server_t)

  ## Allow TCP networking
  ##allow brindle_server_t inaddr_any_node_t:tcp_socket node_bind;
  corenet_tcp_bind_inaddr_any_node(brindle_server_t)
  allow brindle_server_t self:tcp_socket { bind create setopt accept
listen write getopt};
  ##allow brindle_server_t unlabeled_t:packet { recv send };
  corenet_non_ipsec_sendrecv(brindle_server_t)

  ## role statements
  role staff_r types brindle_server_t;
------------------------------------------------------------------

contents of brindle_client.te:
------------------------------------------------------------------
policy_module(brindle_client,1.0.0) 

## This module is designed for the brindle_client processes,
## which is a simple client used to test Labeled IPSec

################################
    # Declarations

  type brindle_client_t;
  domain_type(brindle_client_t)

  ## Access to shared libraries
  libs_use_ld_so(brindle_client_t)
  libs_use_shared_libs(brindle_client_t)

  miscfiles_read_localization(brindle_client_t)

  ## Type of the exec, which is the entrypoint into brindle_client_t
  type brindle_client_exec_t;
  files_type(brindle_client_exec_t)
  domain_entry_file(brindle_client_t, brindle_client_exec_t)


  ## allow transitions from staff_t to brindle_client_t
  gen_require(`
    type staff_t;
  ')

  userdom_entry_spec_domtrans_unpriv_users(brindle_client_t)
  domain_auto_trans(staff_t, brindle_client_exec_t, brindle_client_t)

  ## allow brindle_client domain to use sshd file descriptors
  ssh_use_fd(brindle_client_t)

  ## Allow brindle_client domain to use newrole file descriptors. Needed
  ## if we newrole to a new shell before running 
  seutil_use_newrole_fds(brindle_client_t)

  ## allow brindle_client domains to use staff_devpts_t 
  userdom_use_user_terminals(staff, brindle_client_t)

  ## allow brindle_client_t to send a SIGCHLD signal back to the shell
process
  ## to notify the shell that the brindle_client_t child process has
ended
  allow brindle_client_t staff_t:process sigchld;

  ## give access to /etc/resolv.conf, which is used to get access to
  ## the DNS
  ##allow brindle_client_t net_conf_t:file { read getattr };
  sysnet_read_config(brindle_client_t)

  fs_search_auto_mountpoints(brindle_client_t)
  files_read_etc_files(brindle_client_t)
  files_search_home(brindle_client_t)
  fs_search_nfs(brindle_client_t)
  files_search_usr(brindle_client_t)

  ## These aren't really needed
  ##allow brindle_client_t security_t:dir search;
  ##allow brindle_client_t security_t:file read;
  selinux_get_enforce_mode(brindle_client_t)
  ##allow brindle_client_t selinux_config_t:dir search;
  ##allow brindle_client_t selinux_config_t:file { read getattr };
  seutil_read_config(brindle_client_t)

  ## Allow TCP networking
  allow brindle_client_t self:tcp_socket { read getopt create connect };
  ##allow brindle_client_t port_t:tcp_socket name_connect;
  corenet_tcp_connect_generic_port(brindle_client_t)
  ##allow brindle_server_t unlabeled_t:packet { recv send };
  corenet_non_ipsec_sendrecv(brindle_client_t)

  ## role statements
  role staff_r types brindle_client_t;
------------------------------------------------------------------



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

Re: Brindle example of labeled IPSec

[Paul Moore]

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.

-- 
paul moore
linux security @ hp

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

RE: Brindle example of labeled IPSec

[Clarkson, Mike R (US SSA)]

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;

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

Re: Brindle example of labeled IPSec

[Paul Moore]

On Friday 15 February 2008 6:25:45 pm Clarkson, Mike R (US SSA) wrote:
> I understand why there is no labeling after doing "setkey -FP". That
> was expected.

I'm sorry, I mis-read your original question.

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

That is interesting isn't it?  I don't have an answer off the top of my 
head which means I need to go and dig through the kernel and policy to 
try and piece together what is going on.  What kernel version and 
policy version are you running?

-- 
paul moore
linux security @ hp

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

RE: Brindle example of labeled IPSec

[Clarkson, Mike R (US SSA)]

> -----Original Message-----
> From: Paul Moore [mailto:paul.moore@hp.com]
> Sent: Friday, February 15, 2008 3:43 PM
> To: Clarkson, Mike R (US SSA)
> Cc: selinux@tycho.nsa.gov
> Subject: Re: Brindle example of labeled IPSec
> 
> On Friday 15 February 2008 6:25:45 pm Clarkson, Mike R (US SSA) wrote:
> > I understand why there is no labeling after doing "setkey -FP". That
> > was expected.
> 
> I'm sorry, I mis-read your original question.
> 
> > 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.
> 
> That is interesting isn't it?  I don't have an answer off the top of
my
> head which means I need to go and dig through the kernel and policy to
> try and piece together what is going on.  What kernel version and
> policy version are you running?

Kernel: 2.6.18-53.el5 (x86_64)
Policy: RHEL5.1

Thanks

> 
> --
> paul moore
> linux security @ hp



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

RE: Brindle example of labeled IPSec

[Clarkson, Mike R (US SSA)]

Sorry. I forgot to include the policy version in my original response.
See below

> -----Original Message-----
> From: Clarkson, Mike R (US SSA)
> Sent: Friday, February 15, 2008 3:48 PM
> To: 'Paul Moore'
> Cc: selinux@tycho.nsa.gov
> Subject: RE: Brindle example of labeled IPSec
> 
> 
> 
> > -----Original Message-----
> > From: Paul Moore [mailto:paul.moore@hp.com]
> > Sent: Friday, February 15, 2008 3:43 PM
> > To: Clarkson, Mike R (US SSA)
> > Cc: selinux@tycho.nsa.gov
> > Subject: Re: Brindle example of labeled IPSec
> >
> > On Friday 15 February 2008 6:25:45 pm Clarkson, Mike R (US SSA)
wrote:
> > > I understand why there is no labeling after doing "setkey -FP".
That
> > > was expected.
> >
> > I'm sorry, I mis-read your original question.
> >
> > > 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.
> >
> > That is interesting isn't it?  I don't have an answer off the top of
my
> > head which means I need to go and dig through the kernel and policy
to
> > try and piece together what is going on.  What kernel version and
> > policy version are you running?
> 
> Kernel: 2.6.18-53.el5 (x86_64)
> Policy: RHEL5.1

Policy Version & Type: v.21 (binary, MLS)

> 
> Thanks
> 
> >
> > --
> > paul moore
> > linux security @ hp



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

Re: Brindle example of labeled IPSec

[Joshua Brindle]

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.


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



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

RE: Brindle example of labeled IPSec

[Clarkson, Mike R (US SSA)]

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

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




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

Re: Brindle example of labeled IPSec

[Joshua Brindle]

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.

RE: Brindle example of labeled IPSec

[Clarkson, Mike R (US SSA)]

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



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

Re: Brindle example of labeled IPSec

[Joshua Brindle]

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.

RE: Brindle example of labeled IPSec

[Joy Latten]

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

If I recall correctly, these rules are in Redhat's policy.
The interface ipsec_labeled(domain) allows types with
domain attribute to polmatch to ipsec_spd_t and to also
have recvfrom and sendto permissions. When you did
domain_type(brindle_server_t) and domain_type(brindle_clent_t)
they acquired the domain attribute.

As long as you use ipsec_spd_t as default ipsec policy type,
things should work without having to add new policy for labeled ipsec.
However, if you create or use a new ipsec policy type other
than ipsec_spd_t, you will need new rules to get labeled ipsec working.

What I am not sure I understand is why you want to add mls constraints to 
these rules. I think mls constraints already exist for "association".
Unless you want to add them for your client and server...

regards,
Joy

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

RE: Brindle example of labeled IPSec

[Clarkson, Mike R (US SSA)]

> -----Original Message-----
> From: Joy Latten [mailto:latten@austin.ibm.com]
> Sent: Friday, February 15, 2008 4:27 PM
> To: Clarkson, Mike R (US SSA)
> Cc: selinux@tycho.nsa.gov
> Subject: RE: Brindle example of labeled IPSec
> 
> 
> >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.
> 
> If I recall correctly, these rules are in Redhat's policy.
> The interface ipsec_labeled(domain) allows types with
> domain attribute to polmatch to ipsec_spd_t and to also
> have recvfrom and sendto permissions. When you did
> domain_type(brindle_server_t) and domain_type(brindle_clent_t)
> they acquired the domain attribute.
> 
> As long as you use ipsec_spd_t as default ipsec policy type,
> things should work without having to add new policy for labeled ipsec.
> However, if you create or use a new ipsec policy type other
> than ipsec_spd_t, you will need new rules to get labeled ipsec
working.

I agree with everything that you've mentioned above, the only problem
being that my brindle_client and brindle_server modules didn't call the
ipsec_labeled interface. That's why I'm confused as to why it is
working. It shouldn't be working.

> 
> What I am not sure I understand is why you want to add mls constraints
to
> these rules. I think mls constraints already exist for "association".
> Unless you want to add them for your client and server...

I don't want to add MLS constraints to these rules, as you mentioned
they already exist. The problem is that because I don't have to add the
TE rules for the "association" class in my policy, the policy can not
enforce the MLS constraints that already exist.

> 
> regards,
> Joy



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

RE: Brindle example of labeled IPSec

[Joy Latten]

>I agree with everything that you've mentioned above, the only problem
>being that my brindle_client and brindle_server modules didn't call the
>ipsec_labeled interface. That's why I'm confused as to why it is
>working. It shouldn't be working.

It's been a while and I don't have the policy in front of me, 
so others may be better able to answer this...
The base reference policy (when using mls) contains this rule. It has a
rule, ipsec_labeled(domain). 


regards,
Joy

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

RE: Brindle example of labeled IPSec

[Clarkson, Mike R (US SSA)]

Ohhhhh ... I see your point now.

The mere fact that I've called domain_type(brindle_client_t) may give me
ipsec_labeled(domain) for free. I'll look into that.

Thank you!!!

> -----Original Message-----
> From: Joy Latten [mailto:latten@austin.ibm.com]
> Sent: Friday, February 15, 2008 5:41 PM
> To: Clarkson, Mike R (US SSA)
> Cc: selinux@tycho.nsa.gov
> Subject: RE: Brindle example of labeled IPSec
> 
> >I agree with everything that you've mentioned above, the only problem
> >being that my brindle_client and brindle_server modules didn't call
the
> >ipsec_labeled interface. That's why I'm confused as to why it is
> >working. It shouldn't be working.
> 
> It's been a while and I don't have the policy in front of me,
> so others may be better able to answer this...
> The base reference policy (when using mls) contains this rule. It has
a
> rule, ipsec_labeled(domain).
> 
> 
> regards,
> Joy



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

RE: Brindle example of labeled IPSec

[Clarkson, Mike R (US SSA)]

Yes, domain.te calls ipsec_labeled(domain) if the allow_ipsec_label
boolean is set to true, so this is provided for all domain types.

That answers it.

Thanks to everyone who looked at this for me!!!

> -----Original Message-----
> From: Clarkson, Mike R (US SSA)
> Sent: Friday, February 15, 2008 5:48 PM
> To: 'Joy Latten'
> Cc: selinux@tycho.nsa.gov
> Subject: RE: Brindle example of labeled IPSec
> 
> Ohhhhh ... I see your point now.
> 
> The mere fact that I've called domain_type(brindle_client_t) may give
me
> ipsec_labeled(domain) for free. I'll look into that.
> 
> Thank you!!!
> 
> > -----Original Message-----
> > From: Joy Latten [mailto:latten@austin.ibm.com]
> > Sent: Friday, February 15, 2008 5:41 PM
> > To: Clarkson, Mike R (US SSA)
> > Cc: selinux@tycho.nsa.gov
> > Subject: RE: Brindle example of labeled IPSec
> >
> > >I agree with everything that you've mentioned above, the only
problem
> > >being that my brindle_client and brindle_server modules didn't call
the
> > >ipsec_labeled interface. That's why I'm confused as to why it is
> > >working. It shouldn't be working.
> >
> > It's been a while and I don't have the policy in front of me,
> > so others may be better able to answer this...
> > The base reference policy (when using mls) contains this rule. It
has a
> > rule, ipsec_labeled(domain).
> >
> >
> > regards,
> > Joy



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