From: cpebenito@tresys.com (Christopher J. PeBenito)
Date: Tue, 30 Nov 2010 10:34:10 -0500
Subject: [refpolicy] Turning off unlabeled_t:packet { send recv }
In-Reply-To: <4CED135C.4040304@redhat.com>
References: <4CED135C.4040304@redhat.com>
Message-ID: <4CF51972.9080809@tresys.com>
To: refpolicy@oss.tresys.com
List-Id: refpolicy.oss.tresys.com

On 11/24/10 08:30, Daniel J Walsh wrote:
> I have been fooling around with SECMARK labeling.  And one problem that
> I have found is that we don't have a way to turn off the use of the
> unlabeled_t packets.  Every domain is allowed to send and recv
> unlabeled_t packets.
> 
> The way you label a packet is by setting up iptables rules, if iptables
> is shut down, we do not want SELinux to break the system by default.
> 
> But, in some cases where you want to set up security based on labeled
> packets, you do want the packets to be blocked if the firewall goes down.
> 
> I was trying to setup an environment where you could label two types of
> data intranet, internet.  Then I could assign which domains could talk
> to the intranet an which domains can talk to the internet.  If the
> iptables rules are removed, I do not want packets to flow to either side.
> 
> The mechanism I came up with to do this was to have a module
> unlablednet.pp, that you can disable, in order to stop unlabeled_t
> packets from being used from confined domains.
> 
> Here is the patch I used to make this work.
> 
> What do you think of the idea?

My knee-jerk reaction was to use conditionals instead, but some network
access is already conditional, so that would break w/o nested
conditionals support.  I think this is an ugly solution; however, it may
be the only way to do it within the constraints of the current
toolchain.  I do want to have a way to eliminate the unlabeled packet
access, so I'll think about this for a while.

-- 
Chris PeBenito
Tresys Technology, LLC
www.tresys.com | oss.tresys.com