[PATCH 0/4] Reference Policy patches for the new labeled networking code in 2.6.25

[PATCH 0/4] Reference Policy patches for the new labeled networking code in 2.6.25

[paul.moore]

Four relatively small patches to Reference Policy to support the new labeled
networking controls which are now in Linus' tree and scheduled for 2.6.25.
The first three patches have been posted previously but are not yet in SVN,
while the last patch is new.

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

[PATCH 1/4] REFPOL: Add "rogue" Fedora packet class permissions

[paul.moore]

At some point in the Fedora 6 timeframe the "flow_in" and "flow_out"
permissions were added to the "packet" class, most likely as part of the
ill-fated secid-reconciliation effort.  Despite the fact that these permissions
are not currently used they should be included in the Reference Policy as they
are now a permanent fixture in Fedora and it is crucial that the FLASK
defines be kept in sync.

This patch needs to be applied before any other patches that affect the
"packet" class, otherwise the resulting policy may not load.

Signed-off-by: Paul Moore <paul.moore@hp.com>
---
 policy/flask/access_vectors |    2 ++
 1 file changed, 2 insertions(+)

Index: refpolicy_svn_repo/policy/flask/access_vectors
===================================================================
--- refpolicy_svn_repo.orig/policy/flask/access_vectors
+++ refpolicy_svn_repo/policy/flask/access_vectors
@@ -650,6 +650,8 @@ class packet
 	send
 	recv
 	relabelto
+	flow_in		# not currently in use
+	flow_out	# not currently in use
 }
 
 class key

-- 
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: [PATCH 1/4] REFPOL: Add "rogue" Fedora packet class permissions

[Christopher J. PeBenito]

On Fri, 2008-02-08 at 16:25 -0500, paul.moore@hp.com wrote:
> plain text document attachment (refpol-flask_fedora_fix)
> At some point in the Fedora 6 timeframe the "flow_in" and "flow_out"
> permissions were added to the "packet" class, most likely as part of the
> ill-fated secid-reconciliation effort.  Despite the fact that these permissions
> are not currently used they should be included in the Reference Policy as they
> are now a permanent fixture in Fedora and it is crucial that the FLASK
> defines be kept in sync.
> 
> This patch needs to be applied before any other patches that affect the
> "packet" class, otherwise the resulting policy may not load.

Merged.


> Signed-off-by: Paul Moore <paul.moore@hp.com>
> ---
>  policy/flask/access_vectors |    2 ++
>  1 file changed, 2 insertions(+)
> 
> Index: refpolicy_svn_repo/policy/flask/access_vectors
> ===================================================================
> --- refpolicy_svn_repo.orig/policy/flask/access_vectors
> +++ refpolicy_svn_repo/policy/flask/access_vectors
> @@ -650,6 +650,8 @@ class packet
>  	send
>  	recv
>  	relabelto
> +	flow_in		# not currently in use
> +	flow_out	# not currently in use
>  }
>  
>  class key
> 
-- 
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.

[PATCH 2/4] REFPOL: Add forwarding permissions to the packet object class

[paul.moore]

Add the 'forward_in' and 'forward_out' permissions to the packet object class
to support the new forwarding controls added to the 2.6.25 kernel.

Signed-off-by: Paul Moore <paul.moore@hp.com>
---
 policy/flask/access_vectors |    2 ++
 1 file changed, 2 insertions(+)

Index: refpolicy_svn_repo/policy/flask/access_vectors
===================================================================
--- refpolicy_svn_repo.orig/policy/flask/access_vectors
+++ refpolicy_svn_repo/policy/flask/access_vectors
@@ -652,6 +652,8 @@ class packet
 	relabelto
 	flow_in		# not currently in use
 	flow_out	# not currently in use
+	forward_in
+	forward_out
 }
 
 class key

-- 
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: [PATCH 2/4] REFPOL: Add forwarding permissions to the packet object class

[Christopher J. PeBenito]

On Fri, 2008-02-08 at 16:25 -0500, paul.moore@hp.com wrote:
> plain text document attachment (refpol-flask_perms)
> Add the 'forward_in' and 'forward_out' permissions to the packet object class
> to support the new forwarding controls added to the 2.6.25 kernel.

Merged.


> Signed-off-by: Paul Moore <paul.moore@hp.com>
> ---
>  policy/flask/access_vectors |    2 ++
>  1 file changed, 2 insertions(+)
> 
> Index: refpolicy_svn_repo/policy/flask/access_vectors
> ===================================================================
> --- refpolicy_svn_repo.orig/policy/flask/access_vectors
> +++ refpolicy_svn_repo/policy/flask/access_vectors
> @@ -652,6 +652,8 @@ class packet
>  	relabelto
>  	flow_in		# not currently in use
>  	flow_out	# not currently in use
> +	forward_in
> +	forward_out
>  }
>  
>  class key
> 
-- 
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.

[PATCH 3/4] REFPOL: Remove the unlabeled_t SECMARK policy in kernel_sendrecv_unlabeled_association

[paul.moore]

There is really no need for the SECMARK policy hack in the
kernel_sendrecv_unlabeled_association() interface since we already have an
interface call, kernel_sendrecv_unlabeled_packets(), which handles the
unlabeled SECMARK case.  Remove the hack and use the
kernel_sendrecv_unlabeled_packets() where appropriate.

Signed-off-by: Paul Moore <paul.moore@hp.com>
---
 policy/modules/kernel/corenetwork.if.in |    4 ++++
 policy/modules/kernel/kernel.if         |    3 ---
 2 files changed, 4 insertions(+), 3 deletions(-)

Index: refpolicy_svn_repo/policy/modules/kernel/corenetwork.if.in
===================================================================
--- refpolicy_svn_repo.orig/policy/modules/kernel/corenetwork.if.in
+++ refpolicy_svn_repo/policy/modules/kernel/corenetwork.if.in
@@ -1752,6 +1752,7 @@ interface(`corenet_tcp_recvfrom_netlabel
 #
 interface(`corenet_tcp_recvfrom_unlabeled',`
 	kernel_tcp_recvfrom_unlabeled($1)
+	kernel_sendrecv_unlabeled_packets($1)
 
 	# XXX - at some point the oubound/send access check will be removed
 	# but for right now we need to keep this in place so as not to break
@@ -1859,6 +1860,7 @@ interface(`corenet_udp_recvfrom_netlabel
 #
 interface(`corenet_udp_recvfrom_unlabeled',`
 	kernel_udp_recvfrom_unlabeled($1)
+	kernel_sendrecv_unlabeled_packets($1)
 
 	# XXX - at some point the oubound/send access check will be removed
 	# but for right now we need to keep this in place so as not to break
@@ -1966,6 +1968,7 @@ interface(`corenet_raw_recvfrom_netlabel
 #
 interface(`corenet_raw_recvfrom_unlabeled',`
 	kernel_raw_recvfrom_unlabeled($1)
+	kernel_sendrecv_unlabeled_packets($1)
 
 	# XXX - at some point the oubound/send access check will be removed
 	# but for right now we need to keep this in place so as not to break
@@ -2042,6 +2045,7 @@ interface(`corenet_all_recvfrom_unlabele
 	kernel_tcp_recvfrom_unlabeled($1)
 	kernel_udp_recvfrom_unlabeled($1)
 	kernel_raw_recvfrom_unlabeled($1)
+	kernel_sendrecv_unlabeled_packets($1)
 
 	# XXX - at some point the oubound/send access check will be removed
 	# but for right now we need to keep this in place so as not to break
Index: refpolicy_svn_repo/policy/modules/kernel/kernel.if
===================================================================
--- refpolicy_svn_repo.orig/policy/modules/kernel/kernel.if
+++ refpolicy_svn_repo/policy/modules/kernel/kernel.if
@@ -2255,9 +2255,6 @@ interface(`kernel_sendrecv_unlabeled_ass
 	')
 
 	allow $1 unlabeled_t:association { sendto recvfrom };
-
-	# temporary hack until labeling on packets is supported
-	allow $1 unlabeled_t:packet { send recv };
 ')
 
 ########################################

-- 
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: [PATCH 3/4] REFPOL: Remove the unlabeled_t SECMARK policy in kernel_sendrecv_unlabeled_association

[Christopher J. PeBenito]

On Fri, 2008-02-08 at 16:25 -0500, paul.moore@hp.com wrote:
> plain text document attachment (refpol-secmark_perms_fix)
> There is really no need for the SECMARK policy hack in the
> kernel_sendrecv_unlabeled_association() interface since we already have an
> interface call, kernel_sendrecv_unlabeled_packets(), which handles the
> unlabeled SECMARK case.  Remove the hack and use the
> kernel_sendrecv_unlabeled_packets() where appropriate.

I don't think this is any better as, in reality, there should be no
mixing of secmark rules with labeled networking rules since they are
orthogonal.


> Signed-off-by: Paul Moore <paul.moore@hp.com>
> ---
>  policy/modules/kernel/corenetwork.if.in |    4 ++++
>  policy/modules/kernel/kernel.if         |    3 ---
>  2 files changed, 4 insertions(+), 3 deletions(-)
> 
> Index: refpolicy_svn_repo/policy/modules/kernel/corenetwork.if.in
> ===================================================================
> --- refpolicy_svn_repo.orig/policy/modules/kernel/corenetwork.if.in
> +++ refpolicy_svn_repo/policy/modules/kernel/corenetwork.if.in
> @@ -1752,6 +1752,7 @@ interface(`corenet_tcp_recvfrom_netlabel
>  #
>  interface(`corenet_tcp_recvfrom_unlabeled',`
>  	kernel_tcp_recvfrom_unlabeled($1)
> +	kernel_sendrecv_unlabeled_packets($1)
>  
>  	# XXX - at some point the oubound/send access check will be removed
>  	# but for right now we need to keep this in place so as not to break
> @@ -1859,6 +1860,7 @@ interface(`corenet_udp_recvfrom_netlabel
>  #
>  interface(`corenet_udp_recvfrom_unlabeled',`
>  	kernel_udp_recvfrom_unlabeled($1)
> +	kernel_sendrecv_unlabeled_packets($1)
>  
>  	# XXX - at some point the oubound/send access check will be removed
>  	# but for right now we need to keep this in place so as not to break
> @@ -1966,6 +1968,7 @@ interface(`corenet_raw_recvfrom_netlabel
>  #
>  interface(`corenet_raw_recvfrom_unlabeled',`
>  	kernel_raw_recvfrom_unlabeled($1)
> +	kernel_sendrecv_unlabeled_packets($1)
>  
>  	# XXX - at some point the oubound/send access check will be removed
>  	# but for right now we need to keep this in place so as not to break
> @@ -2042,6 +2045,7 @@ interface(`corenet_all_recvfrom_unlabele
>  	kernel_tcp_recvfrom_unlabeled($1)
>  	kernel_udp_recvfrom_unlabeled($1)
>  	kernel_raw_recvfrom_unlabeled($1)
> +	kernel_sendrecv_unlabeled_packets($1)
>  
>  	# XXX - at some point the oubound/send access check will be removed
>  	# but for right now we need to keep this in place so as not to break
> Index: refpolicy_svn_repo/policy/modules/kernel/kernel.if
> ===================================================================
> --- refpolicy_svn_repo.orig/policy/modules/kernel/kernel.if
> +++ refpolicy_svn_repo/policy/modules/kernel/kernel.if
> @@ -2255,9 +2255,6 @@ interface(`kernel_sendrecv_unlabeled_ass
>  	')
>  
>  	allow $1 unlabeled_t:association { sendto recvfrom };
> -
> -	# temporary hack until labeling on packets is supported
> -	allow $1 unlabeled_t:packet { send recv };
>  ')
>  
>  ########################################
> 
-- 
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: [PATCH 3/4] REFPOL: Remove the unlabeled_t SECMARK policy in kernel_sendrecv_unlabeled_association

[Paul Moore]

On Tuesday 12 February 2008 9:37:21 am Christopher J. PeBenito wrote:
> On Fri, 2008-02-08 at 16:25 -0500, paul.moore@hp.com wrote:
> > plain text document attachment (refpol-secmark_perms_fix)
> > There is really no need for the SECMARK policy hack in the
> > kernel_sendrecv_unlabeled_association() interface since we already have
> > an interface call, kernel_sendrecv_unlabeled_packets(), which handles the
> > unlabeled SECMARK case.  Remove the hack and use the
> > kernel_sendrecv_unlabeled_packets() where appropriate.
>
> I don't think this is any better as, in reality, there should be no
> mixing of secmark rules with labeled networking rules since they are
> orthogonal.

First, thanks for merging the other changes.  Second, I suppose you are right 
about these changes, mixing them (never thought about it that way which is 
kinda funny everything considered) probably isn't the best thing to do long 
term.

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.

[PATCH 4/4] REFPOL: Add new labeled networking permissions

[paul.moore]

The 2.6.25 kernel will introduce a new set of labeled networking controls to
SELinux and this patch makes the necessary changes to the Reference Policy
to support unlabeled network traffic with the new controls.

A description of the new/improved labeled networking controls was posted to
the SELinux list back in early January 2008.

 * http://marc.info/?l=selinux&m=119991234501200&w=2

---
 policy/modules/kernel/corenetwork.if.in |   24 ++++++++++++------------
 policy/modules/kernel/kernel.if         |    6 ++++++
 policy/modules/kernel/kernel.te         |    3 +++
 3 files changed, 21 insertions(+), 12 deletions(-)

Index: refpolicy_svn_repo/policy/modules/kernel/corenetwork.if.in
===================================================================
--- refpolicy_svn_repo.orig/policy/modules/kernel/corenetwork.if.in
+++ refpolicy_svn_repo/policy/modules/kernel/corenetwork.if.in
@@ -154,7 +154,7 @@ interface(`corenet_tcp_sendrecv_generic_
 		type netif_t;
 	')
 
-	allow $1 netif_t:netif { tcp_send tcp_recv };
+	allow $1 netif_t:netif { tcp_send tcp_recv egress ingress };
 ')
 
 ########################################
@@ -172,7 +172,7 @@ interface(`corenet_udp_send_generic_if',
 		type netif_t;
 	')
 
-	allow $1 netif_t:netif udp_send;
+	allow $1 netif_t:netif { udp_send egress };
 ')
 
 ########################################
@@ -191,7 +191,7 @@ interface(`corenet_dontaudit_udp_send_ge
 		type netif_t;
 	')
 
-	dontaudit $1 netif_t:netif udp_send;
+	dontaudit $1 netif_t:netif { udp_send egress };
 ')
 
 ########################################
@@ -209,7 +209,7 @@ interface(`corenet_udp_receive_generic_i
 		type netif_t;
 	')
 
-	allow $1 netif_t:netif udp_recv;
+	allow $1 netif_t:netif { udp_recv ingress };
 ')
 
 ########################################
@@ -228,7 +228,7 @@ interface(`corenet_dontaudit_udp_receive
 		type netif_t;
 	')
 
-	dontaudit $1 netif_t:netif udp_recv;
+	dontaudit $1 netif_t:netif { udp_recv ingress };
 ')
 
 ########################################
@@ -277,7 +277,7 @@ interface(`corenet_raw_send_generic_if',
 		type netif_t;
 	')
 
-	allow $1 netif_t:netif rawip_send;
+	allow $1 netif_t:netif { rawip_send egress };
 ')
 
 ########################################
@@ -295,7 +295,7 @@ interface(`corenet_raw_receive_generic_i
 		type netif_t;
 	')
 
-	allow $1 netif_t:netif rawip_recv;
+	allow $1 netif_t:netif { rawip_recv ingress };
 ')
 
 ########################################
@@ -448,7 +448,7 @@ interface(`corenet_tcp_sendrecv_generic_
 		type node_t;
 	')
 
-	allow $1 node_t:node { tcp_send tcp_recv };
+	allow $1 node_t:node { tcp_send tcp_recv sendto recvfrom };
 ')
 
 ########################################
@@ -466,7 +466,7 @@ interface(`corenet_udp_send_generic_node
 		type node_t;
 	')
 
-	allow $1 node_t:node udp_send;
+	allow $1 node_t:node { udp_send sendto };
 ')
 
 ########################################
@@ -484,7 +484,7 @@ interface(`corenet_udp_receive_generic_n
 		type node_t;
 	')
 
-	allow $1 node_t:node udp_recv;
+	allow $1 node_t:node { udp_recv recvfrom };
 ')
 
 ########################################
@@ -517,7 +517,7 @@ interface(`corenet_raw_send_generic_node
 		type node_t;
 	')
 
-	allow $1 node_t:node rawip_send;
+	allow $1 node_t:node { rawip_send sendto };
 ')
 
 ########################################
@@ -535,7 +535,7 @@ interface(`corenet_raw_receive_generic_n
 		type node_t;
 	')
 
-	allow $1 node_t:node rawip_recv;
+	allow $1 node_t:node { rawip_recv recvfrom };
 ')
 
 ########################################
Index: refpolicy_svn_repo/policy/modules/kernel/kernel.if
===================================================================
--- refpolicy_svn_repo.orig/policy/modules/kernel/kernel.if
+++ refpolicy_svn_repo/policy/modules/kernel/kernel.if
@@ -2314,6 +2314,7 @@ interface(`kernel_tcp_recvfrom_unlabeled
 		type unlabeled_t;
 	')
 
+	allow $1 unlabeled_t:peer recv;
 	allow $1 unlabeled_t:tcp_socket recvfrom;
 ')
 
@@ -2343,6 +2344,7 @@ interface(`kernel_dontaudit_tcp_recvfrom
 		type unlabeled_t;
 	')
 
+	dontaudit $1 unlabeled_t:peer recv;
 	dontaudit $1 unlabeled_t:tcp_socket recvfrom;
 ')
 
@@ -2370,6 +2372,7 @@ interface(`kernel_udp_recvfrom_unlabeled
 		type unlabeled_t;
 	')
 
+	allow $1 unlabeled_t:peer recv;
 	allow $1 unlabeled_t:udp_socket recvfrom;
 ')
 
@@ -2399,6 +2402,7 @@ interface(`kernel_dontaudit_udp_recvfrom
 		type unlabeled_t;
 	')
 
+	dontaudit $1 unlabeled_t:peer recv;
 	dontaudit $1 unlabeled_t:udp_socket recvfrom;
 ')
 
@@ -2426,6 +2430,7 @@ interface(`kernel_raw_recvfrom_unlabeled
 		type unlabeled_t;
 	')
 
+	allow $1 unlabeled_t:peer recv;
 	allow $1 unlabeled_t:rawip_socket recvfrom;
 ')
 
@@ -2455,6 +2460,7 @@ interface(`kernel_dontaudit_raw_recvfrom
 		type unlabeled_t;
 	')
 
+	dontaudit $1 unlabeled_t:peer recv;
 	dontaudit $1 unlabeled_t:rawip_socket recvfrom;
 ')
 
Index: refpolicy_svn_repo/policy/modules/kernel/kernel.te
===================================================================
--- refpolicy_svn_repo.orig/policy/modules/kernel/kernel.te
+++ refpolicy_svn_repo/policy/modules/kernel/kernel.te
@@ -212,6 +212,9 @@ allow kernel_t unlabeled_t:dir mounton;
 # connections with invalidated labels:
 allow kernel_t unlabeled_t:packet send;
 
+# Forwarded traffic
+allow unlabeled_t unlabeled_t:packet { forward_in forward_out };
+
 corenet_all_recvfrom_unlabeled(kernel_t)
 corenet_all_recvfrom_netlabel(kernel_t)
 # Kernel-generated traffic e.g., ICMP replies:

-- 
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: [PATCH 4/4] REFPOL: Add new labeled networking permissions

[Christopher J. PeBenito]

On Fri, 2008-02-08 at 16:25 -0500, paul.moore@hp.com wrote:
> plain text document attachment (refpol-peer_perms)
> The 2.6.25 kernel will introduce a new set of labeled networking controls to
> SELinux and this patch makes the necessary changes to the Reference Policy
> to support unlabeled network traffic with the new controls.

The corenetwork part is missing changes in the cornetwork.if.m4 file.
Thats where the interfaces generated by a network_(node|interface)() are
generated.

I'm not so sure about the kernel interface changes.  The docs probably
should be revised, its more about using sockets whose types have been
invalidated.  It doesn't have anything to do with unlabeled networking.


> A description of the new/improved labeled networking controls was posted to
> the SELinux list back in early January 2008.
> 
>  * http://marc.info/?l=selinux&m=119991234501200&w=2
> 
> ---
>  policy/modules/kernel/corenetwork.if.in |   24 ++++++++++++------------
>  policy/modules/kernel/kernel.if         |    6 ++++++
>  policy/modules/kernel/kernel.te         |    3 +++
>  3 files changed, 21 insertions(+), 12 deletions(-)
> 
> Index: refpolicy_svn_repo/policy/modules/kernel/corenetwork.if.in
> ===================================================================
> --- refpolicy_svn_repo.orig/policy/modules/kernel/corenetwork.if.in
> +++ refpolicy_svn_repo/policy/modules/kernel/corenetwork.if.in
> @@ -154,7 +154,7 @@ interface(`corenet_tcp_sendrecv_generic_
>  		type netif_t;
>  	')
>  
> -	allow $1 netif_t:netif { tcp_send tcp_recv };
> +	allow $1 netif_t:netif { tcp_send tcp_recv egress ingress };
>  ')
>  
>  ########################################
> @@ -172,7 +172,7 @@ interface(`corenet_udp_send_generic_if',
>  		type netif_t;
>  	')
>  
> -	allow $1 netif_t:netif udp_send;
> +	allow $1 netif_t:netif { udp_send egress };
>  ')
>  
>  ########################################
> @@ -191,7 +191,7 @@ interface(`corenet_dontaudit_udp_send_ge
>  		type netif_t;
>  	')
>  
> -	dontaudit $1 netif_t:netif udp_send;
> +	dontaudit $1 netif_t:netif { udp_send egress };
>  ')
>  
>  ########################################
> @@ -209,7 +209,7 @@ interface(`corenet_udp_receive_generic_i
>  		type netif_t;
>  	')
>  
> -	allow $1 netif_t:netif udp_recv;
> +	allow $1 netif_t:netif { udp_recv ingress };
>  ')
>  
>  ########################################
> @@ -228,7 +228,7 @@ interface(`corenet_dontaudit_udp_receive
>  		type netif_t;
>  	')
>  
> -	dontaudit $1 netif_t:netif udp_recv;
> +	dontaudit $1 netif_t:netif { udp_recv ingress };
>  ')
>  
>  ########################################
> @@ -277,7 +277,7 @@ interface(`corenet_raw_send_generic_if',
>  		type netif_t;
>  	')
>  
> -	allow $1 netif_t:netif rawip_send;
> +	allow $1 netif_t:netif { rawip_send egress };
>  ')
>  
>  ########################################
> @@ -295,7 +295,7 @@ interface(`corenet_raw_receive_generic_i
>  		type netif_t;
>  	')
>  
> -	allow $1 netif_t:netif rawip_recv;
> +	allow $1 netif_t:netif { rawip_recv ingress };
>  ')
>  
>  ########################################
> @@ -448,7 +448,7 @@ interface(`corenet_tcp_sendrecv_generic_
>  		type node_t;
>  	')
>  
> -	allow $1 node_t:node { tcp_send tcp_recv };
> +	allow $1 node_t:node { tcp_send tcp_recv sendto recvfrom };
>  ')
>  
>  ########################################
> @@ -466,7 +466,7 @@ interface(`corenet_udp_send_generic_node
>  		type node_t;
>  	')
>  
> -	allow $1 node_t:node udp_send;
> +	allow $1 node_t:node { udp_send sendto };
>  ')
>  
>  ########################################
> @@ -484,7 +484,7 @@ interface(`corenet_udp_receive_generic_n
>  		type node_t;
>  	')
>  
> -	allow $1 node_t:node udp_recv;
> +	allow $1 node_t:node { udp_recv recvfrom };
>  ')
>  
>  ########################################
> @@ -517,7 +517,7 @@ interface(`corenet_raw_send_generic_node
>  		type node_t;
>  	')
>  
> -	allow $1 node_t:node rawip_send;
> +	allow $1 node_t:node { rawip_send sendto };
>  ')
>  
>  ########################################
> @@ -535,7 +535,7 @@ interface(`corenet_raw_receive_generic_n
>  		type node_t;
>  	')
>  
> -	allow $1 node_t:node rawip_recv;
> +	allow $1 node_t:node { rawip_recv recvfrom };
>  ')
>  
>  ########################################
> Index: refpolicy_svn_repo/policy/modules/kernel/kernel.if
> ===================================================================
> --- refpolicy_svn_repo.orig/policy/modules/kernel/kernel.if
> +++ refpolicy_svn_repo/policy/modules/kernel/kernel.if
> @@ -2314,6 +2314,7 @@ interface(`kernel_tcp_recvfrom_unlabeled
>  		type unlabeled_t;
>  	')
>  
> +	allow $1 unlabeled_t:peer recv;
>  	allow $1 unlabeled_t:tcp_socket recvfrom;
>  ')
>  
> @@ -2343,6 +2344,7 @@ interface(`kernel_dontaudit_tcp_recvfrom
>  		type unlabeled_t;
>  	')
>  
> +	dontaudit $1 unlabeled_t:peer recv;
>  	dontaudit $1 unlabeled_t:tcp_socket recvfrom;
>  ')
>  
> @@ -2370,6 +2372,7 @@ interface(`kernel_udp_recvfrom_unlabeled
>  		type unlabeled_t;
>  	')
>  
> +	allow $1 unlabeled_t:peer recv;
>  	allow $1 unlabeled_t:udp_socket recvfrom;
>  ')
>  
> @@ -2399,6 +2402,7 @@ interface(`kernel_dontaudit_udp_recvfrom
>  		type unlabeled_t;
>  	')
>  
> +	dontaudit $1 unlabeled_t:peer recv;
>  	dontaudit $1 unlabeled_t:udp_socket recvfrom;
>  ')
>  
> @@ -2426,6 +2430,7 @@ interface(`kernel_raw_recvfrom_unlabeled
>  		type unlabeled_t;
>  	')
>  
> +	allow $1 unlabeled_t:peer recv;
>  	allow $1 unlabeled_t:rawip_socket recvfrom;
>  ')
>  
> @@ -2455,6 +2460,7 @@ interface(`kernel_dontaudit_raw_recvfrom
>  		type unlabeled_t;
>  	')
>  
> +	dontaudit $1 unlabeled_t:peer recv;
>  	dontaudit $1 unlabeled_t:rawip_socket recvfrom;
>  ')
>  
> Index: refpolicy_svn_repo/policy/modules/kernel/kernel.te
> ===================================================================
> --- refpolicy_svn_repo.orig/policy/modules/kernel/kernel.te
> +++ refpolicy_svn_repo/policy/modules/kernel/kernel.te
> @@ -212,6 +212,9 @@ allow kernel_t unlabeled_t:dir mounton;
>  # connections with invalidated labels:
>  allow kernel_t unlabeled_t:packet send;
>  
> +# Forwarded traffic
> +allow unlabeled_t unlabeled_t:packet { forward_in forward_out };
> +
>  corenet_all_recvfrom_unlabeled(kernel_t)
>  corenet_all_recvfrom_netlabel(kernel_t)
>  # Kernel-generated traffic e.g., ICMP replies:
> 
-- 
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: [PATCH 4/4] REFPOL: Add new labeled networking permissions

[Paul Moore]

On Tuesday 12 February 2008 9:39:59 am Christopher J. PeBenito wrote:
> On Fri, 2008-02-08 at 16:25 -0500, paul.moore@hp.com wrote:
> > plain text document attachment (refpol-peer_perms)
> > The 2.6.25 kernel will introduce a new set of labeled networking controls
> > to SELinux and this patch makes the necessary changes to the Reference
> > Policy to support unlabeled network traffic with the new controls.
>
> The corenetwork part is missing changes in the cornetwork.if.m4 file.
> Thats where the interfaces generated by a network_(node|interface)() are
> generated.

Okay, I'll look into fixing that part up.

> I'm not so sure about the kernel interface changes.  The docs probably
> should be revised, its more about using sockets whose types have been
> invalidated.  It doesn't have anything to do with unlabeled networking.

Hmmm, okay.  Do you have a suggestion for how to add these new allow rules?  A 
new interface?  I would need to go check again, but these seemed to be the 
most logical of the existing interfaces when I made the change (and I suspect 
not much has changed in this area).

> > A description of the new/improved labeled networking controls was posted
> > to the SELinux list back in early January 2008.
> >
> >  * http://marc.info/?l=selinux&m=119991234501200&w=2
> >
> > ---
> >  policy/modules/kernel/corenetwork.if.in |   24 ++++++++++++------------
> >  policy/modules/kernel/kernel.if         |    6 ++++++
> >  policy/modules/kernel/kernel.te         |    3 +++
> >  3 files changed, 21 insertions(+), 12 deletions(-)
> >
> > Index: refpolicy_svn_repo/policy/modules/kernel/corenetwork.if.in
> > ===================================================================
> > --- refpolicy_svn_repo.orig/policy/modules/kernel/corenetwork.if.in
> > +++ refpolicy_svn_repo/policy/modules/kernel/corenetwork.if.in
> > @@ -154,7 +154,7 @@ interface(`corenet_tcp_sendrecv_generic_
> >  		type netif_t;
> >  	')
> >
> > -	allow $1 netif_t:netif { tcp_send tcp_recv };
> > +	allow $1 netif_t:netif { tcp_send tcp_recv egress ingress };
> >  ')
> >
> >  ########################################
> > @@ -172,7 +172,7 @@ interface(`corenet_udp_send_generic_if',
> >  		type netif_t;
> >  	')
> >
> > -	allow $1 netif_t:netif udp_send;
> > +	allow $1 netif_t:netif { udp_send egress };
> >  ')
> >
> >  ########################################
> > @@ -191,7 +191,7 @@ interface(`corenet_dontaudit_udp_send_ge
> >  		type netif_t;
> >  	')
> >
> > -	dontaudit $1 netif_t:netif udp_send;
> > +	dontaudit $1 netif_t:netif { udp_send egress };
> >  ')
> >
> >  ########################################
> > @@ -209,7 +209,7 @@ interface(`corenet_udp_receive_generic_i
> >  		type netif_t;
> >  	')
> >
> > -	allow $1 netif_t:netif udp_recv;
> > +	allow $1 netif_t:netif { udp_recv ingress };
> >  ')
> >
> >  ########################################
> > @@ -228,7 +228,7 @@ interface(`corenet_dontaudit_udp_receive
> >  		type netif_t;
> >  	')
> >
> > -	dontaudit $1 netif_t:netif udp_recv;
> > +	dontaudit $1 netif_t:netif { udp_recv ingress };
> >  ')
> >
> >  ########################################
> > @@ -277,7 +277,7 @@ interface(`corenet_raw_send_generic_if',
> >  		type netif_t;
> >  	')
> >
> > -	allow $1 netif_t:netif rawip_send;
> > +	allow $1 netif_t:netif { rawip_send egress };
> >  ')
> >
> >  ########################################
> > @@ -295,7 +295,7 @@ interface(`corenet_raw_receive_generic_i
> >  		type netif_t;
> >  	')
> >
> > -	allow $1 netif_t:netif rawip_recv;
> > +	allow $1 netif_t:netif { rawip_recv ingress };
> >  ')
> >
> >  ########################################
> > @@ -448,7 +448,7 @@ interface(`corenet_tcp_sendrecv_generic_
> >  		type node_t;
> >  	')
> >
> > -	allow $1 node_t:node { tcp_send tcp_recv };
> > +	allow $1 node_t:node { tcp_send tcp_recv sendto recvfrom };
> >  ')
> >
> >  ########################################
> > @@ -466,7 +466,7 @@ interface(`corenet_udp_send_generic_node
> >  		type node_t;
> >  	')
> >
> > -	allow $1 node_t:node udp_send;
> > +	allow $1 node_t:node { udp_send sendto };
> >  ')
> >
> >  ########################################
> > @@ -484,7 +484,7 @@ interface(`corenet_udp_receive_generic_n
> >  		type node_t;
> >  	')
> >
> > -	allow $1 node_t:node udp_recv;
> > +	allow $1 node_t:node { udp_recv recvfrom };
> >  ')
> >
> >  ########################################
> > @@ -517,7 +517,7 @@ interface(`corenet_raw_send_generic_node
> >  		type node_t;
> >  	')
> >
> > -	allow $1 node_t:node rawip_send;
> > +	allow $1 node_t:node { rawip_send sendto };
> >  ')
> >
> >  ########################################
> > @@ -535,7 +535,7 @@ interface(`corenet_raw_receive_generic_n
> >  		type node_t;
> >  	')
> >
> > -	allow $1 node_t:node rawip_recv;
> > +	allow $1 node_t:node { rawip_recv recvfrom };
> >  ')
> >
> >  ########################################
> > Index: refpolicy_svn_repo/policy/modules/kernel/kernel.if
> > ===================================================================
> > --- refpolicy_svn_repo.orig/policy/modules/kernel/kernel.if
> > +++ refpolicy_svn_repo/policy/modules/kernel/kernel.if
> > @@ -2314,6 +2314,7 @@ interface(`kernel_tcp_recvfrom_unlabeled
> >  		type unlabeled_t;
> >  	')
> >
> > +	allow $1 unlabeled_t:peer recv;
> >  	allow $1 unlabeled_t:tcp_socket recvfrom;
> >  ')
> >
> > @@ -2343,6 +2344,7 @@ interface(`kernel_dontaudit_tcp_recvfrom
> >  		type unlabeled_t;
> >  	')
> >
> > +	dontaudit $1 unlabeled_t:peer recv;
> >  	dontaudit $1 unlabeled_t:tcp_socket recvfrom;
> >  ')
> >
> > @@ -2370,6 +2372,7 @@ interface(`kernel_udp_recvfrom_unlabeled
> >  		type unlabeled_t;
> >  	')
> >
> > +	allow $1 unlabeled_t:peer recv;
> >  	allow $1 unlabeled_t:udp_socket recvfrom;
> >  ')
> >
> > @@ -2399,6 +2402,7 @@ interface(`kernel_dontaudit_udp_recvfrom
> >  		type unlabeled_t;
> >  	')
> >
> > +	dontaudit $1 unlabeled_t:peer recv;
> >  	dontaudit $1 unlabeled_t:udp_socket recvfrom;
> >  ')
> >
> > @@ -2426,6 +2430,7 @@ interface(`kernel_raw_recvfrom_unlabeled
> >  		type unlabeled_t;
> >  	')
> >
> > +	allow $1 unlabeled_t:peer recv;
> >  	allow $1 unlabeled_t:rawip_socket recvfrom;
> >  ')
> >
> > @@ -2455,6 +2460,7 @@ interface(`kernel_dontaudit_raw_recvfrom
> >  		type unlabeled_t;
> >  	')
> >
> > +	dontaudit $1 unlabeled_t:peer recv;
> >  	dontaudit $1 unlabeled_t:rawip_socket recvfrom;
> >  ')
> >
> > Index: refpolicy_svn_repo/policy/modules/kernel/kernel.te
> > ===================================================================
> > --- refpolicy_svn_repo.orig/policy/modules/kernel/kernel.te
> > +++ refpolicy_svn_repo/policy/modules/kernel/kernel.te
> > @@ -212,6 +212,9 @@ allow kernel_t unlabeled_t:dir mounton;
> >  # connections with invalidated labels:
> >  allow kernel_t unlabeled_t:packet send;
> >
> > +# Forwarded traffic
> > +allow unlabeled_t unlabeled_t:packet { forward_in forward_out };
> > +
> >  corenet_all_recvfrom_unlabeled(kernel_t)
> >  corenet_all_recvfrom_netlabel(kernel_t)
> >  # Kernel-generated traffic e.g., ICMP replies:



-- 
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: [PATCH 4/4] REFPOL: Add new labeled networking permissions

[Christopher J. PeBenito]

On Wed, 2008-02-13 at 22:54 -0500, Paul Moore wrote:
> On Tuesday 12 February 2008 9:39:59 am Christopher J. PeBenito wrote:
> > On Fri, 2008-02-08 at 16:25 -0500, paul.moore@hp.com wrote:
> > > plain text document attachment (refpol-peer_perms)
> > > The 2.6.25 kernel will introduce a new set of labeled networking controls
> > > to SELinux and this patch makes the necessary changes to the Reference
> > > Policy to support unlabeled network traffic with the new controls.
> >
> > The corenetwork part is missing changes in the cornetwork.if.m4 file.
> > Thats where the interfaces generated by a network_(node|interface)() are
> > generated.
> 
> Okay, I'll look into fixing that part up.
> 
> > I'm not so sure about the kernel interface changes.  The docs probably
> > should be revised, its more about using sockets whose types have been
> > invalidated.  It doesn't have anything to do with unlabeled networking.
> 
> Hmmm, okay.  Do you have a suggestion for how to add these new allow rules?  A 
> new interface?  I would need to go check again, but these seemed to be the 
> most logical of the existing interfaces when I made the change (and I suspect 
> not much has changed in this area).

I'm thinking along the lines of new interfaces like
kernel_recvfrom_unlabeled_peer().

-- 
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: [PATCH 4/4] REFPOL: Add new labeled networking permissions

[Paul Moore]

On Thursday 14 February 2008 9:36:59 am Christopher J. PeBenito wrote:
> On Wed, 2008-02-13 at 22:54 -0500, Paul Moore wrote:
> > On Tuesday 12 February 2008 9:39:59 am Christopher J. PeBenito 
wrote:
> > > On Fri, 2008-02-08 at 16:25 -0500, paul.moore@hp.com wrote:
> > > > plain text document attachment (refpol-peer_perms)
> > > > The 2.6.25 kernel will introduce a new set of labeled
> > > > networking controls to SELinux and this patch makes the
> > > > necessary changes to the Reference Policy to support unlabeled
> > > > network traffic with the new controls.
> > >
> > > The corenetwork part is missing changes in the cornetwork.if.m4
> > > file. Thats where the interfaces generated by a
> > > network_(node|interface)() are generated.
> >
> > Okay, I'll look into fixing that part up.
> >
> > > I'm not so sure about the kernel interface changes.  The docs
> > > probably should be revised, its more about using sockets whose
> > > types have been invalidated.  It doesn't have anything to do with
> > > unlabeled networking.
> >
> > Hmmm, okay.  Do you have a suggestion for how to add these new
> > allow rules?  A new interface?  I would need to go check again, but
> > these seemed to be the most logical of the existing interfaces when
> > I made the change (and I suspect not much has changed in this
> > area).
>
> I'm thinking along the lines of new interfaces like
> kernel_recvfrom_unlabeled_peer().

Okay, I'll see what I can 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: [PATCH 4/4] REFPOL: Add new labeled networking permissions

[Paul Moore]

On Thursday 14 February 2008 9:36:59 am Christopher J. PeBenito wrote:
> On Wed, 2008-02-13 at 22:54 -0500, Paul Moore wrote:
> > On Tuesday 12 February 2008 9:39:59 am Christopher J. PeBenito 
wrote:
> > > On Fri, 2008-02-08 at 16:25 -0500, paul.moore@hp.com wrote:
> > > > plain text document attachment (refpol-peer_perms)
> > > > The 2.6.25 kernel will introduce a new set of labeled
> > > > networking controls to SELinux and this patch makes the
> > > > necessary changes to the Reference Policy to support unlabeled
> > > > network traffic with the new controls.
> > >
> > > The corenetwork part is missing changes in the cornetwork.if.m4
> > > file. Thats where the interfaces generated by a
> > > network_(node|interface)() are generated.
> >
> > Okay, I'll look into fixing that part up.
> >
> > > I'm not so sure about the kernel interface changes.  The docs
> > > probably should be revised, its more about using sockets whose
> > > types have been invalidated.  It doesn't have anything to do with
> > > unlabeled networking.
> >
> > Hmmm, okay.  Do you have a suggestion for how to add these new
> > allow rules?  A new interface?  I would need to go check again, but
> > these seemed to be the most logical of the existing interfaces when
> > I made the change (and I suspect not much has changed in this
> > area).
>
> I'm thinking along the lines of new interfaces like
> kernel_recvfrom_unlabeled_peer().

Before I go ahead an make all of the changes to the other modules, are 
the two interfaces below what you had in mind?

**** from kernel.if
########################################
## <summary>
##	Receive packets from an unlabeled peer.
## </summary>
## <desc>
##	<p>
##	Receive packets from an unlabeled peer,
##      these packets do not have any peer labeling
##      information present.
##	</p>
##	<p>
##	The corenetwork interface
##	corenet_recvfrom_unlabeled_peer() should
##	be used instead of this one.
##	</p>
## </desc>
## <param name="domain">
##	<summary>
##	Domain allowed access.
##	</summary>
## </param>
#
interface(`kernel_recvfrom_unlabeled_peer',`
	gen_require(`
		type unlabeled_t;
	')

	allow $1 unlabeled_t:peer recv;
')

**** from corenetwork.if.in
########################################
## <summary>
##	Receive packets from an unlabeled peer.
## </summary>
## <desc>
##	<p>
##	Receive packets from an unlabeled peer,
##      these packets do not have any peer labeling
##      information present.
##	</p>
## </desc>
## <param name="domain">
##	<summary>
##	Domain allowed access.
##	</summary>
## </param>
#
interface(`corenet_recvfrom_unlabeled_peer',`
	kernel_recvfrom_unlabeled_peer($1)
')

-- 
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: [PATCH 4/4] REFPOL: Add new labeled networking permissions

[Christopher J. PeBenito]

On Tue, 2008-02-19 at 12:12 -0500, Paul Moore wrote:
> On Thursday 14 February 2008 9:36:59 am Christopher J. PeBenito wrote:
> > On Wed, 2008-02-13 at 22:54 -0500, Paul Moore wrote:
> > > On Tuesday 12 February 2008 9:39:59 am Christopher J. PeBenito 
> wrote:
> > > > On Fri, 2008-02-08 at 16:25 -0500, paul.moore@hp.com wrote:
> > > > > plain text document attachment (refpol-peer_perms)
> > > > > The 2.6.25 kernel will introduce a new set of labeled
> > > > > networking controls to SELinux and this patch makes the
> > > > > necessary changes to the Reference Policy to support unlabeled
> > > > > network traffic with the new controls.
[...]
> > > > I'm not so sure about the kernel interface changes.  The docs
> > > > probably should be revised, its more about using sockets whose
> > > > types have been invalidated.  It doesn't have anything to do with
> > > > unlabeled networking.
> > >
> > > Hmmm, okay.  Do you have a suggestion for how to add these new
> > > allow rules?  A new interface?  I would need to go check again, but
> > > these seemed to be the most logical of the existing interfaces when
> > > I made the change (and I suspect not much has changed in this
> > > area).
> >
> > I'm thinking along the lines of new interfaces like
> > kernel_recvfrom_unlabeled_peer().
> 
> Before I go ahead an make all of the changes to the other modules, are 
> the two interfaces below what you had in mind?

Yes.

> **** from kernel.if
> ########################################
> ## <summary>
> ##	Receive packets from an unlabeled peer.
> ## </summary>
> ## <desc>
> ##	<p>
> ##	Receive packets from an unlabeled peer,
> ##      these packets do not have any peer labeling
> ##      information present.
> ##	</p>
> ##	<p>
> ##	The corenetwork interface
> ##	corenet_recvfrom_unlabeled_peer() should
> ##	be used instead of this one.
> ##	</p>
> ## </desc>
> ## <param name="domain">
> ##	<summary>
> ##	Domain allowed access.
> ##	</summary>
> ## </param>
> #
> interface(`kernel_recvfrom_unlabeled_peer',`
> 	gen_require(`
> 		type unlabeled_t;
> 	')
> 
> 	allow $1 unlabeled_t:peer recv;
> ')
> 
> **** from corenetwork.if.in
> ########################################
> ## <summary>
> ##	Receive packets from an unlabeled peer.
> ## </summary>
> ## <desc>
> ##	<p>
> ##	Receive packets from an unlabeled peer,
> ##      these packets do not have any peer labeling
> ##      information present.
> ##	</p>
> ## </desc>
> ## <param name="domain">
> ##	<summary>
> ##	Domain allowed access.
> ##	</summary>
> ## </param>
> #
> interface(`corenet_recvfrom_unlabeled_peer',`
> 	kernel_recvfrom_unlabeled_peer($1)
> ')
> 
-- 
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.