Actually I meant we have these rules in Fedora except unlabeled_t.

Are these rules really needed? Looks like a bug in tests.

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?

Paul?

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.

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.

(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.

I see in the original report

allow unlabeled_t sshd_t:netif egress;
allow unlabeled_t ping_t:netif egress;

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.

(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?

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

Thank you Linda for your explanation.