oddjob_mkhomedir or mkhomedir

Latest response

It appears that there has been a conscious decision made within Red Hat to move away from pam_mkhomedir in favour of pam_oddjob_mkhomedir, but I haven't yet been able to find a written reference to this.

I came to this by identifying a bug in a configuration with pam_mkhomedir SELinux types being incorrectly set on newly created home directories (home_root_t not user_home_dir_t). It would appear several others have found this bug, and it has been filed (in one instance) at the following URL.

https://bugzilla.redhat.com/show_bug.cgi?id=903880

I was quite surprised by the response "Please use oddjob_mkhomedir" and the closure status "CLOSED NOTABUG" to what appears to be a valid bug report. Is there a reason the SELinux policy for pam_mkhomedir isn't being fixed? pam_mkhomedir is shipped as part of the PAM package, so I would assume it is supported by Red Hat and should be fixed? Is there another issue that would lead to pam_mkhomedir being deprecated that someone from Red Hat can explain?

Interestingly the same bug was raised here, and apparently resolved and closed as Errata:
https://bugzilla.redhat.com/show_bug.cgi?id=863132

Unfortunately, to provide the oddjob_mkhomedir capability you need two additional services running
oddjobd - to execute the jobs
messagebus - to message the oddjob service

So am I right in thinking that this requires two extra services running and three extra packages installed to work around an SELinux bug in a module that ships with the default PAM configuration?

PS
Log in to join the conversation

Responses

james.radtke@siriusxm.com's picture Guru 6863 points
2 June 2014 2:08 PM

Good question.
I have had issues with the "oddjob" approach and had to fall back to using pam module instead. Unfortunately we were not terribly diligent identifying exactly what the issue was, we instead just "fixed" the issue and moved on...

from /etc/pam.d/system-auth-ac
session     optional      pam_mkhomedir.so

The problem I see, however, is if you run
authconfig --enablemkhomedir --update
I believe it will attempt to update your configuration to utilize the "oddjob" way.

If I had to provide a single reason why it doesn't work as expected in our environment, I would have to declare it is because we try to embrace a bit of the new method while clinging to some legacy methods and they collide.

PS Guru 6494 points
2 June 2014 11:41 PM

I pulled apart authconfig when looking at this yesterday because I was frustrated with its inconsistency.

If you have oddjob installed it will configure pam to use pam_oddjob_mkhomedir, if it can't find oddjob it configures pam_mkhomedir.

From authinfo.py line ~3271

# use oddjob_mkhomedir if available
if name == "mkhomedir" and os.access("%s/pam_%s.so"
        % (AUTH_MODULE_DIR, "oddjob_mkhomedir"), os.X_OK):
        name = "oddjob_mkhomedir"

So the same command can generate two different configurations and the tool doesn't communicate what it is doing. Essentially, you can end up with two different configurations with one of them (oddjob) requiring additional dependencies.

So by design authconfig prefers oddjob (overwrites the mkhomedir module if it finds oddjob), and 'falls back' to what appears to be a deprecated pam_mkhomedir.

I also noticed in this AD integration document (section 5.9 pg. 24)
https://access.redhat.com/site/node/216933/40/0
The following statement regarding oddjob and SELinux:

5.9 Install oddjob-mkhomedir
Install the oddjob-mkhomedir package to ensure that user home directories are created with the proper SELinux file and directory contexts:

So the issue with SELinux contexts looks like a known problem.

PS Guru 6494 points
3 June 2014 11:43 PM

I have spent some more time looking at this to try and provide an explanation.

From the looks of it, the pam_mkhomedir source has no reference to SELinux or SELinux capability baked in, so it isn't that it is setting the context incorrectly, it isn't setting it at all (assuming it ends up as root based on who pam_mkhomedir is run as).

Oddjob source includes SELinux capabilities and the file creation context is set before the files and directories are created. Interestingly as well, oddjob has the capability for the creation to run using the standard user's privileges (calls mkmyhomedir) or root (calls mkhomedirfor) which suggests that it also provides the benefit of creating the directory structure without requiring root privileges.

So my guess for why pam_mkhomedir isn't being 'fixed' is because of the requirement to migrate all the SELinux libraries over to provide SELinux capabilities to the module and they are moving away from the need to switch to root.

Hope that guess/explanation helps until we hear something more formal from Red Hat!

Would also be interested to hear what the future direction of oddjob is. Are they planning to use it for all (most) process privilege escalation tasks?

rhn-engineering-dwalsh's picture Red Hat Pro 435 points
4 June 2014 1:50 PM

The reason we have pam_oddjob_mkhomedir is to separate out the ability to create a homedir and all of the content from the login programs.

With pam_mkhomedir login programs have to be allowed to create Your homedir, but if you setup /etc/skel then it also needs to be able to create any content in your home dir.

We in the SELinux world want to control what login programs can do. So we want to separate this abiltity to create home directory content into a separate priv daemon on the hosts, which the login programs can request to create the content. This means that from an SELinux point of view we can stop login programs like sshd from reading random content in your homedir. Why is this important? Over the years it has been shown that login programs have had bugs that led to information leakage without the users every being able to login to a system.

We probably should document this better then we do inside of the pam_mkhomedir documentation. I would suggest we open a bug about this.

PS Guru 6494 points
4 June 2014 10:46 PM

Thanks for the explanation Daniel, makes perfect sense.

Do you know what the general direction/plan is with oddjob? Is the plan to replace some of the existing SUID capabilities of the OS? Do you have examples of where else it is/will be used? By the looks, the only module that ships in RHEL6 is mkhomedir.

Also, do you know what the future is for pam_mkhomedir? Do Red Hat plan to remove it when they package PAM from upstream in future?

Thanks again.

rhn-engineering-dwalsh's picture Red Hat Pro 435 points
5 June 2014 12:42 PM

BTW I blogged on this yesterday.

https://danwalsh.livejournal.com/69837.html

oddjob is used by a couple of other tools including OpenShift, but for the most part, DBUS has sort of usurped alot of its functionality. I guess pam_oddjob_mkhomedir could be rewritten as a standard dbus service that talks to systemd and starts the mkhomedir process on demand.

I don't really know what the plans are for the packagers of pam.

R. Hinton's picture Guru 6827 points
5 June 2014 7:14 PM

Thanks for this info Daniel, appreciate it. Pixel, thanks for bringing this up.

PS Guru 6494 points
3 July 2014 2:12 AM

Those using oddjob_mkhomedir be warned, (atow) it creates home directories using the mask of 0002 which gives all users read on user home directories.

This is defined in

/etc/oddjobd.conf.d/oddjobd-mkhomedir.conf

This issue was raised in the following BZ:
https://bugzilla.redhat.com/show_bug.cgi?id=995097

This update/fix hasn't made its way into the RHEL6.x releases yet.

PS Guru 6494 points
9 July 2014 1:59 AM

Another issue to note is that having the oddjobd daemon running is a finding in the DISA RHEL 6 STIG (v1r3).
http://web.nvd.nist.gov/view/ncp/repository/checklistDetail?id=438

Although it says it 'may provide necessary functionality', the suggestion that it has traditionally been used for escalation is worth keeping in mind.

Group ID (Vulid): V-38646
Group Title: SRG-OS-000096
Rule ID: SV-50447r2_rule
Severity: CAT III
Rule Version (STIG-ID): RHEL-06-000266
Rule Title: The oddjobd service must not be running.

Vulnerability Discussion: The "oddjobd" service may provide necessary functionality in some environments but it can be disabled if it is not needed. Execution of tasks by privileged programs, on behalf of unprivileged ones, has traditionally been a source of privilege escalation security issues.

va Newbie 11 points
3 December 2015 6:12 PM

We created a workaround that we are testing now as we have the STIG applied(V1R9) which means no oddjob service

Added the following below pam_mkhomedir.so in /etc/pam.d/password-auth

session     optional      pam_exec.so debug log=/var/log/pam_exec_rconhomedir.log /usr/local/bin/restoreconhome.sh

Created /usr/local/bin/restoreconhome.sh

#!/bin/bash
#
# Script that will be run by pam_exec to ensure that
# homedirs have correct selinux context
# This script uses getent as the home dir may be provided via winbind or other
# external mechanism

cmd="/sbin/restorecon -R $(getent passwd ${PAM_USER} | awk -F':' '{print $6}')"
echo $cmd
$cmd

Seems like -R might not be wanted as this will run every login, but it works for us now. I'm not sure how /etc/skel gets copied, but if the files are copied in the same way then -R is needed as the files would have the wrong context as well(right?)

PS Guru 6494 points
7 December 2015 2:12 AM

Nice workaround, thanks for posting it.

DW Active Contributor 248 points
5 July 2018 12:11 PM

The STIG says that oddjobd should not be running. It does not say anything about whether or not it should be installed/removed. Where I am working, RHEL 6 servers have

session optional pam_oddjob_mkhomedir.so umask=0077

in multiple /etc/pam.d files, with oddjobd installed but disabled and not running. STIG scans show no findings for oddjobd

DW Active Contributor 248 points
30 July 2018 6:41 PM

CORRECTION !! No STIG findings, but no home directory will be created UNLESS oddjobd is running.

And running "authconfig --updateall" restarts/reenables it as well !

DW Active Contributor 248 points
30 July 2018 6:43 PM

I will give vallardt's workaround a try.

DW Active Contributor 248 points
2 August 2018 1:14 PM

Thank you, vallardt. Your hack works great.

Close

Welcome! Check out the Getting Started with Red Hat page for quick tours and guides for common tasks.