Skip to contentSkip to conversation

network: Enable "network_peer_controls" and fix some remaining issues

RFC PATCH New paul.moore at hp.com 1 participant 3 messages Dec 8, 2008

lore
Share & tools
lore
author
#1 lore raw

RFC PATCH 1/1 network: Enable "network_peer_controls" and fix some remaining issues

Quoted 11 lines · paul.moore at hp.com

From pmoore at flek.lan Mon Dec 8 14:54:09 2008
Message-Id: <[email protected]>
References: <[email protected]>
User-Agent: quilt/0.46-1
Date: Mon, 08 Dec 2008 14:54:00 -0500
From: paul.moore at hp.com
To: refpolicy at oss.tresys.com
Bcc: paul.moore at hp.com
Subject: [patch 2/2] btrfs enablement
Content-Disposition: inline; filename=btrfs-enable

Quoted 2 lines

Jim Owens discovered that we don't currently make use of the xattr support in btrfs; the following patch fixes that.

Ahhh! I've gotten used to stgit's behavior of not mailing patches that aren't applied (the -a option) where it looks like quilt sends all the patches by default. You can ignore this btrfs change as previously discussed. If you need me to resend a corrected patch please let me know.

Sorry about that.

Signature · 2 lines
paul moore
linux @ hp
author
#2 lore raw

RFC PATCH 1/1 network: Enable "network_peer_controls" and fix some remaining issues

In reply to paul.moore at hp.com
Quoted 34 lines · paul.moore at hp.com

We added the network_peer_controls capability back in Linux Kernel 2.6.25 but didn't activate the capabilitiy because more work needed to be done to ensure a smooth transition to the new controls. This patch enables the network_peer_controls capability and fixes a few remaining issues. With this patch applied to the current Fedora Rawhide SELinux policy
(selinux-policy-3.6.1-4.fc11) I am able to interact with the machine over the network without any new AVC denials.

Signed-off-by Paul Moore <[email protected]>
---
 policy/modules/kernel/corenetwork.if.in |  120
++++++++++++++++++++++++++++++++ policy/modules/kernel/kernel.te     
   |    4 -
 policy/policy_capabilities              |    2
 3 files changed, 124 insertions(+), 2 deletions(-)

Index: refpolicy_svn_repo/policy/modules/kernel/corenetwork.if.in
===================================================================

policy/modules/kernel/corenetwork.if.in +9 -0
@@ -140,6 +140,66 @@ interface(`corenet_server_packet',`
 
 ########################################
 ## <summary>
+##	Allow outgoing network traffic on the generic interfaces.
+## </summary>
+## <param name="domain">
+##	<summary>
+##	The peer label of the outgoing network traffic.
+##	</summary>
+## </param>
+## <infoflow type="both" weight="10"/>
+#

policy/modules/kernel/corenetwork.if.in interface(`corenet_server_packet',` · line 161

Quoted 10 lines
policy/modules/kernel/corenetwork.if.in +10 -0
+interface(`corenet_out_generic_if',`
+	gen_require(`
+		type netif_t;
+	')
+
+	allow $1 netif_t:netif { egress };
+
+	# XXX - legacy support
+	allow $1 netif_t:netif { tcp_send udp_send rawip_send };
+')

I wanted to ask everyone's opinion on replacing the protocol specific corenet_*_if() macros with the more generic versions in this patch. I'm not convinced that distinguishing between protocols, i.e. UDP vs TCP, is all that useful in a general sense and only adds complexity to the policy. If people really wanted separation between protocols they could always accomplish that with Secmark ... Thoughts?

Signature · 2 lines
paul moore
linux @ hp