network: Enable "network_peer_controls" and fix some remaining issues
RFC PATCH 1/1 network: Enable "network_peer_controls" and fix some remaining issues
An embedded and charset-unspecified text was scrubbed...
Name: network-in_out_basic
Url: http://oss.tresys.com/pipermail/refpolicy/attachments/20081208/862b53b7/attachment.pl
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
RFC PATCH 1/1 network: Enable "network_peer_controls" and fix some remaining issues
In reply to paul.moore at hp.comQuoted 34 lines · paul.moore at hp.com
We added the
network_peer_controlscapability 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 thenetwork_peer_controlscapability 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