Description of problem: One of the rpms our product installs calls 'semanage port -a -t ldap_port_t -p tcp 4389' in its post install script. This seems to work except in one use case: 1) SELinux disabled initially. 2) Install my application policy using semanage -i as before. 3) Set SELinux to enforcing mode. 4) Reboot, and SELinux denies applications access to LDAP server running on port 4389. This is particularly painful to debug as this slows down the boot process immensely, and breaks user authentication. My testing on RHEL5, without my app installed shows the command 'semanage port -a -t ldap_port_t -p tcp 4389' gives the following error if SELinux is disabled. libsepol.context_from_record: MLS is enabled, but no MLS context found libsepol.context_from_record: could not create context structure libsepol.port_from_record: could not create port structure for range 4389:4389 (tcp) libsepol.sepol_port_modify: could not load port range 4389 - 4389 (tcp) libsemanage.dbase_policydb_modify: could not modify record value libsemanage.semanage_base_merge_components: could not merge local modifications into policy /usr/sbin/semanage: Could not add port tcp/4389 Version-Release number of selected component: policy-coreutils-1.33.12-3.el5 How reproducible: 100% Steps to Reproduce: 1. Disable SELinux. 2. Run 'semanage port -a -t ldap_port_t -p tcp 4389' 3. Error listed above occurs. Context not set for port 4389. Expected results: Expect semanage to succeed and set the context for port 4389 to ldap_port_t. Additional info: After some private email with Dan Walsh, he thinks I am pointing out a bug and recommended I log one. According to Dan, semodule -s targeted should allow you to install your policy module even when selinux is disabled, as long as selinux-policy-targeted is installed. But semanage does not have this qualifier, and he is of the opinion it should.
Fixed in policycoreutils-2.0.31-7.fc8 Added -S and --store to specify the store you are manipulating.
RHEL 5.1 seems to ship with policycoreutils-1.33.12-12.el5. I was hoping this fix would make it into 5.1. Is there a plan to issue an update? This is a real problem for me. Essentially a sysadmin can use our BridgeWays server management product to configure a server and various services with SELinux disabled, then break them just by enabling SELinux afterwards. The severity of the breakage depends on their choices, but when we originally came across this problem, no one could log into our test network or the servers. Network authentication of users via LDAP was not working, as the server was configured to run on port 4389. I also have bugs here where other server's that can be configured to run on non-standard ports (proxy server, httpd, and ftp) fail to work when configured when SELinux is enabled after the fact.
Yes I would like to update policycoreutils in the 5.2 update release.
This request was evaluated by Red Hat Product Management for inclusion in a Red Hat Enterprise Linux maintenance release. Product Management has requested further review of this request by Red Hat Engineering, for potential inclusion in a Red Hat Enterprise Linux Update release for currently deployed products. This request is not yet committed for inclusion in an Update release.
QE ack for RHEL5.2. Reproducer in comment 0.
Fixed in policycoreutils-1.33.12-13
Here is a patch fixing the bug: http://people.redhat.com/jkubin/stuff/316011.patch Dan currently isn't available and I unfortunately don't have sufficient rights to upload it. Tomorrow morning I'll ask him to merge it and for upload.
This bug is reproducible on RHEL5u2 system as well. the policycoreutils default version is 1.33.12-14.el5.
After following original method described in bug when I try to list selinux ports, it gives me following error [root@lifo ~]# semanage port -l /usr/sbin/semanage: SELinux policy is not managed or store cannot be accessed.
Does # semanage port -l -S targeted Work?
[root@lifo ~]# semanage port -l -S targeted /usr/sbin/semanage: Options Error option -S not recognized [root@lifo ~]# semanage port -l -s targeted -s not valid for port objects /usr/sbin/semanage: SELinux policy is not managed or store cannot be accessed.
At present this bug doesn't slow down the booting process as described in the original bug.
Created attachment 316030 [details] /var/log/dmessg log
Created attachment 316031 [details] /var/log/messages log
Manoj, you have a badly mislabeled file system. You need to touch /.autorelabel reboot
Even after relabelling the system, my ldap authentication fails(tested on multiple system).
Well that has nothing to do with this Bugzilla. Send me mail of your avc messages on ldap. Or open a new bugzilla.
Hi Dan as described in this original bug when I follow the method without my application installed. Steps to Reproduce: 1. Disable SELinux. 2. Run 'semanage port -a -t ldap_port_t -p tcp 4389' 3. Error listed above occurs. Context not set for port 4389. Result: libsepol.context_from_record: MLS is enabled, but no MLS context found libsepol.context_from_record: could not create context structure libsepol.port_from_record: could not create port structure for range 4389:4389 (tcp) libsepol.sepol_port_modify: could not load port range 4389 - 4389 (tcp) libsemanage.dbase_policydb_modify: could not modify record value libsemanage.semanage_base_merge_components: could not merge local modifications into policy /usr/sbin/semanage: Could not add port tcp/4389 Expected results: Expect semanage to succeed and set the context for port 4389 to ldap_port_t.
comment 2(of original bug ,very critical) is reproducible on RHEL5u2 system as well(because of semanage inability to add ports with SELinux disabled). policycoreutils on my test system is of version 1.33.12-14.el5
Right and the goal is to add a new field -S targeted which should allow the adding of the port semanage port -a -S targeted -t ldap_port_t -p tcp 4389 This works in Fedora 9 and Rawhide, but does not seem to have been properly backported to RHEL5 U3
Fixed in policycoreutils-1.33.12-14.1.el5
User jkubin's account has been closed
Fixed in policycoreutils-1.33.12-14.4.el5.src.rpm
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on therefore solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHBA-2009-1292.html