Bug 834698 - too restrictive if allow_ypbind is off
too restrictive if allow_ypbind is off
Status: CLOSED NOTABUG
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: selinux-policy (Show other bugs)
6.3
All Linux
unspecified Severity medium
: rc
: ---
Assigned To: Miroslav Grepl
BaseOS QE Security Team
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-06-22 16:04 EDT by Karel Volný
Modified: 2012-11-07 05:00 EST (History)
5 users (show)

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


Attachments (Terms of Use)

  None (edit)
Description Karel Volný 2012-06-22 16:04:44 EDT
Description of problem:
I'm getting avc denials on one machine all the time. If I use audit2allow, it tells me:

#!!!! This avc can be allowed using the boolean 'allow_ypbind'

for every single one of them.

But ypbind is not running, so I see no reason why this boolean should be on.
The denials happen on normal, I suppose valid, operations.

The machine is x86_64 running RHEL6 Client. It happens even after clean install and only a little initial QA setup.


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


How reproducible:
always


Steps to Reproduce:
1. run the system for a while, do some stuff (not sure what exact actions trigger the problems; there is hostname in the logs for example, but simply running `hostname` command from shell doesn't seem to be enough)
2. grep AVC /var/log/audit/audit.log

  
Actual results:
...
type=AVC msg=audit(1340394808.338:4063): avc:  denied  { node_bind } for  pid=29171 comm="hostname" scontext=system_u:system_r:hostname_t:s0 tcontext=system_u:object_r:node_t:s0 tclass=tcp_socket
type=AVC msg=audit(1340394808.338:4064): avc:  denied  { name_bind } for  pid=29171 comm="hostname" src=940 scontext=system_u:system_r:hostname_t:s0 tcontext=system_u:object_r:hi_reserved_port_t:s0 tclass=tcp_socket
type=AVC msg=audit(1340394808.338:4065): avc:  denied  { name_connect } for  pid=29171 comm="hostname" dest=111 scontext=system_u:system_r:hostname_t:s0 tcontext=system_u:object_r:portmap_port_t:s0 tclass=tcp_socket
type=AVC msg=audit(1340394841.688:4072): avc:  denied  { name_connect } for  pid=29469 comm="procmail" dest=111 scontext=system_u:system_r:procmail_t:s0 tcontext=system_u:object_r:portmap_port_t:s0 tclass=tcp_socket
type=AVC msg=audit(1340394841.689:4073): avc:  denied  { name_bind } for  pid=29469 comm="procmail" src=813 scontext=system_u:system_r:procmail_t:s0 tcontext=system_u:object_r:hi_reserved_port_t:s0 tclass=tcp_socket
type=AVC msg=audit(1340394841.689:4074): avc:  denied  { name_connect } for  pid=29469 comm="procmail" dest=111 scontext=system_u:system_r:procmail_t:s0 tcontext=system_u:object_r:portmap_port_t:s0 tclass=tcp_socket
type=AVC msg=audit(1340394841.692:4075): avc:  denied  { name_connect } for  pid=29471 comm="dbus-daemon-lau" dest=111 scontext=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:portmap_port_t:s0 tclass=tcp_socket
type=AVC msg=audit(1340394841.693:4076): avc:  denied  { name_bind } for  pid=29471 comm="dbus-daemon-lau" src=815 scontext=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:hi_reserved_port_t:s0 tclass=tcp_socket
type=AVC msg=audit(1340394841.693:4077): avc:  denied  { name_connect } for  pid=29471 comm="dbus-daemon-lau" dest=111 scontext=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:portmap_port_t:s0 tclass=tcp_socket
type=AVC msg=audit(1340394962.361:4090): avc:  denied  { name_connect } for  pid=29522 comm="procmail" dest=111 scontext=system_u:system_r:procmail_t:s0 tcontext=system_u:object_r:portmap_port_t:s0 tclass=tcp_socket
type=AVC msg=audit(1340394962.361:4091): avc:  denied  { name_bind } for  pid=29522 comm="procmail" src=866 scontext=system_u:system_r:procmail_t:s0 tcontext=system_u:object_r:hi_reserved_port_t:s0 tclass=tcp_socket
type=AVC msg=audit(1340394962.362:4092): avc:  denied  { name_connect } for  pid=29522 comm="procmail" dest=111 scontext=system_u:system_r:procmail_t:s0 tcontext=system_u:object_r:portmap_port_t:s0 tclass=tcp_socket
type=AVC msg=audit(1340394962.366:4093): avc:  denied  { name_connect } for  pid=29524 comm="dbus-daemon-lau" dest=111 scontext=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:portmap_port_t:s0 tclass=tcp_socket
...

Expected results:
no errors

Additional info:
Comment 4 Milos Malik 2012-06-25 03:07:25 EDT
My opinion: allow_ypbind boolean contains a lot of rules which are not always related to the name of the boolean. Maybe the rules in the boolean should be divided into more booleans which will be more specific.
Comment 5 Miroslav Grepl 2012-06-25 03:19:14 EDT
Karel,
so you are getting these AVC msgs and you are not using NIS?
Comment 6 Karel Volný 2012-06-25 08:30:23 EDT
(In reply to comment #5)
> Karel,
> so you are getting these AVC msgs and you are not using NIS?

I believe so ... no yp* daemon running on that machine

how do I know that individual commands like "hostname", "sshd", "procmail", "dbus-daemon-launch" ... try to do something with NIS? (why should they do that?)

I remember, for running some yppasswd tests we've used to switch the boolean on, but we never ever needed it elsewhere
Comment 7 Daniel Walsh 2012-06-25 12:32:04 EDT
Look at /etc/nsswitch.conf

Any app that does a getpw call will intereact with NIS/YPBIND if the /etc/nsswitch.conf file is configured, whether or not you are executing ypbind.

If you are not using NIS then do not turn on this boolean since it is very loose,  IE Every domain can bind to any port and connect to random ports.

In the case of your avc's you have hostname trying to run as a service?

Also lots of domains trying to connect to port 111, portmap_port_t.
Comment 8 Karel Volný 2012-06-25 13:14:53 EDT
now I'm getting really confused because /etc/nsswitch.conf contents are the same as on another machine RHEL6 server), where allow_ypbind is off, and there are no such errors on that machine ...
Comment 10 Daniel Walsh 2012-06-25 16:27:20 EDT
Do you have anything out of the usual in /etc/nsswitch.conf?
Comment 11 Karel Volný 2012-06-26 04:32:34 EDT
examining the file closely and re-reading "Any app that does a getpw call will intereact with NIS/YPBIND if the /etc/nsswitch.conf file is configured, whether or not you are executing ypbind." I see something ... there is:

passwd:     files nis

so, it _may_ explain some ssh problems if the login cannot be resolved locally, but in no way it'd explain the hostname issue as the value is set in /etc/sysconfig/network and not read from the network

all the differences to the package supplied version of nsswitch.conf are:

33,35c33,35
< passwd:     files
< shadow:     files
< group:      files
---
> passwd:     files nis
> shadow:     files nis
> group:      files nis
38c38
< hosts:      files dns
---
> hosts:      files nis dns
57c57
< netgroup:   nisplus
---
> netgroup:   files nis
61c61
< automount:  files nisplus
---
> automount:  files nis



but, as mentioned, this configuration, 100% (md5) the same, doesn't cause any troubles on another machine, so there is a mystery to be solved ... maybe the selinux is right and there is some rogue library (glibc itself?) doing something it shouldn't do ... what to investigate next?
Comment 13 Daniel Walsh 2012-06-26 06:17:04 EDT
This would be a glibc issue. I am not sure when it makes the network calls on resolution of getpw or resolving hostnames.  But this is what is going on.
Comment 14 Karel Srot 2012-06-27 06:42:22 EDT
Hi Jeff,
could you take a look?
Comment 15 RHEL Product and Program Management 2012-07-10 04:19:02 EDT
This request was not resolved in time for the current release.
Red Hat invites you to ask your support representative to
propose this request, if still desired, for consideration in
the next release of Red Hat Enterprise Linux.
Comment 16 RHEL Product and Program Management 2012-07-10 21:57:00 EDT
This request was erroneously removed from consideration in Red Hat Enterprise Linux 6.4, which is currently under development.  This request will be evaluated for inclusion in Red Hat Enterprise Linux 6.4.
Comment 17 Miroslav Grepl 2012-10-15 10:58:05 EDT
I believe this should be handled by this boolean anyway. Closing this bug. Please reopen if you don't agree with me. Thank you.
Comment 18 Karel Volný 2012-11-02 13:14:10 EDT
(In reply to comment #17)
> I believe this should be handled by this boolean anyway. Closing this bug.
> Please reopen if you don't agree with me. Thank you.

well, while I'd disagree - just enabling some boolean to get rid of error messages isn't the_right_thing(tm) - there's not too much to debug as the machine seems to have stopped misbehaving ... maybe INSUFFICIENT_DATA would be better resolution ...

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