Bug 695799

Miroslav add 

	kernel_recvfrom_unlabeled_peer($1)
 to corenet_tcp_recvfrom_unlabeled

Probably should just back port corenetwork.if.in.

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

Paul what do you think the correct thing to do is here?

Do use this do we need to have sshd launched by xinetd at the proper level?

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.

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.

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.

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.

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.

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.

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.

I believe this is not abug.

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.

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.

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.

Updated summary to take policy out of the line.  Can we reopen the bug now?

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.

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.

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.

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.

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.

I am not sure if this is a selinux-policy or a xinetd, bug waiting for more confirmation from Linda.

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.

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.

In reply to comment 23:

RHEL5.6:       xinetd-2.3.14-10.el5
RHEL6.1 snap3: xinetd-2.3.14-31.el6.x86_64

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

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

In reply to comment 36:

I'm pretty sure I'm doing something wrong with that test.  Time to read the evaluated config guide.

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

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

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

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

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?

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

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

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

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.

If these packets were labeled unlabeled_t:s0, we would not have this problem,  Is this how we should label them?

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

Use netlabelctl unlbl add ... to specify a label other than unlabeled_t:SystemHigh for unlabeled traffic if that is what you want.

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?

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

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?

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.

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.

(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

Thanks, I see that in the manpage now.

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.

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.

This bug is being closed based on comments #54 and #59.