2008-12-08 19:53:59

by Paul Moore

[permalink] [raw]
Subject: [refpolicy] [RFC PATCH v1] 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


2008-12-08 20:37:40

by Paul Moore

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

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: <[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
>
> 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

2008-12-08 20:41:08

by Paul Moore

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

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 <[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
> ===================================================================
> --- 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