8:48 a.m.
Does anyone out there in OpenLDAP land have experience with working with
OpenLDAP and SELINUX?
Running OpenLDAP 2.4.43 on a CentOS 7 VM.
SELINUX is squashing client authentication connectivity - with SELINUX in
enforcing, and a user fails login (No Such User) - nothing at all in the
LDAP logs the only error is in the system auth.log. It acts as if the
system authentication process does not pass off to LDAP when the user is not
found locally; with SELINUX in Permissive, the user authenticates with the
LDAP Server with no problems.
If there is anyone who has been down this road it would be very much
appreciated.
Sincerely,
John D. Borresen (Dave)
Linux/Unix Systems Administrator
MIT Lincoln Laboratory
Email: <mailto:john.borresen@ll.mit.edu> john.borresen(a)ll.mit.edu
9:39 a.m.
On 03 Feb 2016, at 17:48 , Borresen, John - 0444 - MITLL
<John.Borresen(a)ll.mit.edu> wrote:
Does anyone out there in OpenLDAP land have experience with working with OpenLDAP and
SELINUX?
The standard procedure I use to debug SELinux issues and then create SELinux rule files to
allow previosuly forbidden interactions is the following (all steps as root). Don’t trust
anyone or any advice from random websites that tell you to just switch off SELinux to make
things work, those people obviously don’t know anything about the topic at all.
1) Switch from Enforcing to Permissive mode so everything is allowed but still fully
logged:
# setenforce permissive
2) Run through your test scenarios, like starting and stopping all the involved system
services and logging in/using your applications
3) Get a report using audit2allow:
# audit2allow -al
Now you have a report showing you what’s disallowed and what processes are involved.
4) To create a policy file that can be loaded into the SELinux rule set in order to
prevent the denials you create a type enforcement rule file (you can choose any name for
it that does not collide with built-in policies):
# audit2allow -alm my_custom_policy_name >my_custom_policy_name.te
5) Now you compile it into a format the kernel understands:
# checkmodule -M -m -o my_custom_policy_name.mod my_custom_policy_name.te
# semodule_package -o my_custom_policy_name.pp -m my_custom_policy_name.mod
6) Insert the compiled module (the .pp file) into the SELinux rule set:
# semodule -u my_custom_policy_name.pp
7) Now test again (return to step 2) and if there are any remaining issues follow steps
3-7. IMPORTANT: If you create a new policy file in step 4, make sure to INCREMENT the
version number that’s shown at the top of the file. If your new policy retains the old
policy version number it will not load.
8) Once you’re happy do not forget to return to enforcing mode:
# setenforce enforcing
Hope that helps,
jens
10:04 a.m.
Thank Jens!
I will try this out.
John D. Borresen (Dave)
Email: john.borresen(a)ll.mit.edu
-----Original Message-----
From: openldap-technical [mailto:openldap-technical-bounces@openldap.org] On Behalf Of
Jens Vagelpohl
Sent: Wednesday, February 03, 2016 12:40 PM
To: openldap-technical(a)openldap.org
Subject: Re: LDAP and SELINUX
On 03 Feb 2016, at 17:48 , Borresen, John - 0444 - MITLL
<John.Borresen(a)ll.mit.edu> wrote:
Does anyone out there in OpenLDAP land have experience with working with OpenLDAP and
SELINUX?
The standard procedure I use to debug SELinux issues and then create SELinux rule files to
allow previosuly forbidden interactions is the following (all steps as root). Don’t trust
anyone or any advice from random websites that tell you to just switch off SELinux to make
things work, those people obviously don’t know anything about the topic at all.
1) Switch from Enforcing to Permissive mode so everything is allowed but still fully
logged:
# setenforce permissive
2) Run through your test scenarios, like starting and stopping all the involved system
services and logging in/using your applications
3) Get a report using audit2allow:
# audit2allow -al
Now you have a report showing you what’s disallowed and what processes are involved.
4) To create a policy file that can be loaded into the SELinux rule set in order to
prevent the denials you create a type enforcement rule file (you can choose any name for
it that does not collide with built-in policies):
# audit2allow -alm my_custom_policy_name >my_custom_policy_name.te
5) Now you compile it into a format the kernel understands:
# checkmodule -M -m -o my_custom_policy_name.mod my_custom_policy_name.te #
semodule_package -o my_custom_policy_name.pp -m my_custom_policy_name.mod
6) Insert the compiled module (the .pp file) into the SELinux rule set:
# semodule -u my_custom_policy_name.pp
7) Now test again (return to step 2) and if there are any remaining issues follow steps
3-7. IMPORTANT: If you create a new policy file in step 4, make sure to INCREMENT the
version number that’s shown at the top of the file. If your new policy retains the old
policy version number it will not load.
8) Once you’re happy do not forget to return to enforcing mode:
# setenforce enforcing
Hope that helps,
jens
2558
days inactive
2558
days old
openldap-technical@openldap.org
2 comments
2 participants
participants (2)
-
Borresen, John - 0444 - MITLL -
Jens Vagelpohl