Bug 746651 - Add egress rules to selinux-policy
Summary: Add egress rules to selinux-policy
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: selinux-policy
Version: 6.2
Hardware: All
OS: Linux
Target Milestone: rc
: 6.2
Assignee: Miroslav Grepl
QA Contact: BaseOS QE Security Team
Depends On:
Blocks: RHEL62CCC 846801 846802
TreeView+ depends on / blocked
Reported: 2011-10-17 11:57 UTC by Miroslav Vadkerti
Modified: 2012-08-08 18:29 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2011-10-18 18:44:44 UTC

Attachments (Terms of Use)

Description Miroslav Vadkerti 2011-10-17 11:57:39 UTC
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):

How reproducible:

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 13:50:44 UTC
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 16:09:45 UTC
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 16:24:07 UTC

Comment 4 Paul Moore 2011-10-17 21:08:00 UTC
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 21:15:22 UTC
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 21:26:15 UTC
(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 21:33:40 UTC
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 21:41:22 UTC
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 12:19:57 UTC
(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 

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 18:40:05 UTC
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 18:44:44 UTC
Thank you Linda for your explanation.

Note You need to log in before you can comment on or make changes to this bug.