[refpolicy] [RFC PATCH v1] network: Enable "network_peer_controls" and fix some remaining issues

[refpolicy] [RFC PATCH v1] network: Enable "network_peer_controls" and fix some remaining issues

[paul.moore at hp.com]

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 

[refpolicy] [RFC PATCH v1] network: Enable "network_peer_controls" and fix some remaining issues

[Paul Moore]

On Monday 08 December 2008 2:53:59 pm paul.moore at hp.com wrote:
> From pmoore at flek.lan Mon Dec  8 14:54:09 2008
> Message-Id: <20081208195409.166769977@flek.lan>
> References: <20081208195358.743995840@flek.lan>
> 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
>
> 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.

-- 
paul moore
linux @ hp

[refpolicy] [RFC PATCH v1] network: Enable "network_peer_controls" and fix some remaining issues

[Paul Moore]

On Monday 08 December 2008 2:53:59 pm paul.moore at hp.com wrote:
> 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 <paul.moore@hp.com>
> ---
>  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
> ===================================================================
> --- refpolicy_svn_repo.orig/policy/modules/kernel/corenetwork.if.in
> +++ refpolicy_svn_repo/policy/modules/kernel/corenetwork.if.in
> @@ -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"/>
> +#
> +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?

-- 
paul moore
linux @ hp