Bug 695799 - regression in labeled networking
regression in labeled networking
Status: CLOSED NOTABUG
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: selinux-policy (Show other bugs)
6.1
All Linux
urgent Severity high
: rc
: ---
Assigned To: Miroslav Grepl
BaseOS QE Security Team
: Reopened, SELinux
Depends On:
Blocks: RHEL62CCC 846801 846802
  Show dependency treegraph
 
Reported: 2011-04-12 13:55 EDT by Linda Knippers
Modified: 2013-09-04 09:55 EDT (History)
12 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2011-05-10 10:25:39 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
AVCs from RHEL6 (5.80 KB, text/plain)
2011-04-12 13:55 EDT, Linda Knippers
no flags Details

  None (edit)
Description Linda Knippers 2011-04-12 13:55:04 EDT
Created attachment 491534 [details]
AVCs from RHEL6

Description of problem:
Due to some changes in the upstream labeled networking support, RHEL6.1 with the MLS policy is more restrictive than RHEL5 with the MLS policy and may even be more restrictive than the current Fedora.  This behavior change may surprise customers.

Version-Release number of selected component (if applicable):


How reproducible:
Very.

Steps to Reproduce:
1.  Configure a system with the MLS policy and netlabel
2.  Enable cipso

On RHEL6.1:

# netlabelctl cipsov4 add pass doi:6000 tags:1
<traffic is blocked - avc's generated>
# setenforce 0
<traffic resumes>
# netlabelctl cipsov4 add pass doi:6000 tags:1
# setenforce 1
<traffic still flows>

On RHEL5, the traffic continues to flow when the same commands are executed.
The difference seems to be that enabling labeled networking with RHEL6 
causes all the TE checks to be activated, rather than just the MLS checks.
While RHEL5 there was a boolean to allow unlabeled packets, which
was on by default.
  
Actual results:

Traffic for which there is no SELinux TE policy is blocked.

Expected results:
Traffic should flow unless it violates a CIPSO rule.

Additional info:

AVCs are attached.  According to Dan these accesses are allowed in F15.
Comment 3 Daniel Walsh 2011-04-13 11:28:11 EDT
Miroslav add 

	kernel_recvfrom_unlabeled_peer($1)
 to corenet_tcp_recvfrom_unlabeled

Probably should just back port corenetwork.if.in.
Comment 5 Miroslav Grepl 2011-04-18 04:00:59 EDT
(In reply to comment #3)
> Miroslav add 
> 
>  kernel_recvfrom_unlabeled_peer($1)
>  to corenet_tcp_recvfrom_unlabeled
> 
> Probably should just back port corenetwork.if.in.

Actually we have this in policy.

But the problem is

#============= sshd_t ==============
#!!!! This avc is a constraint violation.  You will need to add an attribute to either the source or target type to make it work.
#Contraint rule: 
allow sshd_t unlabeled_t:peer recv;
Comment 6 Daniel Walsh 2011-04-18 12:07:27 EDT
Paul what do you think the correct thing to do is here?
Comment 7 Daniel Walsh 2011-04-18 12:08:36 EDT
Do use this do we need to have sshd launched by xinetd at the proper level?
Comment 8 Stephen Smalley 2011-04-18 12:29:49 EDT
sshd_t needs the mlsnetreadtoclr or mlsnetread type attribute (mls_socket_read_to_clearance or mls_socket_read_all_levels interfaces) in order to accept connections from any level.  This would make sshd part of the TCB.

Or you could run sshd at the peer level via the modified xinetd as Dan said - I think that was done for RHEL5.  But not sure if the xinetd patches carried forward.
Comment 9 Linda Knippers 2011-04-18 12:46:49 EDT
The RHEL5 and RHEL6 evaluated configurations set up sshd to be launched by xinetd at the right level, although I haven't actually tested it for RHEL6.
Comment 10 Paul Moore 2011-04-18 12:47:24 EDT
Just a reminder, in RHEL6 unlabeled_t really means unlabeled (netlabel_peer_t is used for NetLabel/CIPSO packets) whereas in RHEL5 unlabeled_t could mean both an unlabeled packet as well as a NetLabel/CIPSO labeled packet.  So, in the examples given above, the unlabeled_t packet is unlabeled_t:SystemHigh which is likely why the MLS constraint is causing AVC denials.

As for how to fix it?  Well, truly unlabeled data has always been unlabeled_t:SystemHigh so that isn't new and I would expect similar solutions to work in RHEL6, although some of these solutions may have been dropped between RHEL5 and RHEL6 due to the dynamic network access controls.  As Stephen points out, if you want to avoid the MLS constraint you will need to assign one of the MLS attributes but for evaluation reasons you may want to use this sparingly.  I would suggest talking to the evaluator to discuss your options but it seems like a per-domain boolean to assign the MLS overrides might be a good option.
Comment 11 Linda Knippers 2011-04-18 12:57:17 EDT
I think we want the MLS constraint to be enforced as it was in RHEL5.  I think we want to be able to enforce the Netlabel/CIPSO labeling without the TE labeling, which I believe is how it was for RHEL5.
Comment 12 Stephen Smalley 2011-04-18 13:17:12 EDT
Possibly I don't understand, but the denial appears to be a MLS denial due to sshd receiving a unlabeled packet.  It doesn't have anything to do with TE per se, although you can use TE to "fix" it by giving sshd_t the attributes it needs to override the MLS constraint.
Comment 13 Linda Knippers 2011-04-18 13:36:23 EDT
Its quite possible I misunderstood my conversation with Paul regarding the cause of the behavior difference but I am quite sure that there is a behavior difference as I described in the original problem statement.
Comment 14 Daniel Walsh 2011-04-18 15:21:28 EDT
There is no Type Enforcement denial here.  The denial is a domain sshd_t running as s0-s15:c0.c1023 is trying to read a package running at s15:c0.c1023.  If you had kill sshd and run it out of xinetd like we did in RHEL5, it should be executed out of xinetd at

s15:c0.c1023 and able to read the packet.
Comment 16 Daniel Walsh 2011-04-18 15:22:02 EDT
I believe this is not abug.
Comment 17 Linda Knippers 2011-04-18 15:29:28 EDT
There is a difference in behavior between RHEL5 and RHEL6.  My systems are configured the same wrt sshd and xinetd but the behavior is different.  Maybe the bug is somewhere else but there's a bug somewhere.
Comment 18 Linda Knippers 2011-04-18 15:31:14 EDT
Maybe it would be good if someone else tries this.  Its actually very easy to reproduce.  Install the RHEL6 evaluated config and and follow the steps in the original problem statement.
Comment 19 Daniel Walsh 2011-04-18 15:39:27 EDT
If xinetd is launching sshd as s0-s15:c0.c1023 on a connection from a network labeled s15:c0.c1023 then that would be an xinetd regression.
Comment 20 Linda Knippers 2011-04-18 15:44:34 EDT
Updated summary to take policy out of the line.  Can we reopen the bug now?
Comment 21 Stephen Smalley 2011-04-18 15:46:44 EDT
Based on the AVC, we have a denial on an unlabeled packet, i.e. the packet had
no CIPSO label at all.  So the question is:  Did you expect the packet to have
a CIPSO label or not?  If the former, then we have a bug in or misconfiguration
of NetLabel on the sending side.  If the latter, then what behavior do you
expect for unlabeled packets?  xinetd, even with the labeled networking
patches, wouldn't have launched sshd in a particular level/range unless it
could get the peer label, and there was no peer label available here.
Comment 22 Linda Knippers 2011-04-18 19:40:24 EDT
My sshd/xinetd configuration is the same on my RHEL5 and RHEL6 systems.  I don't know if the RHEL5 boolean for allowing unlabeled packets is a factor here.  I tried turning it off on my RHEL5 system and it didn't seem to make a difference.

At this point my RHEL6 system is a couple of snapshots old so I'm going to reinstall and re-test.
Comment 23 Vojtech Vitek 2011-04-19 09:41:02 EDT
Linda, could you please paste versions of xinetd packages installed on both RHEL-5 and RHEL-6 when the issue occurred?

$ rpmquery xinetd

I would also appreciate re-testing the issue after the upgrade, as you mentioned above.
Comment 26 Steve Grubb 2011-04-19 10:15:04 EDT
Looking at xinetd in RHEL6, there was a change in names of an additional patch being applied. RHEL5 is xinetd-2.3.14-contextmerge.patch and RHEL 6 is xinetd-2.3.14-contextconf.patch. Diff'ing the patches shows they are almost identical. There is some whitespace differences and that's all. Aside from that, the labeled networking code appears about the same. Xinetd is depending on libselinux for certain functionality, like getpeercon and setexeccon. It essentially gets the context and applies it and does nothing else.
Comment 28 Vojtech Vitek 2011-04-19 10:33:52 EDT
Exactly as Steve said.

It's not clear where to find any bug until we know exact versions of xinetd
packages used by customer. The sources are identical in terms of labeled
networking (when release-synced - there are same patches).

Last changes of labeled networking were in xinetd-2:2.3.14-10.el5 and
xinetd-2:2.3.14-9.el6 packages: Fix getpeercon() for LABELED networking MLS environments.
Comment 30 Daniel Walsh 2011-04-19 10:38:28 EDT
I am not sure if this is a selinux-policy or a xinetd, bug waiting for more confirmation from Linda.
Comment 31 Stephen Smalley 2011-04-19 10:44:55 EDT
I'm unclear as to whether xinetd is even relevant to this bug.
The AVC denials are for sshd and dnsmasq and are on unlabeled packets; thus,
xinetd labeled networking support is irrelevant AFAICS.
The correct question is do you expect these packets to be labeled, and if so,
why are they not labeled (e.g. NetLabel bug or misconfiguration)?
In the steps to reproduce, you defined a NetLabel DOI, but you didn't add any
domain mappings AFAICS, so there wouldn't yet be any labeled traffic.

The reason you encounter the denials after defining the DOI is that peer
permission check is only performed if someone configures labeled networking; that was a compatibility compromise to avoid breaking existing systems when the new network permission checks were introduced. 
So before defining the DOI, you need to configure handling of unlabeled packets
and/or allow receipt of unlabeled packets if that is what you want.
Comment 32 Steve Grubb 2011-04-19 10:55:03 EDT
One additional troubleshooting note...if you go into /etc/sysconfig/xinetd and add -d to the daemon flags,this will put xinetd in debug mode. It will send more info to LOG_DEBUG syslog facility. What I am curious about is the line saying:

"current security exec context now"  If this line does not appear, there should
be something in syslog saying "Changing process context failed for ...". 

So, if the unlabeled packet does not map to a context, I suspect we get the
changing failed message. That should be in syslog or xinetd's logs without
adding the debug, so maybe you might want to look for that first.
Comment 34 Linda Knippers 2011-04-19 16:41:59 EDT
In reply to comment 23:

RHEL5.6:       xinetd-2.3.14-10.el5
RHEL6.1 snap3: xinetd-2.3.14-31.el6.x86_64
Comment 35 Linda Knippers 2011-04-19 16:44:41 EDT
(In reply to comment #31)
> I'm unclear as to whether xinetd is even relevant to this bug.
> The AVC denials are for sshd and dnsmasq and are on unlabeled packets; thus,
> xinetd labeled networking support is irrelevant AFAICS.
> The correct question is do you expect these packets to be labeled, and if so,
> why are they not labeled (e.g. NetLabel bug or misconfiguration)?
> In the steps to reproduce, you defined a NetLabel DOI, but you didn't add any
> domain mappings AFAICS, so there wouldn't yet be any labeled traffic.
> 
> The reason you encounter the denials after defining the DOI is that peer
> permission check is only performed if someone configures labeled networking;
> that was a compatibility compromise to avoid breaking existing systems when the
> new network permission checks were introduced. 
> So before defining the DOI, you need to configure handling of unlabeled packets
> and/or allow receipt of unlabeled packets if that is what you want.

I agree with Stephen.  I don't think this problem is related to running multiple levels of sshd from xinetd because the behavior difference I see is when using sshd on the default port.  With RHEL5, unlabeled packets go through and on RHEL6, they don't.  On RHEL6, my existing network connections stop as soon as I run my first netlabelctl command, but on RHEL5, the connections continue to work.  
Maybe its a netlabel bug.  When I first talked to Paul about this the theory was that it was the type enforcement but the AVCs suggest otherwise.
Comment 36 Linda Knippers 2011-04-19 16:47:54 EDT
(In reply to comment #32)
> One additional troubleshooting note...if you go into /etc/sysconfig/xinetd and
> add -d to the daemon flags,this will put xinetd in debug mode. It will send
> more info to LOG_DEBUG syslog facility. What I am curious about is the line
> saying:
> 
> "current security exec context now"  If this line does not appear, there should
> be something in syslog saying "Changing process context failed for ...". 
> 
> So, if the unlabeled packet does not map to a context, I suspect we get the
> changing failed message. That should be in syslog or xinetd's logs without
> adding the debug, so maybe you might want to look for that first.

This is interesting.  I tried this on RHEL6 and when I tried to ssh in at the alternate port used for mls, it failed.

11/4/19@15:37:56: DEBUG: 2402 {cnf_start_services} Started service: ssh-mls
11/4/19@15:37:56: DEBUG: 2402 {cnf_start_services} pfds_last = 1, services_started = 1
11/4/19@15:37:56: NOTICE: 2402 {main} xinetd Version 2.3.14 started with libwrap loadavg labeled-networking options compiled in.
11/4/19@15:37:56: NOTICE: 2402 {main} Started working: 1 available service
11/4/19@15:37:56: DEBUG: 2402 {main_loop} active_services = 1
11/4/19@15:39:01: DEBUG: 2402 {main_loop} select returned 1
11/4/19@15:39:01: DEBUG: 2402 {server_start} Starting service ssh-mls
11/4/19@15:39:01: DEBUG: 2402 {main_loop} active_services = 1
11/4/19@15:39:01: DEBUG: 2471 {exec_server} duping 7
11/4/19@15:39:01: ERROR: 2471 {exec_server} Changing process context failed for ssh-mls
11/4/19@15:39:01: DEBUG: 2402 {main_loop} active_services = 1
11/4/19@15:39:01: DEBUG: 2402 {main_loop} select returned 1
11/4/19@15:39:01: DEBUG: 2402 {check_pipe} Got signal 17 (Child exited)
11/4/19@15:39:01: DEBUG: 2402 {child_exit} waitpid returned = 2471
11/4/19@15:39:01: DEBUG: 2402 {server_end} ssh-mls server 2471 exited
11/4/19@15:39:01: INFO: 2402 {conn_free} freeing connection
11/4/19@15:39:01: DEBUG: 2402 {child_exit} waitpid returned = -1
11/4/19@15:39:01: DEBUG: 2402 {main_loop} active_services = 1

So then I tried the same thing with RHEL5, and it failed there too.
Since I haven't tried testing this before maybe there's something
bogus about my setup, but at least the two releases are acting the same. :-)
Comment 37 Linda Knippers 2011-04-19 16:59:27 EDT
In reply to comment 36:

I'm pretty sure I'm doing something wrong with that test.  Time to read the evaluated config guide.
Comment 38 Stephen Smalley 2011-04-19 17:12:11 EDT
(In reply to comment #35)
> I agree with Stephen.  I don't think this problem is related to running
> multiple levels of sshd from xinetd because the behavior difference I see is
> when using sshd on the default port.  With RHEL5, unlabeled packets go through
> and on RHEL6, they don't.  On RHEL6, my existing network connections stop as
> soon as I run my first netlabelctl command, but on RHEL5, the connections
> continue to work.  
> Maybe its a netlabel bug.  When I first talked to Paul about this the theory
> was that it was the type enforcement but the AVCs suggest otherwise.

This suggests that RHEL5 is incorrect, not RHEL6.  sshd running with a current level of SystemLow shouldn't be able to receive an unlabeled packet (mapped to SystemHigh) under MLS constraints. Alternatives:
a) Make sshd a MLS trusted subject, so that it can still receive unlabeled traffic (and traffic at any level).
-or-
b) Assign systemlow to unlabeled packets (via netlabelctl unlbl add default...) so that systemlow processes, including sshd, can receive them but not receive labeled packets at higher levels.
Comment 39 Paul Moore 2011-04-19 17:13:51 EDT
(In reply to comment #35) 
> Maybe its a netlabel bug.  When I first talked to Paul about this the theory
> was that it was the type enforcement but the AVCs suggest otherwise.

While it would be foolish to rule anything out without a better understanding, I would be very surprised if this is a NetLabel bug since this is unlabeled traffic we are talking about and it appears to be correctly labeled as unlabeled_t.  There is a better likelihood of it being a problem with the SELinux network controls, but from everything I've read so far it appears to either be a bug in the policy or an understanding of how things should be working.
Comment 40 Linda Knippers 2011-04-19 17:31:48 EDT
(In reply to comment #38)

sshd isn't running at SystemLow on my system.  

# ps axlZ | grep sshd
system_u:system_r:sshd_t:SystemLow-SystemHigh 5 0 1759 1 20 0 63944 1076 poll_s Ss   ?          0:00 /usr/sbin/sshd

Its the same on my RHEL5 system.
Comment 41 Stephen Smalley 2011-04-20 07:32:38 EDT
(In reply to comment #40)
> (In reply to comment #38)
> 
> sshd isn't running at SystemLow on my system.  
> 
> # ps axlZ | grep sshd
> system_u:system_r:sshd_t:SystemLow-SystemHigh 5 0 1759 1 20 0 63944 1076 poll_s
> Ss   ?          0:00 /usr/sbin/sshd
> 
> Its the same on my RHEL5 system.

The low level of the range (in this case SystemLow) is used as the current or active level for normal MLS access control checks, so sshd is limited to reading SystemLow data by default.  The high level of the range (in this case SystemHigh) is used as the clearance or maximum level, which caps the highest level to which the process can transition via e.g. newrole -l.  The high level can also come into play in constraints if the process domain has a type attribute like mlsnetreadtoclr, which means that the process is allowed to receive packets up to its clearance/high level rather than being limited to its current/low level.  But at present sshd_t does not have mlsnetreadtoclr in policy.  As I said, you either need to grant it such attributes or you need to change the level assigned to unlabeled traffic.  Those two actions have different results:  the former allows sshd to receive any traffic, while the latter allows sshd (and others) to receive unlabeled traffic but not higher level labeled traffic. As to which is the right choice for you depends on your security goals.  I'd typically expect sshd to be part of the TCB, like login, but I don't know what is included in your evaluation.
Comment 42 Linda Knippers 2011-04-20 14:21:43 EDT
sshd is part of the TCB.  

In RHEL5, unlabeled packets were accepted by default although there was a way to disable it.  I thought the intent was the same for RHEL6 but I need to double-check that.

Just trying to understand what changed between RHEL5 and RHEL6, I see there are many more networking-related constraints in policy/mls than there used to be.  Is this why the ssh policy didn't need the mlsnetreadtoclr attribute before?
Comment 43 Stephen Smalley 2011-04-20 14:36:59 EDT
(In reply to comment #42)
> sshd is part of the TCB.  

Then there is no reason for it to not have the mlnetread attribute, which would resolve this issue for you.

> In RHEL5, unlabeled packets were accepted by default although there was a way
> to disable it.  I thought the intent was the same for RHEL6 but I need to
> double-check that.
> 
> Just trying to understand what changed between RHEL5 and RHEL6, I see there are
> many more networking-related constraints in policy/mls than there used to be. 
> Is this why the ssh policy didn't need the mlsnetreadtoclr attribute before?

There was a significant overhaul of the network checks in RHEL6, and I think there was some cleanup of the MLS constraints.  Could have been either one of those changes.
Comment 44 Linda Knippers 2011-04-20 14:43:10 EDT
(In reply to comment #31)
> I'm unclear as to whether xinetd is even relevant to this bug.
> The AVC denials are for sshd and dnsmasq and are on unlabeled packets; thus,
> xinetd labeled networking support is irrelevant AFAICS.
> The correct question is do you expect these packets to be labeled, and if so,
> why are they not labeled (e.g. NetLabel bug or misconfiguration)?
> In the steps to reproduce, you defined a NetLabel DOI, but you didn't add any
> domain mappings AFAICS, so there wouldn't yet be any labeled traffic.
> 
> The reason you encounter the denials after defining the DOI is that peer
> permission check is only performed if someone configures labeled networking;
> that was a compatibility compromise to avoid breaking existing systems when the
> new network permission checks were introduced. 
> So before defining the DOI, you need to configure handling of unlabeled packets
> and/or allow receipt of unlabeled packets if that is what you want.

I believe I have netlabel configured to allow unlabeled packets as that is the
default on both systems.  What I'm fuzzy on is whether the packets are actually
unlabeled or whether they're being automatically labeled by default as
unlabeled_t and SystemHigh.
Comment 45 Linda Knippers 2011-04-20 14:46:10 EDT
(In reply to comment #43)
> (In reply to comment #42)
> > sshd is part of the TCB.  
> 
> Then there is no reason for it to not have the mlnetread attribute, which would
> resolve this issue for you.

I will give that a try.  

I'm also verifying that what I want is consistent with the RHEL6 evaluation claims.
Comment 46 Daniel Walsh 2011-04-20 14:47:44 EDT
I guess the question I have is:  Is this the only daemon that needs this, or do all network services need this.  apache?  Do they need to be able to read SystemHigh?  Or just read to Range.  apache by default would run as SystemLow, sshd just happens to cover the entire range.
Comment 47 Daniel Walsh 2011-04-20 14:49:59 EDT
If these packets were labeled unlabeled_t:s0, we would not have this problem,  Is this how we should label them?
Comment 48 Paul Moore 2011-04-20 14:52:49 EDT
(In reply to comment #44)
> I believe I have netlabel configured to allow unlabeled packets as that is the
> default on both systems.  What I'm fuzzy on is whether the packets are actually
> unlabeled or whether they're being automatically labeled by default as
> unlabeled_t and SystemHigh.

By default all unlabeled packets are labeled as unlabeled_t:SystemHigh, just like any other piece of unlabeled data imported into the system.  Remember, everything _must_ have a label assigned to it so that the kernel can apply the security policy to the object.
Comment 49 Stephen Smalley 2011-04-20 14:54:25 EDT
Use netlabelctl unlbl add ... to specify a label other than unlabeled_t:SystemHigh for unlabeled traffic if that is what you want.
Comment 50 Linda Knippers 2011-04-20 16:29:26 EDT
You have to do that for every source network but at least it worked for me and my ssh sessions.

# netlabelctl unlbl add default address:<mysubnet> label:system_u:object_r:unlabeled_t:s0

Paul, regarding comment $48, how did this work before?
Comment 51 Paul Moore 2011-04-20 16:45:47 EDT
(In reply to comment #50)
> You have to do that for every source network but at least it worked for me and
> my ssh sessions.
> 
> # netlabelctl unlbl add default address:<mysubnet>
> label:system_u:object_r:unlabeled_t:s0

Try 0.0.0.0/0 for <mysubnet>.

> Paul, regarding comment $48, how did this work before?

It has always worked this way as far as I can remember.
Comment 52 Daniel Walsh 2011-04-22 07:17:38 EDT
Stephan or Eric I am not sure how I could change this to make labeled packets SystemLow by default.

#
# unlabeled_t is the type of unlabeled objects.
# Objects that have no known labeling information or that
# have labels that are no longer valid are treated as having this type.
#
type unlabeled_t;
sid unlabeled gen_context(system_u:object_r:unlabeled_t,mls_systemhigh)
fs_associate(unlabeled_t)


If I change this to s0, then everything on the system that does not have a label will be treated as SystemLow including files without labels, which is not what we want.

# These initial sids are no longer used, and can be removed:
sid any_socket		gen_context(system_u:object_r:unlabeled_t,mls_systemhigh)
...

These would seem like the logical place but the code says they are no longer used?
Comment 53 Stephen Smalley 2011-04-22 08:05:26 EDT
Don't change the initial SID contexts.  If they want unlabeled packets to be SystemLow by default, then they can use netlabelctl unlbl add default to do so.  No change to policy required there.  Or if they want sshd to be able to receive packets at any level, you can add mlsnetreadtoclr to sshd_t.
Comment 54 Linda Knippers 2011-04-22 11:57:29 EDT
I think we can do what we need using netlabelctl or with a few policy tweaks 
as Stephen said.  I still don't have everything working yet because I've run 
into a few other problems, like the port I used in RHEL5 being blocked in 
RHEL6, but I'm working through that thanks to Joe Nall.  

Quick question though - I didn't get an AVC when my test server's bind was 
failing, even though it worked in permissive mode.  I assume there are 
dontaudit rules preventing the AVCs?  Is there any way to override the
dontaudit policy?

Also, is this information and the links it points to current?
http://selinuxproject.org/page/NB_Networking
Or is there a better source of information?

Dan, I'm seeing a few policy problems (netlabelctl can't be run at boot time 
by init), files labeled incorrectly after boot, etc. but I'll report those 
separately.  If you want to close this BZ, I won't object.
Comment 55 Stephen Smalley 2011-04-22 13:30:04 EDT
(In reply to comment #54)
> Quick question though - I didn't get an AVC when my test server's bind was 
> failing, even though it worked in permissive mode.  I assume there are 
> dontaudit rules preventing the AVCs?  Is there any way to override the
> dontaudit policy?

# Strip all dontaudit rules from policy.
# Will generate many AVCs that you don't care about.
semodule -DB

# Will restore dontaudit rules.
semodule -B
Comment 56 Linda Knippers 2011-04-22 17:19:43 EDT
Thanks, I see that in the manpage now.
Comment 58 Daniel Walsh 2011-04-28 11:15:19 EDT
Is this still considered a bug, or just the responsibility of the admin or provider of the cert, to explain how to allow all domains access to unlabeled packets.
Comment 59 Linda Knippers 2011-04-28 11:25:07 EDT
Dan, I noted in #54 that I'm ok with closing this bz and leaving the policy as an exercise for the user.  Some documentation would be nice though.  I've had to piece it together from various blog postings with help from developers.  

BTW, I don't actually have all the networking tests running yet.  I think I've 
gotten the TE part of the policy right but I'm seeing syscalls succeed that 
should fail due to the MLS constraints so I'm still sorting through that.  If I find a bug there, I will open a separate bz.
Comment 60 Steve Grubb 2011-05-10 10:25:39 EDT
This bug is being closed based on comments #54 and #59.

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