Red Hat Bugzilla – Bug 839404
SELinux issues when enabling NIS
Last modified: 2016-07-01 05:33:56 EDT
Description of problem:
When authconfig is used to enable NIS via anaconda/kickstart, the SELinux context on /etc/yp.conf is incorrect. Although NIS winds up enabled, the SELinux policy is not updated to allow use of NIS.
Version-Release number of selected component (if applicable):
(Substitute your own servers for the Example entries below)
Create a Kickstart with the following:
authconfig --enablemd5 --enableshadow --enablenis --nisdomain example.com --nisserver nis.example.com --enablekrb5 --krb5realm EXAMPLE.COM
Steps to Reproduce:
1. Install a box via kickstart with an authconfig command similar to the above.
2. Ensure that SELinux is Enforcing and that auditd is installed and enabled
3. ssh into the resulting system
4. Check /var/log/messages and ls -lZ /etc/yp.conf
yp.conf has context: system_u:object_r:etc_t:s0
Lots of AVC messages involving sshd and dbus attempting to use bind/named_sockets.
yp.conf has context: system_u:object_r:net_conf_t:s0
No AVC messages.
This can be fixed or worked around by:
setsebool -P allow_ypbind 1
The boolean is supposed to be set by the init script of ypbind.
Not sure about the context on yp.conf - running restorecon from authconfig doesn't seem to me as a the best way.
In this case, ypbind wasn't actually started; thus setsebool wasn't executed.
authconfig does manipulate yp.conf, in /usr/share/authconfig/authinfo.py. If that manipulation is causing a change of SELinux context, there's likely a fix to be made there. Since authconfig is being called from kickstart here, I haven't been able to check what the original context of the file was.
This is a problem on RHEL6.3 without filename transition. Could we run the restorecon also in the init script?
There is another bug #681134 similar to this one. John, can you confirm that the SELinux messages are the same and are emitted by dhclient-script?
There is also a patch attached to bug #681134, if you could reproduce this failure, does the patch fixes it?
The messages I'm seeing are a result of not having started ypbind (and thus having setsebool run):
SELinux is preventing /bin/dbus-daemon from name_bind access on the tcp_socket
SELinux is preventing /bin/dbus-daemon from name_connect access on the tcp_socket
SELinux is preventing /usr/sbin/ntpdate from name_bind access on the tcp_socket
SELinux is preventing /usr/sbin/ntpdate from name_connect access on the tcp_socket
SELinux is preventing /usr/bin/procmail from name_bind access on the tcp_socket
SELinux is preventing /usr/bin/procmail from name_connect access on the tcp_socket
Not sure which fix (restorecon or setsebool) got rid of this one:
SELinux is preventing /usr/sbin/sshd from search access on the directory /var/yp
I'm not seeing any avc messages about dhclient in the logs, although /sbin/dhclient has been running just fine both before and after the restorecon/setsebool changes.
I did confirm that the ypbind rpm creates a yp.conf file with the correct context, by:
# rpm --nodeps --root /test_ypconf -ivh ypbind-1.20.4-29.el6.x86_64.rpm
and checking the ensuing /test_ypconf/etc/yp.conf file.
So something else is changing the context someplace.
From what I see in the logs, the sequence was:
- Fresh 6.3 install
- in %post, Configure RHN, run updates, install additional packages
- observe AVC messages only after the reboot
But note that ypbind wasn't actually chkconfig'd to start on boot. (That's on the list of things to address in the next revision of the %post for this machine.)
(In reply to comment #6)
> This is a problem on RHEL6.3 without filename transition. Could we run the
> restorecon also in the init script?
We probably could, but if the messages appear even before ypbind is started, it should be called from authinfo.py script as John suggests, probably together with setsebool call. Is this a problem to do in authconfig for some reason?
(In reply to comment #8)
> Not sure which fix (restorecon or setsebool) got rid of this one:
> SELinux is preventing /usr/sbin/sshd from search access on the directory
I reproduced this with a kickstart containing authconfig command as mentioned above and then tried to use "setsebool -P allow_ypbind on" and "restorecon /etc/yp.conf" in %post section of the kickstart. Using setsebool is enough to get rid of all messages, so I'd say that wrong context is a different issue (btw. already reported separately in bug #681134, now we have even a reproducer for it).
Thinking a bit more about it, it doesn't make sense to have NIS configured using authconfig and not have allow_ypbind on. A bug proposing turning on it in authconfig already exists (bug #741646), but was closed as wontfix. Without that we can't get rid of such AVC messages before ypbind is started, so re-assigning back to authconfig, since I don't see a solution that can be made in ypbind.
I just want to verify it again, just doing setsebool -P allow_ypbind 1 fixes the avcs for you?
This request was evaluated by Red Hat Product Management for
inclusion in the current release of Red Hat Enterprise Linux.
Because the affected component is not scheduled to be updated
in the current release, Red Hat is unable to address this
request at this time.
Red Hat invites you to ask your support representative to
propose this request, if appropriate, in the next release of
Red Hat Enterprise Linux.
(In reply to Honza Horak from comment #9)
> (In reply to comment #6)
> > This is a problem on RHEL6.3 without filename transition. Could we run the
> > restorecon also in the init script?
> We probably could, but if the messages appear even before ypbind is started,
> it should be called from authinfo.py script as John suggests, probably
> together with setsebool call. Is this a problem to do in authconfig for some
authconfig is unconfined domain.