Red Hat Bugzilla – Bug 430595
Problems with selinux and pam_mount
Last modified: 2008-11-26 12:37:14 EST
I'm seeing a lot of chatter from selinux - including avc denied - when I log in
as a user with a pam_mount'ed LUKS partition.
I found bug #426785, but I'm running selinux-policy-3.0.8-76.fc8 (and
pam_mount-0.18-2.fc8) and the mount itself seems to be successful - the home
directory is present. The home directory isn't unmounted when I log out - I
suspect that could be broken by selinux.
It looks similar to #426785, but for pam_mount in regard to sshd and login
rather than gdm.
I have pam_mount configured for: sshd, login, and gdm. I'll attach the relevant
log sections of audit.log, messages, and secure; the summary of which is:
gdm: 0 avc denied
sshd on login: 17 avc denied (1 avc denied it the user doesn't have an encrypted
sshd on logout: 3 avc denied
login on login: 1 avc denied
login on logout: 3 avc denied
I can provide more log information if needed (I wasn't which would be most useful).
This appears to be a regression from FC6.
Created attachment 293213 [details]
logs when logging in via gdm (no avc denied)
Created attachment 293214 [details]
logs: sshd login
Created attachment 293215 [details]
logs: sshd logout
Created attachment 293216 [details]
logs: sshd - user without pam_mounted crypted home
Created attachment 293217 [details]
logs: login user login
Created attachment 293218 [details]
logs: login user logout
Kevin thanks for reporting these. In Fedora 8 Login and sshd are confined,
which is why you are seeing these. I have done some investigation into the
pam_mount package and have seen some SELinux problems.
Labeling on /sbin/mount.crypt and /sbin/umount.crypt should be fixed in the next
You can temporarily change the context on these files by executing
chcon -t mount_exec_t /sbin/mount.crypt /sbin/umount/crypt
After you do this you can login in permissive mode to generate all of the AVC
messages. Then you can temporarily update you policy, by executing
# grep AVC /var/log/audit/audit.log | audit2allow -M mypolicy
# semodule -i mypolicy.pp
This should get you back to enforcing mode.
I am not sure what pmvarrun purpose is, if it creates files in /var/run/pam_mount
Then this directory should be owned by the package. /var/run/pam_mount should
be labeled pam_var_run_t, which will allow the login programs to use that
directory. I will change the SELinux policy to match that labeling, but the
directory should be part of the spec to get created with the right context on
Man page for pmvarrun states:
A separate program is needed so that /var/run/pam_mount/user may be
created with a pam_mount-specific security context (otherwise SELinux
policy will conflict with gdm, which also creates file in /var/run).
I have no idea what this means and I believe this is false.
Finally this package ships some policy files for strict policy which probably
should be removed and if additional privs are required they should be added to
the base package.
Labeling will be fixed in selinux-policy-3.0.8-82
(In reply to comment #7)
> I am not sure what pmvarrun purpose is, if it creates files in /var/run/pam_mount
> Then this directory should be owned by the package. /var/run/pam_mount should
> be labeled pam_var_run_t, which will allow the login programs to use that
> directory. I will change the SELinux policy to match that labeling, but the
> directory should be part of the spec to get created with the right context on
Is it reasonable to build a new pam_mount package that owns /var/run/pam_mount
for F8, even when there are no other changes? Do I need to run restorecon in %post?
> Man page for pmvarrun states:
> A separate program is needed so that /var/run/pam_mount/user may be
> created with a pam_mount-specific security context (otherwise SELinux
> policy will conflict with gdm, which also creates file in /var/run).
> I have no idea what this means and I believe this is false.
Pam_mount upstream interpreted this in
Using a separate programm makes sure that the context of the files in
/var/run/pam_mount are independent from the programm that loads pam_mount.so.
E.g. the context of gdm and ssh may differ, so that after a login via gdm, the
file in /var/run/pam_mount could not be updated when one logs in via ssh. But I
do not know, whether this is really an issue. Better you also read the original
mail from upstream.
> Finally this package ships some policy files for strict policy which probably
> should be removed and if additional privs are required they should be added to
> the base package.
I will try to test whether pam_mount works without its own policy files.
In RHEL5 and beyond, both gdm/sshd can write to directories labeled
pam_var_run_t. So if you create this directory in the rpm and we have labeling
setup, no additional programs should be necessary. RPM has a builtin
"restorecon" So no you do not need to run restorecon in the post install script.
All packages should own the directories they create, so package removal will
remove the directories. If you want pam_mount to work properly with selinux
then you will need to update the package.
(cross-posted to the pam-mount-user list; I don't know if that's a better place
to resolve this issue: http://tinyurl.com/yvsta4 )
I'm now running selinux-policy-3.0.8-84.fc8, but still see AVC denied messages
when logging in (and so using pam_mount).
I'm unclear as to whether the selinux-policy changes alone should have fixed
these errors, or whether pmvarrun and the superfluous policy files need to be
fixed? (as opposed to it just being nice for them to be fixed!)
On 2008-01-30 00:24, Jan Engelhardt wrote:
> >Btw. could you maybe adjust the autotools stuff in a way, that the
> >directory /var/run/pam_mount/ is created on install?
> Can do that. See changeset r407.
Ok, so /var/run/pam_mount will be created on install of pam_mount - great!
> pmvarrun.c -- Updates /var/run/pam_mount/<user>.
> But since pam_mount.so is also
> run from console and perhaps other login managers, there could be a
> conflict on /var/run/pam_mount files. At least that's what I would
> make of this message that I inherited from the previous maintainer
> and kept through the releases.
This is an incorrect assumption according to the Fedora selinux maintainer in
comment #9 (and in earlier comments on that bug)
Is there any reason why pmvarrun cannot be removed now? Or merged into the main
AFAICT, with the creation of /var/run/pam_mount by the package pmvarrun is
causing selinux problems, not solving them.
> Centos perhaps, because they clone redhat. selinux is too complex
> (read: nice shiny user interfaces missing) and I don't even bother
> turning on AppArmor. The policy files are likely out of date,
> obsolete or wrong.
CentOS is based on RHEL, which in turn is based on Fedora. From the Fedora
selinux maintainer in the RH bugzilla:
"Finally this package ships some policy files for strict policy which probably
should be removed and if additional privs are required they should be added to
the base package."
Could these policy files be removed from the pam_mount install?
If this will cause problems elsewhere than Fedora/RHEL/CentOS, would it be
possible for a configure option to ignore them?
What is the labeling on /var/run/pam_mount
ls -lZd /var/run/pam_mount
Does restorecon -R -v /var/run/pam_mount fix it.
(In reply to comment #11)
> What is the labeling on /var/run/pam_mount
> ls -lZd /var/run/pam_mount
drwxr-xr-x root root system_u:object_r:pam_var_run_t /var/run/pam_mount
> Does restorecon -R -v /var/run/pam_mount fix it.
Ok what AVC messages are you seeing now?
Created attachment 295953 [details]
audit.log for ssh login
I can only grab debug for ssh logins at the moment (I already tried restorecon
and login with gdm yesterday; I double checked restorecon today too).
Attached is audit.log for a ssh login to a user with two pam_mount directories,
one being the home directory.
You can allow this for now by executing
# audit2allow -M mypol -i /var/log/audit/audit.log
# semodule -i mypol.pp
Fixed in selinux-policy-3.0.8-89.fc8
>In RHEL5 and beyond, both gdm/sshd can write to directories
>labeled pam_var_run_t. So if you create this directory in
>the rpm and we have labeling setup, no additional programs
>should be necessary.
Well ok, but there is not just gdm or sshd. Anything that call the PAM stack in
"session" mode, including su/kdm/cron and possibly many others must be able to
write into it. Instead of giving policy files to them all (which is impossible,
given the uncountable number of user-written programs), pmvarrun is used to
switch to pam_var_run_t context and then operate on the files.
So far the theory from my --disabled-selinux standpoint. :-)
su/kdm/cron can also write there. Any login program or program that is confined
and uses pam.
pam_var_run_t is a file context not a process context. Processes get the access
not the files. If a process is using pam, is setuid and is confined, it will
need to have this permissions, and labeling will need to be setup correctly.
The AVCs are indeed gone with the latest F8 policy - thanks.
I've left the bug open as there seems to be a useful discussion regarding
pmvarrun; feel free to close the bug if this is best continued elsewhere.
This message is a reminder that Fedora 8 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 8. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora
'version' of '8'.
Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version prior to Fedora 8's end of life.
Bug Reporter: Thank you for reporting this issue and we are sorry that
we may not be able to fix it before Fedora 8 is end of life. If you
would still like to see this bug fixed and are able to reproduce it
against a later version of Fedora please change the 'version' of this
bug to the applicable version. If you are unable to change the version,
please add a comment here and someone will do it for you.
Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.
The process we are following is described here:
As this bug is in MODIFIED, Fedora believes that a fix has been committed that resolves the problem listed in this bug report.
If this is not the case, please re-open this report, noting the version of the package that you reproduced the bug against.
Thanks for the report!