Bug 167873

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.10) Gecko/20050720 Fedora/1.0.6-1.1.fc4 Firefox/1.0.6

Description of problem:
My pam stack was modified to allow LDAP authentication and pam_mount of a network share.  I made the changes to /etc/pam.d/system-auth first with system-config-authentication, and then manually added the part for pam_mount.  I just found out that that the changes make cron fail to start because cron is now "pam aware."  I call this a security issue because users (like me) will assume that the  yum automatic update would work, but it fails.

I have been wrestling so much with the authentication that I did not notice the side effect on cron.  When I su to root, it works, but there's always a message to /var/log/secure because root is not found in the LDAP server.  Authentication falls back to the local files and succeeds, and so I figured all was well. But, it works only after failing to authenticate against the LDAP server, since there's no root user there. "su" goes through OK, but I guess the cron-pam thing is more fragile.

Here's the indication from /var/log/secure, every time when cron tries to run

Sep  1 18:01:01 pols11 crond[18092]: pam_mount: error trying to retrieve authtok from auth code
Sep  1 19:01:01 pols11 crond[18107]: pam_mount: error trying to retrieve authtok from auth code
Sep  1 20:01:01 pols11 crond[18122]: pam_mount: error trying to retrieve authtok from auth code
Sep  1 21:01:01 pols11 crond[18137]: pam_mount: error trying to retrieve authtok from auth code


Here's my modified system-auth. It has all this special mustard in there because 1) authenticate against a Novell LDAP server, 2) pam_mount shares for users found there, and 3) create home directories for users on the local machine who authenticate but do not have home directories.

#%PAM-1.0
# This file is auto-generated.
# User changes will be destroyed the next time authconfig is run.
account    sufficient     /lib/security/$ISA/pam_ldap.so
auth        required       /lib/security/$ISA/pam_mount.so
auth        required      /lib/security/$ISA/pam_env.so
auth        sufficient    /lib/security/$ISA/pam_ldap.so use_first_pass

auth        sufficient    /lib/security/$ISA/pam_unix.so likeauth nullok use_first_pass

auth        required      /lib/security/$ISA/pam_deny.so

account     required      /lib/security/$ISA/pam_unix.so broken_shadow
account     sufficient    /lib/security/$ISA/pam_localuser.so
account     sufficient    /lib/security/$ISA/pam_succeed_if.so uid < 100 quiet
account     [default=bad success=ok user_unknown=ignore] /lib/security/$ISA/pam_ldap.so
account     required      /lib/security/$ISA/pam_permit.so

password    requisite     /lib/security/$ISA/pam_cracklib.so retry=3
password    sufficient    /lib/security/$ISA/pam_unix.so nullok use_authtok md5 shadow
password    sufficient    /lib/security/$ISA/pam_ldap.so use_authtok
password    required      /lib/security/$ISA/pam_deny.so

session    required       /lib/security/$ISA/pam_mkhomedir.so skel=/etc/skel umask=0002
session    optional       /lib/security/$ISA/pam_mount.so
session     required      /lib/security/$ISA/pam_limits.so
session     required      /lib/security/$ISA/pam_unix.so
session     optional      /lib/security/$ISA/pam_ldap.so

I do not know which particular thing makes the cron system to fail.

I have fixed this by taking the crond pam file and cutting out the parts it grabs from system-auth, and instead of those parts, cram in the equivalent parts from the system-auth that existed before I did LDAP. See what I mean?

Replace this old crond file:
# /etc/pam.d/crond
#
# The PAM configuration file for the cron daemon
#
#
auth       sufficient pam_rootok.so
auth       required   pam_stack.so service=system-auth
auth       required   pam_env.so
account    required   pam_stack.so service=system-auth
account    required   pam_access.so
session    required   pam_stack.so service=system-auth
session    required   pam_loginuid.so
# To enable PAM user limits for cron jobs,
# configure /etc/security/limits.conf and
# uncomment this line:
# session  required   pam_limits.so
#


Can it do any damage to put in the original system-auth lines? Am I insecure?

# proposed /etc/pam.d/crond
#
# The PAM configuration file for the cron daemon
#
#
auth       sufficient pam_rootok.so
#paste 3 auth lines from original system-auth
auth        required      /lib/security/$ISA/pam_env.so
auth        sufficient    /lib/security/$ISA/pam_unix.so likeauth nullok
auth        required      /lib/security/$ISA/pam_deny.so

auth       required   pam_env.so

#paste 3 account lines from original system auth
account     required      /lib/security/$ISA/pam_unix.so
account     sufficient    /lib/security/$ISA/pam_succeed_if.so uid < 100 quiet
account     required      /lib/security/$ISA/pam_permit.so

account    required   pam_access.so
#paste 2 session lines from original system auth
session     required      /lib/security/$ISA/pam_limits.so
session     required      /lib/security/$ISA/pam_unix.so


--------------------------------

I'm testing that now and it SEEMS to be working, but I have no idea what secondary effects it might be causing.  What dangers lurk?



Version-Release number of selected component (if applicable):
vixie-cron-4.1-36.FC4, pam-0.79-9.5, system-config-authentication

How reproducible:
Always

Steps to Reproduce:
1. Change /etc/pam.d/system-auth
2. 
3.
  

Actual Results:  Cron jobs fail to run after that

Expected Results:  I wish the cron system could be more agile, I guess.

Additional info:

I'm claiming this is security, the same way the rhn-update bug is a security bug. It induces a "false sense of security" when the updater fails because of this problem.