Bug 430595 - Problems with selinux and pam_mount
Problems with selinux and pam_mount
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: pam_mount (Show other bugs)
8
All Linux
low Severity medium
: ---
: ---
Assigned To: Till Maas
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-01-28 17:36 EST by Kevin R. Page
Modified: 2008-11-26 12:37 EST (History)
3 users (show)

See Also:
Fixed In Version: F8
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-11-26 12:37:14 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
logs when logging in via gdm (no avc denied) (2.16 KB, text/plain)
2008-01-28 17:36 EST, Kevin R. Page
no flags Details
logs: sshd login (16.39 KB, text/plain)
2008-01-28 17:38 EST, Kevin R. Page
no flags Details
logs: sshd logout (3.09 KB, text/plain)
2008-01-28 17:38 EST, Kevin R. Page
no flags Details
logs: sshd - user without pam_mounted crypted home (2.84 KB, text/plain)
2008-01-28 17:39 EST, Kevin R. Page
no flags Details
logs: login user login (3.04 KB, text/plain)
2008-01-28 17:40 EST, Kevin R. Page
no flags Details
logs: login user logout (2.87 KB, text/plain)
2008-01-28 17:40 EST, Kevin R. Page
no flags Details
audit.log for ssh login (10.44 KB, text/plain)
2008-02-26 11:56 EST, Kevin R. Page
no flags Details

  None (edit)
Description Kevin R. Page 2008-01-28 17:36:50 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
home)
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.
Comment 1 Kevin R. Page 2008-01-28 17:36:51 EST
Created attachment 293213 [details]
logs when logging in via gdm (no avc denied)
Comment 2 Kevin R. Page 2008-01-28 17:38:14 EST
Created attachment 293214 [details]
logs: sshd login
Comment 3 Kevin R. Page 2008-01-28 17:38:43 EST
Created attachment 293215 [details]
logs: sshd logout
Comment 4 Kevin R. Page 2008-01-28 17:39:35 EST
Created attachment 293216 [details]
logs: sshd - user without pam_mounted crypted home
Comment 5 Kevin R. Page 2008-01-28 17:40:16 EST
Created attachment 293217 [details]
logs: login user login
Comment 6 Kevin R. Page 2008-01-28 17:40:41 EST
Created attachment 293218 [details]
logs: login user logout
Comment 7 Daniel Walsh 2008-01-29 09:24:33 EST
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
release.

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.


pam_mount maintainers:

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
install.


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




Comment 8 Till Maas 2008-01-29 19:41:24 EST
(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
> install.

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 
http://sourceforge.net/mailarchive/message.php?msg_name=Pine.LNX.4.64.0801300114250.14907%40fbirervta.pbzchgretzou.qr
the following:

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.
Comment 9 Daniel Walsh 2008-01-30 11:08:38 EST
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.
Comment 10 Kevin R. Page 2008-02-25 06:09:56 EST
(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>.
[snip]
> 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
pam_mount?

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?
Comment 11 Daniel Walsh 2008-02-26 10:07:55 EST
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.
Comment 12 Kevin R. Page 2008-02-26 11:04:35 EST
(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.

Sorry, no.
Comment 13 Daniel Walsh 2008-02-26 11:15:50 EST
Ok what AVC messages are you seeing now?
Comment 14 Kevin R. Page 2008-02-26 11:56:27 EST
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.
Comment 15 Daniel Walsh 2008-02-26 13:22:18 EST
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
Comment 16 Jan Engelhardt 2008-04-04 18:50:49 EDT
>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. :-)
Comment 17 Daniel Walsh 2008-04-06 07:02:17 EDT
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.
Comment 18 Kevin R. Page 2008-04-09 20:14:49 EDT
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.
Comment 19 Bug Zapper 2008-11-26 04:37:06 EST
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: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 20 Jon Stanley 2008-11-26 12:37:14 EST
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!

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