Bug 167873 - cron jobs fail to run after fiddling around in pam.d
cron jobs fail to run after fiddling around in pam.d
Product: Fedora
Classification: Fedora
Component: vixie-cron (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Marcela Mašláňová
Brock Organ
: FutureFeature
Depends On:
  Show dependency treegraph
Reported: 2005-09-09 00:18 EDT by Paul Johnson
Modified: 2007-11-30 17:11 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-09-08 09:11:02 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Paul Johnson 2005-09-09 00:18:47 EDT
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.

# 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:

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

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.
Comment 1 Jason Vas Dias 2005-09-14 19:22:29 EDT
It sounds like you've installed the pam_mount module 
( from http://flyn.org/projects/pam_mount/index.html
) , which is NOT shipped by default with Fedora.

I have downloaded pam_mount-0.9.9 from flyn.org, and tried playing around with it.

The purpose of this module seems to be to mount user's home directories if they
are not mounted when the user first authenticates with a PAM aware application
that has pam_mount in its 'auth' service stack.

It supports "mount" operations that may require userid and password options,
such as those for SMB, NCP, and encrypted-FS, and CLAIMS to support mounts
for filesystems that do not require any authentication mount options, such
as NFS .

But pam_mount REQUIRES that the PAM_AUTHTOK PAM item (the user password) be set
when it's pam_sm_authenticate ('auth' service handler) function is called, even
if its configuration file contains no volumes that require authentication
options (eg. a single NFS volume) - otherwise it will emit the message
    pam_mount: error trying to retrieve authtok from auth code
in its pam_sm_open_session ('session' service handler), not attempt the mount,
and fail the open session service call. 

There is possibly room for improvement in pam_mount here: if it sees that 
no password is required for a user's mounts in its configuration file, it
should not complain and give up if it cannot obtain the user's password
from the PAM_AUTHTOK item.

By default, pam_unix and most other default PAM 'password' service handlers
do not set the PAM_AUTHTOK item to the user's password in pam_sm_authenticate. 

The pam_ldap module does, however, which is why it is able to be used for 
pam_mount .

crond, like other system daemons that run as root, never has access to the 
user's password, and must rely on the pam_rootok module to authenticate
as the users on behalf of which it runs jobs. pam_rootok never even looks up
the user's password, let alone sets PAM_AUTHTOK .

So any system services, such as crond and atd, that need to acquire the
credentials of other users in order to perform actions on their behalf,
but which do not interact with users, cannot use modules such as pam_mount 
at the moment.

It is better security NOT to have the PAM_AUTHTOK pam item set to the 
user's password in all processes, as it is then easier for attackers
to dig passwords out of running process' memory.

A better solution for you, rather than modifying the system-auth pam
configuration to pam_mount, would be to only modify the pam configuration
of the applications that you use to login with, eg. gdm / xdm / kde, sshd,
login, to use ldap and pam_mount.

Then your home directory would be mounted when you login, and you would not
need to modify the system-auth configuration and the configurations which
use system-auth such as crond and atd .

While I've not had time to analyse pam_mount in detail, it is probably more
secure to restrict its use to those services that require it, rather than
have it in the system-auth .

There is perhaps a need for crond and atd to be able to use pam modules that
require the user's password , and do be able to do things like mount their
home directories when the job is running . 

So I will consider this as a request to enhance cron to provide a per-job
option that, once it had authenticated as the user with pam_rootok and gained
the user's credentials, would make cron look up the users's password, set 
PAM_AUTHTOK to it, and then open the pam session - that would allow modules
such as pam_mount to be used for the crond session service .

This bug is hence NOT a security vulnerability, but an enhancement request.
Comment 2 Marcela Mašláňová 2006-09-08 09:11:02 EDT
I agree with previous maintainer. I close it.

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