labeled ipsec policy

labeled ipsec policy

[Joy Latten]

The following policy enables labeled ipsec to run
in enforcing mode. I configure labeled ipsec in sysadm_r role. 
Thus the rules I needed were specific to this role.

This is just what I needed to get it to work and use labels,
please feel free to modify this and make corrections.
I was not sure if anyone had started this work.
I am not sure where this should even reside in refpolicy modules.
I apologize if this email gets long, but I wanted to make sure
I  tried to explain everything.

Included are some interfaces, which I used in an xxxx.if
file. Then, there are a bunch of rules which I used in a xxxx.te file
These rules were just an example of what I needed
to get ping, nc, and ssh to work with labeled ipsec. For my
policy, I used the types unlabeled_t, passwd_t, and ipsec_spd_t.
When using passwd_t, ipsec_spd_t or any other domain, please be 
mindful of mls constraints. 

I am still "playing" with labeled ipsec, so I don't think this policy
is absolute and totally correct. :-)

The interfaces:
ipsec_set_label() 
	-setkey needs to be able to add an ipsec policy containing a
	security context to the SPD.
	-racoon/setkey need to be able to add SAs containing security
	context to the SAD.
	-A sysadm would use this interface to enter the domain of the
	security context used in an ipsec policy entry.
	-A sysadm would also use this interface to enter the domain of
	the security context the SA will have.
	**NOTE: SAs pose a problem because there is the assumption you
              know the domain of the socket that will be created by an
	      application. i.e, a ping proccess opens a socket with 
	      ping_t, thus SA's security context is also ping_t.
	      sysadm would need to enter "ping_t" into this interface
	      so the SA could be added to the SAD. 

ipsec_label_sa_pol()
	-Enter the domain of the SA and the domain of the ipsec policy.
	The SA will be considered "within the range" of the ipsec policy.
	i.e. the domain of your ipsec policy is ipsec_spd_t, 
        you want ping_t SAs to be within range of ipsec_spd_t policy.
	racoon requires this in order to determine if
	a proposed SA "polmatches" to the SPD entry for the 
	traffic stream.
 	
ipsec_labels_send_recv()
	-Allow a socket to send and receive with an IPSec SA. 
	 It is assumed that the type of the IPSec SA is the
	 same as the domain of the socket which created and used
	 it.
	** NOTE: perhaps another interface is needed to allow 
	a socket to use an SA of a different type than the socket.
	i.e. allow sshd_t sysadm_ssh_t:association recvfrom;


ipsec_tools_utilites()
	-Enter the type of the process that can use setkey and racoon.
	-Actually, I kinda just grouped together all the rules that
	I needed to run racoon and setkey while in sysadm_r role.
	- I could not help but wonder if setkey and racoon should 
	  be run in sysadm_r role and transition into ipsec_t domain 
	  (see system/ipsec.te and system/ipsec.if) or left alone to 
	  run in sysadm domain. All the rules in this interface
	  are when racoon and ipsec run in sysadm_t domain.
	NOTE: ideally it seems to me these rules should 
	      be in a *.te file.
	

-----------------------------------------------------------------------------
xxxx.if 

## <summary>Labeled IPSec</summary>

########################################
## <summary>
##     	Allow setkey/racoon to add policy to the SPD or
##	Security Associations to the SAD with the specified
##	specified domain.
## </summary>
## <param name="domain">
##      <summary>
##	Domain specified in security context of IPSec policy entry
##	or IPSec SA.
##      </summary>
## </param>
#
interface(`ipsec_set_label',`
	gen_require(`
		type sysadm_t;
	')
	
	allow sysadm_t $1:association setcontext; 
')

########################################
## <summary>
##      Allow an IPSec SA to be within the range of an IPSec Policy.
## </summary>
## <param name="domain">
##      <summary>
##      1. The type of the IPSec SA 
##	2. The type of the IPSec Policy
##      </summary>
## </param>
#
interface(`ipsec_label_sa_pol',`
	
	allow $1 $2:association polmatch;
')

########################################
## <summary>
##      Allow a socket to send and receive with an IPSec SA.
##	Note: It is assumed that the type of the IPSec SA is same
##	      as the type of the socket that created it.
## </summary>
## <param name="domain">
##      <summary>
##      1. The type of the socket and the IPSec SA 
##      </summary>
## </param>
#

interface(`ipsec_labels_send_recv',`
		
	allow $1 self:association { recvfrom sendto };

')


########################################
## <summary>
##      Run ipsec utilities, setkey and racoon.
## </summary>
## <param name="domain">
##      <summary>
##      The type of the proces performing this action. 
##      </summary>
## </param>
#
interface(`ipsec_tools_utilities',`
	gen_require(`
		type isakmp_port_t;
		type inaddr_any_node_t;
	')

	# allow setkey and racoon to create and use a key socket.
	allow $1 self:key_socket { create read write setopt };

	# allow racoon to use ISAKMP port
	allow $1 isakmp_port_t:udp_socket name_bind;

	# allow racoon to use avc_has_perm in within_range() 
	# to determine if proposed SA "polmatches" to policy
	allow $1 self:netlink_selinux_socket { bind create read };

	# I think this is so racoon can listen on an admin port.
	allow $1 inaddr_any_node_t:tcp_socket node_bind;

	# to create, remove read lock in /var/racoon/
	ipsec_manage_pid($1)

	# in grabmyaddrs() socket(PF_ROUTE...)
	allow $1 self:netlink_route_socket { create_netlink_socket_perms };
')

-------------------------------------------------------------------------
xxxx.te

policy_module(ipsec_joy,1.0)

gen_require(`
	type sysadm_t;
	type passwd_t;
	type ping_t;
	type unlabeled_t;
	type sysadm_ssh_t;
	type sshd_t;
')

type ipsec_spd_t;

ipsec_tools_utilities(sysadm_t)

# use following domains in spd
ipsec_set_label(unlabeled_t)
ipsec_set_label(passwd_t)
ipsec_set_label(ipsec_spd_t)

# use following domains in SAs
ipsec_set_label(ping_t)
ipsec_set_label(sysadm_t) #for NC

# allow specified SA to be considered within range of specified policy
ipsec_label_sa_pol(ping_t, passwd_t) 
ipsec_label_sa_pol(sysadm_t, passwd_t)

ipsec_label_sa_pol(ping_t, unlabeled_t)
ipsec_label_sa_pol(sysadm_t, unlabeled_t)


ipsec_label_sa_pol(ping_t, ipsec_spd_t)
ipsec_label_sa_pol(sysadm_t, ipsec_spd_t)

# allow SAs to be used for sending and receiving
ipsec_labels_send_recv(ping_t)
ipsec_labels_send_recv(sysadm_t)

# for ssh
ipsec_set_label(sysadm_ssh_t) 
ipsec_set_label(sshd_t) 
ipsec_label_sa_pol(sysadm_ssh_t, unlabeled_t)
ipsec_label_sa_pol(sshd_t, unlabeled_t)
ipsec_labels_send_recv(sshd_t)
ipsec_labels_send_recv(sysadm_ssh_t)
allow sysadm_ssh_t sshd_t:association recvfrom; 
allow sshd_t sysadm_ssh_t:association recvfrom;


--
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: [redhat-lspp] labeled ipsec policy

[Joy Latten]

On Mon, 2006-11-20 at 10:00 -0500, Paul Moore wrote:
> On Friday 17 November 2006 5:30 pm, Joy Latten wrote:
> > The following policy enables labeled ipsec to run
> > in enforcing mode. I configure labeled ipsec in sysadm_r role.
> > Thus the rules I needed were specific to this role.
> 
> I'll let the policy gurus comment on the rest of the policy, but I think that 
> we would want only the secadm_r role (in the MLS/LSPP policy) to be able to 
> configure labeled IPsec.  Yes?
> 
Actually, I wondered about this too. But when I took a look at the
policy source, I noticed that in userdomain.te, sysadm_t was allowed
to execute ipsec programs ipsec_exec_mgmt(sysadm_t), so I just assumed I
should use sysadm_r role. Not sure if this was correct or not. Tried
secadm_r role out of curiousity and got quite a lot of avc denied
messages. So went with sysadm_r. :-)

If secadm_r should be used, please let me know as I would need to get
labeled ipsec working with policy in enforcing mode.

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: [redhat-lspp] labeled ipsec policy

[Paul Moore]

On Monday 20 November 2006 10:09 am, Joy Latten wrote:
> On Mon, 2006-11-20 at 10:00 -0500, Paul Moore wrote:
> > On Friday 17 November 2006 5:30 pm, Joy Latten wrote:
> > > The following policy enables labeled ipsec to run
> > > in enforcing mode. I configure labeled ipsec in sysadm_r role.
> > > Thus the rules I needed were specific to this role.
> >
> > I'll let the policy gurus comment on the rest of the policy, but I think
> > that we would want only the secadm_r role (in the MLS/LSPP policy) to be
> > able to configure labeled IPsec.  Yes?
>
> Actually, I wondered about this too. But when I took a look at the
> policy source, I noticed that in userdomain.te, sysadm_t was allowed
> to execute ipsec programs ipsec_exec_mgmt(sysadm_t), so I just assumed I
> should use sysadm_r role. Not sure if this was correct or not. Tried
> secadm_r role out of curiousity and got quite a lot of avc denied
> messages. So went with sysadm_r. :-)

Hmmm, I suspect this will probably be a problem as the IPsec management tools 
serve a dual purpose, they control the IPsec configuration (sysadm_r) as well 
as the policy relating to labeling SAs (secadm_r).  I guess we'll just have 
to settle for sysadm_r and deal with the fact that sysadm_r is going to have 
some control over the system's security policy in this case.

-- 
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: [redhat-lspp] labeled ipsec policy

[Casey Schaufler]

--- Paul Moore <paul.moore@hp.com> wrote:


> Hmmm, I suspect this will probably be a problem as
> the IPsec management tools 
> serve a dual purpose, they control the IPsec
> configuration (sysadm_r) as well 
> as the policy relating to labeling SAs (secadm_r). 
> I guess we'll just have 
> to settle for sysadm_r and deal with the fact that
> sysadm_r is going to have 
> some control over the system's security policy in
> this case.

Alternatively, you might consider a separate
network security administrator role that is
associated with those tools. It might be better
than giving sysadm_r the additional responsibility.


Casey Schaufler
casey@schaufler-ca.com

--
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: labeled ipsec policy

[Christopher J. PeBenito]

On Fri, 2006-11-17 at 16:30 -0600, Joy Latten wrote:
> The following policy enables labeled ipsec to run
> in enforcing mode. I configure labeled ipsec in sysadm_r role. 
> Thus the rules I needed were specific to this role.
[cut]
> Included are some interfaces, which I used in an xxxx.if
> file. Then, there are a bunch of rules which I used in a xxxx.te file
> These rules were just an example of what I needed
> to get ping, nc, and ssh to work with labeled ipsec. For my
> policy, I used the types unlabeled_t, passwd_t, and ipsec_spd_t.
> When using passwd_t, ipsec_spd_t or any other domain, please be 
> mindful of mls constraints. 
[cut]

> interface(`ipsec_set_label',`
> 	gen_require(`
> 		type sysadm_t;
> 	')
> 	
> 	allow sysadm_t $1:association setcontext; 
> ')

Interfaces are written from the perspective of the subject (except for a
few very specific cases), so the parameter should be the subject, not
the object.  Neglecting that, is this for sysadm_t instead of
ipsec_mgmt_t?  I suspect that we want to add an interface to the domain
module that allows setcontext on the domain attribute.

> interface(`ipsec_label_sa_pol',`	
> 	allow $1 $2:association polmatch;
> ')

Generally refpolicy would leave this as a raw rule these types are in
separate modules, in which case the interface would be in $2's module
and have a specific type instead of $2.

> interface(`ipsec_labels_send_recv',`		
> 	allow $1 self:association { recvfrom sendto };
> ')

This would be raw rule in refpolicy instead of an interface.

> interface(`ipsec_tools_utilities',`
> 	gen_require(`
> 		type isakmp_port_t;
> 		type inaddr_any_node_t;
> 	')
> 
> 	# allow setkey and racoon to create and use a key socket.
> 	allow $1 self:key_socket { create read write setopt };
> 
> 	# allow racoon to use ISAKMP port
> 	allow $1 isakmp_port_t:udp_socket name_bind;
> 
> 	# allow racoon to use avc_has_perm in within_range() 
> 	# to determine if proposed SA "polmatches" to policy
> 	allow $1 self:netlink_selinux_socket { bind create read };
> 
> 	# I think this is so racoon can listen on an admin port.
> 	allow $1 inaddr_any_node_t:tcp_socket node_bind;
> 
> 	# to create, remove read lock in /var/racoon/
> 	ipsec_manage_pid($1)
> 
> 	# in grabmyaddrs() socket(PF_ROUTE...)
> 	allow $1 self:netlink_route_socket { create_netlink_socket_perms };
> ')

Again, why is this needed, instead of ipsec_mgmt_t?

I suspect that the ipsec policy needs to be overhauled because I believe
it was oriented towards the KAME ipsec implementation (pluto, et al) and
was augmented to work with racoon afterwards.

-- 
Chris PeBenito
Tresys Technology, LLC
(410) 290-1411 x150


--
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: [redhat-lspp] Re: labeled ipsec policy

[Joy Latten]

On Tue, 2006-11-21 at 09:10 -0500, Christopher J. PeBenito wrote:
> On Fri, 2006-11-17 at 16:30 -0600, Joy Latten wrote:
> > The following policy enables labeled ipsec to run
> > in enforcing mode. I configure labeled ipsec in sysadm_r role. 
> > Thus the rules I needed were specific to this role.
> [cut]
> > Included are some interfaces, which I used in an xxxx.if
> > file. Then, there are a bunch of rules which I used in a xxxx.te file
> > These rules were just an example of what I needed
> > to get ping, nc, and ssh to work with labeled ipsec. For my
> > policy, I used the types unlabeled_t, passwd_t, and ipsec_spd_t.
> > When using passwd_t, ipsec_spd_t or any other domain, please be 
> > mindful of mls constraints. 
> [cut]
> 
> > interface(`ipsec_set_label',`
> > 	gen_require(`
> > 		type sysadm_t;
> > 	')
> > 	
> > 	allow sysadm_t $1:association setcontext; 
> > ')
> 
> Interfaces are written from the perspective of the subject (except for a
> few very specific cases), so the parameter should be the subject, not
> the object.  Neglecting that, is this for sysadm_t instead of
> ipsec_mgmt_t?  I suspect that we want to add an interface to the domain
> module that allows setcontext on the domain attribute.

Yes, this was for sysadm_t. I had taken a look at the current ipsec.if,
ipsec.te, ipsec.fc and userdomain.te files as well and had wondered why
we were not executing ipsec in the ipsec domain. It seem that the policy
in those files was more for pluto and its utilities than ipsec-tools'
utilities. 

So should racoon and setkey, the ipsec-tools' utiltites, be run in the
ipsec domain? Should the sysadm_r role only be allowed to configure
ipsec?
 
> > interface(`ipsec_label_sa_pol',`	
> > 	allow $1 $2:association polmatch;
> > ')
> 
> Generally refpolicy would leave this as a raw rule these types are in
> separate modules, in which case the interface would be in $2's module
> and have a specific type instead of $2.

Ok, I think I understand what you mean. From what I can tell of the code
for the "polmatch" permission, $2 will most likely always be the type of
the security context in the ipsec policy. However, this could be set to
anything by the sysadm. Should I setup a default? For example, assume
labeled ipsec policy to have a type of ipsec_spd_t? Thus a sysadm who
decides to use labels in his ipsec policy, by default could use
ipsec_spd_t for the type and specify whatever he/she wants for the mls
level. Then he/she would use the interface to say which domains he wants
to allow to "polmatch" to this. Does this sound reasonable? If so, I'll
make the change and also make sure this is documented.

> > interface(`ipsec_labels_send_recv',`		
> > 	allow $1 self:association { recvfrom sendto };
> > ')
> 
> This would be raw rule in refpolicy instead of an interface.

I am not too sure I understand. We need a rule allowing flow->sid to use
SA's sid to send. SA's type as well as flow's type will be that of the
socket. Thus it could be any application or daemon. Do I need to add
this rule to every daemon/application as a raw rule?  For example, in 
netutils.te, add this for ping?

> > interface(`ipsec_tools_utilities',`
> > 	gen_require(`
> > 		type isakmp_port_t;
> > 		type inaddr_any_node_t;
> > 	')
> > 
> > 	# allow setkey and racoon to create and use a key socket.
> > 	allow $1 self:key_socket { create read write setopt };
> > 
> > 	# allow racoon to use ISAKMP port
> > 	allow $1 isakmp_port_t:udp_socket name_bind;
> > 
> > 	# allow racoon to use avc_has_perm in within_range() 
> > 	# to determine if proposed SA "polmatches" to policy
> > 	allow $1 self:netlink_selinux_socket { bind create read };
> > 
> > 	# I think this is so racoon can listen on an admin port.
> > 	allow $1 inaddr_any_node_t:tcp_socket node_bind;
> > 
> > 	# to create, remove read lock in /var/racoon/
> > 	ipsec_manage_pid($1)
> > 
> > 	# in grabmyaddrs() socket(PF_ROUTE...)
> > 	allow $1 self:netlink_route_socket { create_netlink_socket_perms };
> > ')
> 
> Again, why is this needed, instead of ipsec_mgmt_t?
> 
> I suspect that the ipsec policy needs to be overhauled because I believe
> it was oriented towards the KAME ipsec implementation (pluto, et al) and
> was augmented to work with racoon afterwards.

I think you are correct. 

Right now racoon and setkey use ipsec_exec_t domain. Is this ok or
should it be ipsec_mgmt_t? Also, should I go ahead and make the
modifications for racoon and setkey to run in the ipsec domain (either
ipsec_exec_t or ipsec_mgmt_t) instead of sysadm_t domain ? I wouldn't
mind making an attempt at it with your help and as long as I knew you
would review it for me.

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: [redhat-lspp] Re: labeled ipsec policy

[Christopher J. PeBenito]

On Mon, 2006-11-27 at 14:51 -0600, Joy Latten wrote:
> On Tue, 2006-11-21 at 09:10 -0500, Christopher J. PeBenito wrote:
> > On Fri, 2006-11-17 at 16:30 -0600, Joy Latten wrote:
> > > The following policy enables labeled ipsec to run
> > > in enforcing mode. I configure labeled ipsec in sysadm_r role. 
> > > Thus the rules I needed were specific to this role.
> > [cut]
> > > Included are some interfaces, which I used in an xxxx.if
> > > file. Then, there are a bunch of rules which I used in a xxxx.te file
> > > These rules were just an example of what I needed
> > > to get ping, nc, and ssh to work with labeled ipsec. For my
> > > policy, I used the types unlabeled_t, passwd_t, and ipsec_spd_t.
> > > When using passwd_t, ipsec_spd_t or any other domain, please be 
> > > mindful of mls constraints. 
> > [cut]
> > > interface(`ipsec_set_label',`
> > > 	gen_require(`
> > > 		type sysadm_t;
> > > 	')
> > > 	
> > > 	allow sysadm_t $1:association setcontext; 
> > > ')
> > 
> > Interfaces are written from the perspective of the subject (except for a
> > few very specific cases), so the parameter should be the subject, not
> > the object.  Neglecting that, is this for sysadm_t instead of
> > ipsec_mgmt_t?  I suspect that we want to add an interface to the domain
> > module that allows setcontext on the domain attribute.
> 
> Yes, this was for sysadm_t. I had taken a look at the current ipsec.if,
> ipsec.te, ipsec.fc and userdomain.te files as well and had wondered why
> we were not executing ipsec in the ipsec domain. It seem that the policy
> in those files was more for pluto and its utilities than ipsec-tools'
> utilities. 
> 
> So should racoon and setkey, the ipsec-tools' utiltites, be run in the
> ipsec domain? Should the sysadm_r role only be allowed to configure
> ipsec?

I don't know all the little details of racoon and setkey, but I think
racoon would run in ipsec_t and setkey in ipsec_mgmt_t.  However, if the
policy is going to be overhauled, then racoon_t and setkey_t seem more
applicable.  Then we can just add aliases for compatibility.

For the non-MLS strict policy, sysadm should be able to run setkey.  For
MLS, I'd have to defer that to someone who knows if there are any
relevant LSPP requirements for this.

> > > interface(`ipsec_label_sa_pol',`	
> > > 	allow $1 $2:association polmatch;
> > > ')
> > 
> > Generally refpolicy would leave this as a raw rule these types are in
> > separate modules, in which case the interface would be in $2's module
> > and have a specific type instead of $2.
> 
> Ok, I think I understand what you mean. From what I can tell of the code
> for the "polmatch" permission, $2 will most likely always be the type of
> the security context in the ipsec policy. However, this could be set to
> anything by the sysadm. Should I setup a default? For example, assume
> labeled ipsec policy to have a type of ipsec_spd_t? Thus a sysadm who
> decides to use labels in his ipsec policy, by default could use
> ipsec_spd_t for the type and specify whatever he/she wants for the mls
> level. Then he/she would use the interface to say which domains he wants
> to allow to "polmatch" to this. Does this sound reasonable? If so, I'll
> make the change and also make sure this is documented.

I'm not very sure how users will use the SPD labeling.  I suspect that
they will be labeled with probably the other side's domain type.  For
example, if httpd_t and mozilla_t are connected, the SPD would be
mozilla_t on the http machine and httpd_t on the mozilla machine.

> > > interface(`ipsec_labels_send_recv',`		
> > > 	allow $1 self:association { recvfrom sendto };
> > > ')
> > 
> > This would be raw rule in refpolicy instead of an interface.
> 
> I am not too sure I understand. We need a rule allowing flow->sid to use
> SA's sid to send. SA's type as well as flow's type will be that of the
> socket. Thus it could be any application or daemon. Do I need to add
> this rule to every daemon/application as a raw rule?  For example, in 
> netutils.te, add this for ping?

In general, the network access needs to be specified in each of the
modules, just like all the socket, node, netif, etc already specified in
the modules.  For the send side, it also brings back to the question of
if the sendto check is needed, since it is always checked against self.
But that assumes there isn't a use case for being able to receive but
not send on labeled connections.  I don't have any strong indication
either way, except that netlabel only has a recvfrom check.

For the receive side, there is going to have to be an interface, for
example

interface(`apache_recvfrom',`
	allow $1 apache_t:association recvfrom;
')

and then you might see

apache_recvfrom(mozilla_t)

If the sendto check stays, we could conceivably add this to the above
interface:

	allow $1 self:association sendto;

> > > interface(`ipsec_tools_utilities',`
> > > 	gen_require(`
> > > 		type isakmp_port_t;
> > > 		type inaddr_any_node_t;
> > > 	')
> > > 
> > > 	# allow setkey and racoon to create and use a key socket.
> > > 	allow $1 self:key_socket { create read write setopt };
> > > 
> > > 	# allow racoon to use ISAKMP port
> > > 	allow $1 isakmp_port_t:udp_socket name_bind;
> > > 
> > > 	# allow racoon to use avc_has_perm in within_range() 
> > > 	# to determine if proposed SA "polmatches" to policy
> > > 	allow $1 self:netlink_selinux_socket { bind create read };
> > > 
> > > 	# I think this is so racoon can listen on an admin port.
> > > 	allow $1 inaddr_any_node_t:tcp_socket node_bind;
> > > 
> > > 	# to create, remove read lock in /var/racoon/
> > > 	ipsec_manage_pid($1)
> > > 
> > > 	# in grabmyaddrs() socket(PF_ROUTE...)
> > > 	allow $1 self:netlink_route_socket { create_netlink_socket_perms };
> > > ')
> > 
> > Again, why is this needed, instead of ipsec_mgmt_t?
> > 
> > I suspect that the ipsec policy needs to be overhauled because I believe
> > it was oriented towards the KAME ipsec implementation (pluto, et al) and
> > was augmented to work with racoon afterwards.
> 
> I think you are correct. 
> 
> Right now racoon and setkey use ipsec_exec_t domain. Is this ok or
> should it be ipsec_mgmt_t? Also, should I go ahead and make the
> modifications for racoon and setkey to run in the ipsec domain (either
> ipsec_exec_t or ipsec_mgmt_t) instead of sysadm_t domain ? I wouldn't
> mind making an attempt at it with your help and as long as I knew you
> would review it for me.

See my above comments.

-- 
Chris PeBenito
Tresys Technology, LLC
(410) 290-1411 x150


--
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: [redhat-lspp] Re: labeled ipsec policy

[Venkat Yekkirala]

> I'm not very sure how users will use the SPD labeling.  I suspect that
> they will be labeled with probably the other side's domain type.  For
> example, if httpd_t and mozilla_t are connected, the SPD would be
> mozilla_t on the http machine and httpd_t on the mozilla machine.
>

In the simplest case, you would just have a generic "labeled_ipsec_t" Type
that would be specified for all the spd rules that pertain to labeled-ipsec.
All the different domains that need to use labeled-ipsec would then polmatch
to labeled_ipsec_t.

The SAs will always and automatically be using the originating domain Type.
So, the SA from the client to server would be auto-labeled mozilla_t,
rss_aggregator_t, etc. (on both ends), and the SA from the server to client
would be auto-labeled httpd_t (again on both ends).


--
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: [redhat-lspp] Re: labeled ipsec policy

[Joy Latten]

On Wed, 2006-11-29 at 14:42 -0600, Venkat Yekkirala wrote:
> > I'm not very sure how users will use the SPD labeling.  I suspect that
> > they will be labeled with probably the other side's domain type.  For
> > example, if httpd_t and mozilla_t are connected, the SPD would be
> > mozilla_t on the http machine and httpd_t on the mozilla machine.
> >
> 
> In the simplest case, you would just have a generic "labeled_ipsec_t" Type
> that would be specified for all the spd rules that pertain to labeled-ipsec.
> All the different domains that need to use labeled-ipsec would then polmatch
> to labeled_ipsec_t.
> 
> The SAs will always and automatically be using the originating domain Type.
> So, the SA from the client to server would be auto-labeled mozilla_t,
> rss_aggregator_t, etc. (on both ends), and the SA from the server to client
> would be auto-labeled httpd_t (again on both ends).

Ok, so then I will go with my original idea of a type ipsec_spd_t and
create an interface that allows sysadmins to create selinux policy for
"polmatching" ipsec SAs to the ipsec policy type, ipsec_spd_t. Thanks!!

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: [redhat-lspp] Re: labeled ipsec policy

[Venkat Yekkirala]

> > > I'm not very sure how users will use the SPD labeling.  I 
> suspect that
> > > they will be labeled with probably the other side's 
> domain type.  For
> > > example, if httpd_t and mozilla_t are connected, the SPD would be
> > > mozilla_t on the http machine and httpd_t on the mozilla machine.
> > >
> > 
> > In the simplest case, you would just have a generic 
> "labeled_ipsec_t" Type
> > that would be specified for all the spd rules that pertain 
> to labeled-ipsec.
> > All the different domains that need to use labeled-ipsec 
> would then polmatch
> > to labeled_ipsec_t.
> > 
> > The SAs will always and automatically be using the 

s/always/always (when the spd rule has a context associate with it)/

> originating domain Type.
> > So, the SA from the client to server would be auto-labeled 
> mozilla_t,
> > rss_aggregator_t, etc. (on both ends), and the SA from the 
> server to client
> > would be auto-labeled httpd_t (again on both ends).
> 
> Ok, so then I will go with my original idea of a type ipsec_spd_t and
> create an interface that allows sysadmins to create selinux policy for
> "polmatching" ipsec SAs to the ipsec policy type, 
> ipsec_spd_t. Thanks!!
> 
> 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.