I'm trying to get ldap (from openldap-servers-2.4.8-6) running in enforcing mode on a F9 server. When I try in enforcing mode, it fails. I've attaced the AVCs from the audit log, for 'service ldap start' in enforcing and permissive mode (with don't audit disabled), along with the avcs after the first round were passed through audit2allow and loaded.. After those are added and loaded, it starts up fine with no AVCs...
Should I file a bug report in bugzilla, or is this message sufficient?
Sending to the list as well. I hate reply-to: :)
Robert Story wrote:
I'm trying to get ldap (from openldap-servers-2.4.8-6) running in enforcing mode on a F9 server. When I try in enforcing mode, it fails. I've attaced the AVCs from the audit log, for 'service ldap start' in enforcing and permissive mode (with don't audit disabled), along with the avcs after the first round were passed through audit2allow and loaded.. After those are added and loaded, it starts up fine with no AVCs...
what exactly did audit2allow tell you to add?
From the AVCs this looks like a mislabelled cert - /etc/openldap/cacerts/cacert.pem which is labelled as user_tmp_t
what is reported by this: # restorecon -Rnv /etc/openldap/cacerts
The CA certificate you have there wasn't moved from /tmp by any chance?
Stuart
On Thu, 2008-07-17 at 17:24 -0400, Robert Story wrote:
I'm trying to get ldap (from openldap-servers-2.4.8-6) running in enforcing mode on a F9 server. When I try in enforcing mode, it fails. I've attaced the AVCs from the audit log, for 'service ldap start' in enforcing and permissive mode (with don't audit disabled), along with the avcs after the first round were passed through audit2allow and loaded.. After those are added and loaded, it starts up fine with no AVCs...
Should I file a bug report in bugzilla, or is this message sufficient?
Just to make sure it can't possibly get lost I usually file a BZ. But:
Most of these are 'bogus' The majority of them are some form of slapd is trying to read files in /selinux and /etc/selinux. I don't know why slapd would be trolling around in either of those directories but I can't imagine it would cause an actual problem in the operation of slapd.
The real issue are these: type=AVC msg=audit(1216329419.086:433): avc: denied { getattr } for pid=2886 comm="slapd" path="/etc/openldap/cacerts/cacert.pem" dev=dm-4 ino=204805 scontext=unconfined_u:system_r:slapd_t:s0 tcontext=unconfined_u:object_r:user_tmp_t:s0 tclass=file type=AVC msg=audit(1216329419.220:434): avc: denied { getattr } for pid=2886 comm="slapd" path="/etc/openldap/cacerts/cacert.pem" dev=dm-4 ino=204805 scontext=unconfined_u:system_r:slapd_t:s0 tcontext=unconfined_u:object_r:user_tmp_t:s0 tclass=file type=AVC msg=audit(1216329419.223:435): avc: denied { getattr } for pid=2886 comm="slapd" path="/etc/openldap/slapd.pem" dev=dm-4 ino=204830 scontext=unconfined_u:system_r:slapd_t:s0 tcontext=unconfined_u:object_r:user_tmp_t:s0 tclass=file
These indicate to me that cacert.pem and slapd.pem were both created in /tmp/and moved to /etc/openldap. This is a labeling issue. slapd doesn't normally need access to files created in /tmp and since those files have been moved you need to reset their attributes approprietely to their new location.
restorecon -R -v /etc/openldap
After doing that can you send up the denials you get (with dontaudits) and if it gives you any more trouble?
Also can you help us understand how these two .pem files were created and how the got into /etc/openldap so we can try to fix this for others?
-Eric
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Eric Paris wrote:
On Thu, 2008-07-17 at 17:24 -0400, Robert Story wrote:
I'm trying to get ldap (from openldap-servers-2.4.8-6) running in enforcing mode on a F9 server. When I try in enforcing mode, it fails. I've attaced the AVCs from the audit log, for 'service ldap start' in enforcing and permissive mode (with don't audit disabled), along with the avcs after the first round were passed through audit2allow and loaded.. After those are added and loaded, it starts up fine with no AVCs...
Should I file a bug report in bugzilla, or is this message sufficient?
Just to make sure it can't possibly get lost I usually file a BZ. But:
Most of these are 'bogus' The majority of them are some form of slapd is trying to read files in /selinux and /etc/selinux. I don't know why slapd would be trolling around in either of those directories but I can't imagine it would cause an actual problem in the operation of slapd.
The real issue are these: type=AVC msg=audit(1216329419.086:433): avc: denied { getattr } for pid=2886 comm="slapd" path="/etc/openldap/cacerts/cacert.pem" dev=dm-4 ino=204805 scontext=unconfined_u:system_r:slapd_t:s0 tcontext=unconfined_u:object_r:user_tmp_t:s0 tclass=file type=AVC msg=audit(1216329419.220:434): avc: denied { getattr } for pid=2886 comm="slapd" path="/etc/openldap/cacerts/cacert.pem" dev=dm-4 ino=204805 scontext=unconfined_u:system_r:slapd_t:s0 tcontext=unconfined_u:object_r:user_tmp_t:s0 tclass=file type=AVC msg=audit(1216329419.223:435): avc: denied { getattr } for pid=2886 comm="slapd" path="/etc/openldap/slapd.pem" dev=dm-4 ino=204830 scontext=unconfined_u:system_r:slapd_t:s0 tcontext=unconfined_u:object_r:user_tmp_t:s0 tclass=file
These indicate to me that cacert.pem and slapd.pem were both created in /tmp/and moved to /etc/openldap. This is a labeling issue. slapd doesn't normally need access to files created in /tmp and since those files have been moved you need to reset their attributes approprietely to their new location.
restorecon -R -v /etc/openldap
After doing that can you send up the denials you get (with dontaudits) and if it gives you any more trouble?
Also can you help us understand how these two .pem files were created and how the got into /etc/openldap so we can try to fix this for others?
-Eric
-- fedora-selinux-list mailing list fedora-selinux-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-selinux-list
setroubleshoot says:
Summary:
SELinux is preventing the slapd from using potentially mislabeled files (/etc/openldap/slapd.pem).
Detailed Description:
[SELinux is in permissive mode, the operation would have been denied but was permitted due to permissive mode.]
SELinux has denied slapd access to potentially mislabeled file(s) (/etc/openldap/slapd.pem). This means that SELinux will not allow slapd to use these files. It is common for users to edit files in their home directory or tmp directories and then move (mv) them to system directories. The problem is that the files end up with the wrong file context which confined applications are not allowed to access.
Allowing Access:
If you want slapd to access this files, you need to relabel them using restorecon -v '/etc/openldap/slapd.pem'. You might want to relabel the entire directory using restorecon -R -v '/etc/openldap'.
Additional Information:
Source Context unconfined_u:system_r:slapd_t:s0 Target Context unconfined_u:object_r:user_tmp_t:s0 Target Objects /etc/openldap/slapd.pem [ file ] Source slapd Source Path <Unknown> Port <Unknown> Host <Unknown> Source RPM Packages Target RPM Packages Policy RPM selinux-policy-3.5.0-2.fc10 Selinux Enabled True Policy Type targeted MLS Enabled True Enforcing Mode Permissive Plugin Name home_tmp_bad_labels Host Name redsox.boston.devel.redhat.com Platform Linux redsox.boston.devel.redhat.com 2.6.26-0.124.rc9.git5.fc10.x86_64 #1 SMP Wed Jul 9 17:11:05 EDT 2008 x86_64 x86_64 Alert Count 1 First Seen Thu Jul 17 17:16:59 2008 Last Seen Thu Jul 17 17:16:59 2008 Local ID d667d771-5046-4373-a911-7fccd8ae0e81 Line Numbers 1
Raw Audit Messages
type=AVC msg=audit(1216329419.223:435): avc: denied { getattr } for pid=2886 comm="slapd" path="/etc/openldap/slapd.pem" dev=dm-4 ino=204830 scontext=unconfined_u:system_r:slapd_t:s0 tcontext=unconfined_u:object_r:user_tmp_t:s0 tclass=file
On Thu, 17 Jul 2008 23:30:40 -0400 Eric wrote: EP> These indicate to me that cacert.pem and slapd.pem were both created EP> in /tmp/and moved to /etc/openldap. [...] EP> EP> restorecon -R -v /etc/openldap EP> EP> After doing that can you send up the denials you get (with dontaudits) EP> and if it gives you any more trouble?
No more trouble after that... Sorry for the noise..
EP> Also can you help us understand how these two .pem files were created EP> and how the got into /etc/openldap so we can try to fix this for others?
It was just a manual process... generated the certificates on a another machine and scp'd them to /tmp/ because it's short and easier than trying to remember the real path from the HOWTO on another machine...
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Robert Story wrote:
On Thu, 17 Jul 2008 23:30:40 -0400 Eric wrote: EP> These indicate to me that cacert.pem and slapd.pem were both created EP> in /tmp/and moved to /etc/openldap. [...] EP> EP> restorecon -R -v /etc/openldap EP> EP> After doing that can you send up the denials you get (with dontaudits) EP> and if it gives you any more trouble?
No more trouble after that... Sorry for the noise..
EP> Also can you help us understand how these two .pem files were created EP> and how the got into /etc/openldap so we can try to fix this for others?
It was just a manual process... generated the certificates on a another machine and scp'd them to /tmp/ because it's short and easier than trying to remember the real path from the HOWTO on another machine...
-- fedora-selinux-list mailing list fedora-selinux-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-selinux-list
I guess this is the number one thing we need to teach unix administrators. With SELinux when you get a permission denied message there are 3 things to check. Ownership, Permissions which all admins have ingrained into them, and SELinux Label.
chown OWNER PATH chmod PERM PATH restorecon PATH
selinux@lists.fedoraproject.org