Bug 671882

*** This bug has been marked as a duplicate of bug 671792 ***

oops wrong bug.

Did you setup some special pam module?

Hi Dan,

Just pam_ldap and pam_mkhomedir.

I've disabled pam_mkhomedir and tried again, and that's not it.

The AVCs are only triggered when I login with an ldap user, not with a local one.

It looks like unix_chkpwd is searching /usr/tmp for something.

I have no idea why unix_chkpwd would be needing sys_nice or setsched.

Do the pam guys have any idea?

That must be something in the nss_ldap or other module you use for the LDAP user lookups. What is in your /etc/nsswitch.conf and what module do you use for the user lookups in LDAP?

Here's my /etc/nsswitch.conf:

# Managed by puppet

passwd:     files ldap
shadow:     files ldap
group:      files ldap
hosts:      files dns

bootparams: files
ethers:     files
netmasks:   files
networks:   files
protocols:  files
rpc:        files
services:   files

netgroup:   ldap
publickey:  nisplus
automount:  files
aliases:    files

and this is /etc/nss_ldap.conf:

# Managed by puppet

base dc=tilaa,dc=nl
ldap_version 3
port 389
timelimit 10
bind_timelimit 20
pam_login_attribute uid
pam_lookup_policy yes
pam_min_uid 10000
pam_max_uid 20000
nss_initgroups_ignoreusers root,ldap,named,avahi,haldaemon,dbus,radvd,tomcat,radiusd,news,mailman,nscd,gdm,polkituser,postfix,apache
uri ldap://ldap.priv.tilaa.nl
ssl start_tls
tls_cacertfile /etc/openldap/cacerts/ca.pem
tls_ciphers TLSv1+RSA:!EXPORT:!NULL:!RC4:!MD5
pam_password exop

nss_base_passwd        ou=People,dc=tilaa,dc=nl?one
nss_base_shadow        ou=People,dc=tilaa,dc=nl?one
nss_base_group         ou=Groups,dc=tilaa,dc=nl?one

I suppose you use the nss_ldap module from nss-pam-ldapd - so I would expect the avcs coming from there. I'm ccing nalin who is the owner.

Hi Tomas,

I'm using nss_ldap-265-6.fc14.x86_64, not nss-pam-ldap.

The nslcd daemon doesn't read /etc/nss_ldap.conf, so I'd assume the original nss_ldap module is in play here.  Since we build nss_ldap using the shared libldap, and libldap uses NSS now, here's a backtrace from ldapsearch, which is also told to use StartTLS:

#0  0x00007ffff604d380 in open64 () from /lib64/libc.so.6
#1  0x00007ffff5fe891f in _IO_new_file_fopen () from /lib64/libc.so.6
#2  0x00007ffff5fdd2c6 in __fopen_internal () from /lib64/libc.so.6
#3  0x00007ffff5b12487 in RNG_FileUpdate (fileName=0x7ffff5b519f7 "/tmp", 
    limit=1000000) at unix_rand.c:1006
#4  0x00007ffff5b12689 in RNG_SystemInfoForRNG () at unix_rand.c:935
#5  0x00007ffff5b21e53 in rng_init () at drbg.c:425
#6  0x00007ffff6335dfa in PR_CallOnce (once=0x7ffff5d6ca34, 
    func=<value optimized out>)
    at ../../../mozilla/nsprpub/pr/src/misc/prinit.c:803
#7  0x00007ffff5b21ed7 in RNG_RNGInit () at drbg.c:469
#8  0x00007ffff5099c88 in nsc_CommonInitialize (pReserved=0x7fffffff95c0, 
    isFIPS=0) at pkcs11.c:2752
#9  0x00007ffff509a107 in NSC_Initialize (pReserved=0x7fffffff95c0)
    at pkcs11.c:2880
#10 0x00007ffff6bbb964 in secmod_ModuleInit (mod=0x6290a0, 
    reload=0x7fffffff9710, alreadyLoaded=0x7fffffff965c) at pk11load.c:252
#11 0x00007ffff6bbbfe8 in secmod_LoadPKCS11Module (mod=0x6290a0, 
    oldModule=0x7fffffff9710) at pk11load.c:492
#12 0x00007ffff6bc8e65 in SECMOD_LoadModule (
    modulespec=0x628d30 "library= name=\"NSS Internal PKCS #11 Module\" parameters=\"configdir='' certPrefix='' keyPrefix='' secmod='secmod.db' flags=readOnly,noCertDB,noModDB updatedir='' updateCertPrefix='' updateKeyPrefix='' "..., 
    parent=0x627d60, recurse=1) at pk11pars.c:1108
#13 0x00007ffff6bc8ff0 in SECMOD_LoadModule (
    modulespec=0x626a40 "name=\"NSS Internal Module\" parameters=\"configdir='' certPrefix='' keyPrefix='' secmod='secmod.db' flags=readOnly,noCertDB,noModDB updatedir='' updateCertPrefix='' updateKeyPrefix='' updateid='' update"..., 
    parent=0x0, recurse=1) at pk11pars.c:1143
#14 0x00007ffff6b97482 in nss_InitModules (isContextInit=1, optimizeSpace=0, 
    forceOpen=0, noModDB=1, noCertDB=1, readOnly=1, 
    pwRequired=<value optimized out>, configStrings=0x626880 " minPS=0", 
    configName=0x7ffff6c7b3c8 "NSS Internal Module", 
    updateName=0x7ffff6c7b917 "", updateID=0x7ffff6c7b917 "", 
    updKeyPrefix=0x7ffff6c7b917 "", 
    updCertPrefix=0x6269c0 "\230i\375\367\377\177", updateDir=0x6269a0 "", 
    secmodName=0x7ffff7bd20af "secmod.db", keyPrefix=<value optimized out>, 
    certPrefix=<value optimized out>, configdir=0x7ffff7bd2082 "")
    at nssinit.c:461
#15 nss_Init (configdir=0x7ffff7bd2082 "", certPrefix=<value optimized out>, 
    keyPrefix=<value optimized out>, secmodName=0x7ffff7bd20af "secmod.db", 
    updateDir=0x6269a0 "", updCertPrefix=0x6269c0 "\230i\375\367\377\177", 
    updKeyPrefix=0x7ffff6c7b917 "", updateID=0x7ffff6c7b917 "", 
    updateName=0x7ffff6c7b917 "", initContextPtr=0x7fffffff9938, 
    initParams=0x7fffffff9980, readOnly=1, noCertDB=1, noModDB=1, forceOpen=0, 
    noRootInit=1, optimizeSpace=0, noSingleThreadedModules=0, 
    allowAlreadyInitializedModules=0, dontFinalizeModules=0) at nssinit.c:620
#16 0x00007ffff6b97d45 in NSS_InitContext (configdir=<value optimized out>, 
    certPrefix=<value optimized out>, keyPrefix=<value optimized out>, 
    secmodName=<value optimized out>, initParams=<value optimized out>, 
    flags=<value optimized out>) at nssinit.c:800
#17 0x00007ffff7bc9274 in tlsm_deferred_init (arg=0x626170)
    at ../../../libraries/libldap/tls_m.c:1573
#18 tlsm_deferred_ctx_init (arg=0x626170)
    at ../../../libraries/libldap/tls_m.c:1935
#19 0x00007ffff6335ef5 in PR_CallOnceWithArg (once=0x6261a8, 
    func=<value optimized out>, arg=<value optimized out>)
    at ../../../mozilla/nsprpub/pr/src/misc/prinit.c:832
#20 0x00007ffff7bc6a56 in tlsm_session_new (ctx=0x626170, is_server=0)
    at ../../../libraries/libldap/tls_m.c:2281
#21 0x00007ffff7bc42c4 in alloc_handle (ctx_arg=<value optimized out>, 
    is_server=<value optimized out>) at ../../../libraries/libldap/tls2.c:296
#22 0x00007ffff7bc443e in ldap_int_tls_connect (ld=0x6160b0, 
    conn=<value optimized out>) at ../../../libraries/libldap/tls2.c:341
#23 0x00007ffff7bc4e4c in ldap_int_tls_start (ld=0x6160b0, conn=0x6162b0, 
    srv=<value optimized out>) at ../../../libraries/libldap/tls2.c:833
#24 0x00007ffff7bc51ce in ldap_start_tls_s (ld=0x6160b0, serverctrls=0x0, 
    clientctrls=0x0) at ../../../libraries/libldap/tls2.c:939
#25 0x0000000000408849 in tool_conn_setup (dont=<value optimized out>, 
    private_setup=0x404a30 <private_conn_setup>)
    at ../../../clients/tools/common.c:1290
#26 0x0000000000406c81 in main (argc=<value optimized out>, 
    argv=<value optimized out>) at ../../../clients/tools/ldapsearch.c:900

So either LDAP clients all need to be able to read /tmp this way, or it's a bug in OpenLDAP and/or NSS.

Is there any extra information I can provide?

Elio, are the reads of /tmp by nss essential? If not perhaps these AVCs can be dontaudited?

They seem to be essential as they are part of the PRNG seeding. Looking at
http://mxr.mozilla.org/security/source/security/nss/lib/freebl/unix_rand.c#854
shows that /tmp is one the files that RNG_SystemInfoForRNG reads to gather up system specific information to help seed the state of the global random number generator. RNG_SystemInfoForRNG is called when NSS loads and initializes a cryptographic module.

So does this mean /sbin/unix_chkpwd is going to try to read any file in /tmp?

No, as far as I can tell from the code, it won't read any other files inside /tmp.

So it literally wants to read the /tmp directory file. (Actually I think it is reading /usr/tmp -> /var/tmp

Miroslav can you add

files_read_usr_symlinks(chkpwd_t)
files_list_tmp(chkpwd_t)

To F13/F14/RHEL6