Bug 846084 - Call setsebool -P authlogin_nsswitch_use_ldap 1 when enabling LDAP
Call setsebool -P authlogin_nsswitch_use_ldap 1 when enabling LDAP
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: authconfig (Show other bugs)
rawhide
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Tomas Mraz
Fedora Extras Quality Assurance
: FutureFeature
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-08-06 15:02 EDT by John Ellson
Modified: 2012-09-25 16:11 EDT (History)
8 users (show)

See Also:
Fixed In Version: authconfig-6.2.4-1.fc19
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-09-25 16:11:53 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 John Ellson 2012-08-06 15:02:45 EDT
Description of problem:
I'm struggling to bring up a 389-ds.
selinux in *permissive* mode is preventing /usr/bin/sshd from accessing tcp_socket



Version-Release number of selected component (if applicable):
selinux-policy-targeted-3.10.0-142.fc17.noarch
nscd-2.15-51.fc17.x86_64

How reproducible:
100%

Steps to Reproduce:
1. // system is in permissive mode
# sestatus | grep mode
Current mode:                   permissive

2. // try to login to and ldap account with selinux in permissive mode (all components on same host)
$ ssh test@dir-p
test@dir-p's password: 
Permission denied, please try again.
test@dir-p's password: 

3. // /var/log/messages contains error
# tail -1 /var/log/messages
Aug  6 09:45:46 dir-p setroubleshoot: SELinux is preventing /usr/sbin/sshd from name_connect access on the tcp_socket . For complete SELinux messages. run sealert -l f82ad7ec-be1e-42c1-a192-fa7f10ff607c

4. // sealert message
# sealert -l f82ad7ec-be1e-42c1-a192-fa7f10ff607c
SELinux is preventing /usr/sbin/sshd from name_connect access on the tcp_socket .

*****  Plugin catchall (100. confidence) suggests  ***************************

If you believe that sshd should be allowed name_connect access on the  tcp_socket by default.
Then you should report this as a bug.
You can generate a local policy module to allow this access.
Do
allow this access for now by executing:
# grep sshd /var/log/audit/audit.log | audit2allow -M mypol
# semodule -i mypol.pp


Additional Information:
Source Context                system_u:system_r:sshd_t:s0-s0:c0.c1023
Target Context                system_u:object_r:ldap_port_t:s0
Target Objects                 [ tcp_socket ]
Source                        sshd
Source Path                   /usr/sbin/sshd
Port                          389
Host                          dir-p
Source RPM Packages           openssh-server-5.9p1-22.fc17.x86_64
Target RPM Packages           
Policy RPM                    selinux-policy-3.10.0-142.fc17.noarch
Selinux Enabled               True
Policy Type                   targeted
Enforcing Mode                Permissive
Host Name                     dir-p
Platform                      Linux dir-p 3.5.0-2.fc17.x86_64 #1 SMP Mon Jul 30
                              14:48:59 UTC 2012 x86_64 x86_64
Alert Count                   4
First Seen                    Mon 06 Aug 2012 09:04:59 AM EDT
Last Seen                     Mon 06 Aug 2012 09:45:46 AM EDT
Local ID                      f82ad7ec-be1e-42c1-a192-fa7f10ff607c

Raw Audit Messages
type=AVC msg=audit(1344260746.117:252): avc:  denied  { name_connect } for  pid=1921 comm="sshd" dest=389 scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:ldap_port_t:s0 tclass=tcp_socket


type=SYSCALL msg=audit(1344260746.117:252): arch=x86_64 syscall=connect success=no exit=EINPROGRESS a0=8 a1=7ff5cc285b40 a2=10 a3=7fff6275c9c0 items=0 ppid=718 pid=1921 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm=sshd exe=/usr/sbin/sshd subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 key=(null)

Hash: sshd,sshd_t,ldap_port_t,tcp_socket,name_connect

audit2allow

#============= sshd_t ==============
#!!!! This avc can be allowed using one of the these booleans:
#     authlogin_nsswitch_use_ldap, allow_ypbind

allow sshd_t ldap_port_t:tcp_socket name_connect;

audit2allow -R

#============= sshd_t ==============
#!!!! This avc can be allowed using one of the these booleans:
#     authlogin_nsswitch_use_ldap, allow_ypbind

allow sshd_t ldap_port_t:tcp_socket name_connect;



  
Actual results:
login fails

Expected results:
login succeeds

Additional info:
If I completely disable selinux the login succeeds.
Comment 1 Miroslav Grepl 2012-08-07 05:00:06 EDT
#============= sshd_t ==============
#!!!! This avc can be allowed using one of the these booleans:
#     authlogin_nsswitch_use_ldap, allow_ypbind


So you can allow it using

# setsebool -P authlogin_nsswitch_use_ldap 1

You can also read the sshd_man page for more details.
Comment 2 John Ellson 2012-08-07 09:32:16 EDT
Miroslav,

I think you missed the point.

I fully underderstand that you would use some setbool... to make it work in enforcing mode.    

The bug is that it doesn't work in *permissive* mode.
Comment 3 Petr Lautrbach 2012-08-07 10:07:11 EDT
Are there any relevant information in the /var/log/secure log? Did you boot straight into permissive mode or into enforcing and changed mode after you hadn't been able to login? 

The AVC you sent is not probably related to login problem.
Comment 4 John Ellson 2012-08-07 12:37:50 EDT
I think I had been in permissive mode for some time ... but I get a different result today.

I set selinux back to permissive mode.  Rebooted -- waited for relabeling to complete.   Restarted the directory server.   Opened  "tail -f"s on /var/log/messages and on /var/log/secure

This time the "ssh test@dir-p" login succeeded!   

I still get the same AVC:

   Aug  7 07:12:55 dir-p setroubleshoot: SELinux is preventing /usr/sbin/sshd from name_connect access on the tcp_socket . For complete SELinux messages. run sealert -l 053ccc66-9432-4e19-b156-7a18dee20f16


But this time it was correctly ineffective in permissive mode.

Looking into /var/log/secure for the entries corresponding to the above report:

Aug  6 09:45:46 dir-p sshd[1921]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=lweb1-vhost4.aldc.att.com  user=test
Aug  6 09:45:46 dir-p sshd[1921]: pam_ldap: error trying to bind as user "uid=test,ou=People,dc=aldc,dc=att,dc=com" (Invalid credentials)
Aug  6 09:45:48 dir-p sshd[1921]: Failed password for test from 130.8.46.114 port 53290 ssh2


I wonder if I was just entering the wrong passwd?   I tired by that point.

So, no bug, I guess, unless this report can be passed over to 389-ds for them to set up selinux correctly during installation?
Comment 5 Petr Lautrbach 2012-08-08 03:14:36 EDT
My guess would be that you had originally booted in the enforcing mode and 
something went wrong during initialization of a directory server.
Comment 6 Rich Megginson 2012-08-08 10:20:19 EDT
I don't understand - what component is supposed to do

setsebool -P authlogin_nsswitch_use_ldap 1

?  What does this allow?  Does it allow nss_ldap to make an ldap connection to an LDAP server?  If so, then this is not specific to 389 - what if you use openldap server or some other ldap server?
Comment 7 Nathan Kinder 2012-08-08 11:20:53 EDT
This is not directly 389 DS related, and I don't think that 389 DS should be making changes to the authlogin_nsswitch_use_ldap boolean.  This boolean is generic with regards to allowing nsswitch to connect to any port labelled as ldap_port_t on the system (be it 389 DS, OpenLDAP, or anything else listening on ports 389 or 636).

For 389 DS to run and handle client operations, it does not require any specific setting for authlogin_nsswitch_use_ldap.  That setting is used to confine nsswitch, not the ns-slapd process.
Comment 8 Tomas Mraz 2012-08-08 11:46:24 EDT
I think this can be done in authconfig now that we do the same for nis support.

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