Bug 746651

Summary: Add egress rules to selinux-policy
Product: Red Hat Enterprise Linux 6 Reporter: Miroslav Vadkerti <mvadkert>
Component: selinux-policyAssignee: Miroslav Grepl <mgrepl>
Status: CLOSED NOTABUG QA Contact: BaseOS QE Security Team <qe-baseos-security>
Severity: urgent Docs Contact:
Priority: urgent    
Version: 6.2CC: dwalsh, eparis, linda.knippers, mmalik, pmoore
Target Milestone: rcKeywords: TestBlocker
Target Release: 6.2   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2011-10-18 14:44:44 EDT Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
Bug Depends On:    
Bug Blocks: 584498, 846801, 846802    

Description Miroslav Vadkerti 2011-10-17 07:57:39 EDT
Description of problem:
In CCC tests we use netlabel. We need these rules to be added to the MLS selinux policy for the tests to work. Some of the are already enabled in the lspp policy, though mgrepl suggested they should be in the default policy:

allow kernel_t unlabeled_t:netif egress;
allow inetd_t lo_netif_t:netif egress;
allow inetd_t unlabeled_t:netif egress;
allow sshd_t unlabeled_t:netif egress;
allow unlabeled_t sshd_t:netif egress;
allow sshd_t lo_netif_t:netif egress;
allow ping_t unlabeled_t:netif egress;
allow unlabeled_t ping_t:netif egress;
allow cupsd_t lo_netif_t:netif egress;
allow ssh_t lo_netif_t:netif egress;

Version-Release number of selected component (if applicable):
selinux-policy-3.7.19-117.el6.noarch

How reproducible:
100%

Steps to Reproduce:
1. Run CCC tests

Actual results:
Tests fail

Expected results:
Tests should PASS

Additional info:
Comment 1 Miroslav Grepl 2011-10-17 09:50:44 EDT
Actually I meant we have these rules in Fedora except unlabeled_t.

Are these rules really needed? Looks like a bug in tests.
Comment 2 Miroslav Vadkerti 2011-10-17 12:09:45 EDT
Well they are needed because we have network labeling via netlabel set on the machines. This breaks some tests if the rules are not present. So is the correct place for these rules in our custom policy?
Comment 3 Daniel Walsh 2011-10-17 12:24:07 EDT
Paul?
Comment 4 Paul Moore 2011-10-17 17:08:00 EDT
I think blindly adding any rules like the following to the base policy is a mistake:

  allow <domain> unlabeled_t:netif { ingress egress };

The rule above essentially lets any unlabeled traffic into the system; probably what you want in a general purpose MCS system but almost certainly not what you want on a system with labeled networking configured (the first sentence in the problem report indicates that this is the case).

If you are going to configure labeled networking on a system, you almost certainly want to make sure all of your network interfaces and network traffic on the system is labeled.  For incoming traffic you label it either through a labeling protocol for multi-label networks or through a static/fallback label for single label networks.  For outgoing traffic you want to make sure that the outbound network interface's label matches the network's label range; it is this last part which appears to be causing you problems.

If you really need to add the unlabeled_t rule to base policy, please surround it with a boolean so users who deploy MLS systems in a well defined environment can disable it.
Comment 5 Miroslav Grepl 2011-10-17 17:15:22 EDT
Then I believe the unlabeled_t policy should be added by CCC tests and should not be added to the policy by default.

But I am still interested in rules like

allow unlabeled_t sshd_t:netif egress;

This still looks like a CCC test issue for me.
Comment 6 Paul Moore 2011-10-17 17:26:15 EDT
(In reply to comment #5)
> Then I believe the unlabeled_t policy should be added by CCC tests and should
> not be added to the policy by default.

I think the right course of action is for the Common Criteria tests to configure labeled networking properly and not halfway as they appear to be doing now.

> But I am still interested in rules like
> 
> allow unlabeled_t sshd_t:netif egress;
> 
> This still looks like a CCC test issue for me.

I think you have that backwards, do you mean the following?

  allow sshd_t unlabeled_t:netif egress;

Assuming that is what you meant, this is an example of the outgoing network interface not being labeled correctly.  Label all the interfaces correctly and this goes away.
Comment 7 Miroslav Grepl 2011-10-17 17:33:40 EDT
I see in the original report

allow unlabeled_t sshd_t:netif egress;
allow unlabeled_t ping_t:netif egress;
Comment 8 Paul Moore 2011-10-17 17:41:22 EDT
You're right, I'm sorry.  Miroslav V. can you confirm that those allow rules are correct and actually needed?  If they are indeed needed, something very odd is going on.
Comment 9 Miroslav Grepl 2011-10-18 08:19:57 EDT
(In reply to comment #1)
> Actually I meant we have these rules in Fedora except unlabeled_t.
> 
Well, this is valid for targeted policy because of 


build_option(`enable_mls',`
network_interface(lo, lo, s0 - mls_systemhigh)
',`
typealias netif_t alias { lo_netif_t netif_lo_t };
')

The question is how we should handle it. Should we just provide an interface?
Comment 11 Linda Knippers 2011-10-18 14:40:05 EDT
As a reminder to Paul and for everyone else's information, the purpose of the 
lspp_test policy is to provide enough overrides so that the test harness can 
do all the appropriate test setup and so that the testers can interact with
the test systems from their workstations, all without invalidating what we're 
trying to test.

Where we're trying to test labeled networking, we're using explicit labeling and the unlabeled allow rules do not apply.  I believe we have the ssh_t one so that 
tester can ssh in/out of the system.  I believe we have the ping one because we
have an selinux boolean test that happens to use ping.  Since its testing the
effect of the boolean and not labeled networking, the labeled networking
rules are not a factor.  I added those allow rules when we first enabled
the labeled networking tests with RHE6 and its possible that due to the
netlabel rules we added that they're not actually needed anymore but I think 
they do no harm.

We have all sorts of policy in the lspp_test policy that is only suitable 
for our test setup (a super privileged role, MLS overrides on various
harness-related types) so I wouldn't put any of it in the standard policy
without a really good reason.  It is also not part of the configuration
that a customer would install if they care about labeled networking or
MLS in general.

-- ljk
Comment 12 Miroslav Grepl 2011-10-18 14:44:44 EDT
Thank you Linda for your explanation.