Bug 595508 - pam_mount 2.x requires cryptsetup privileges
Summary: pam_mount 2.x requires cryptsetup privileges
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: selinux-policy-targeted
Version: 14
Hardware: All
OS: Linux
low
low
Target Milestone: ---
Assignee: Miroslav Grepl
QA Contact: Ben Levenson
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2010-05-24 20:26 UTC by Tomáš Trnka
Modified: 2011-10-30 00:33 UTC (History)
3 users (show)

Fixed In Version: selinux-policy-3.9.7-46.fc14
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2011-10-30 00:33:06 UTC
Type: ---


Attachments (Terms of Use)

Description Tomáš Trnka 2010-05-24 20:26:59 UTC
Description of problem:
pam_mount versions from 2.0 onwards do not rely on the cryptsetup binary anymore, they use libcryptsetup directly. That means /sbin/mount.crypt needs the necessary block device privileges to work.

Version-Release number of selected component (if applicable):
pam_mount-2.2-1.fc13 (The update got unpushed because version 2.2 is a brown-paper-bag one due to an unrelated bug, but I suppose 2.3 package will be there soon)
So this is more of a feature request because the SELinux bits have to be already there when the pam_mount update lands, otherwise it won't work at all in Enforcing.

Steps to Reproduce:
Install the new pam_mount onto an Enforcing machine and watch...
  
Actual results:
All hell breaks loose.

Expected results:
Everything works as it used to.

Additional info:
Since I got the update installed before it got unpushed again, I've had to fix this with a tiny local policy module:

require {
        type mount_t;
        type udev_tbl_t;
        type device_t;
        type fixed_disk_device_t;
        class file { getattr read open relabelfrom relabelto };
}

dontaudit mount_t udev_tbl_t : file { getattr read open };

dev_manage_generic_blk_files( mount_t )
dontaudit mount_t device_t : file relabelfrom;
dontaudit mount_t fixed_disk_device_t : file relabelto;

The udev_tbl_t dontaudit is due to mount.crypt touching /dev/.udev/queue.bin (I haven't examined the code thoroughly to find out whether this isn't done on purpose, perhaps it should be an "allow", but the dontaudit works oK).

There's another problem and that's /etc/cmtab (where mount.crypt records its runtime info on mounted volumes) being moved to /var/run/cmtab. I've hacked this around by setting /var/run/cmtab to etc_runtime_t (working, but ugly), because I somehow don't want mount_t to be allowed to write any generic /var/run file. I think this will need a proper new type for the file (or maybe not and I'm just paranoid).

Comment 1 Till Maas 2010-05-24 20:42:11 UTC
FYI, the location of cmtab is why I did not yet push 2.3. This is currently discussed in the upstream bugtracker:

https://sourceforge.net/tracker/index.php?func=detail&aid=3004180&group_id=41452&
atid=430593

Comment 2 Daniel Walsh 2010-05-24 21:31:44 UTC
If you change the label on /sbin/mount.crypt to the lvm_exec_t does everything work.

chcon -t lvm_exec_t /sbin/mount.crypt

Comment 3 Tomáš Trnka 2010-05-24 21:55:34 UTC
That was the first solution I've tried...
However, it's quite suboptimal, IMHO, since it requires adding at least:

lvm_domtrans(local_login_t)
lvm_domtrans(xdm_t)

And this is either:
1) Working, but quite a security hole, when the unconfined.pp package is active and lvm_t is unconfined
or else
2) Not working due to lvm_t being unable to e.g. stat the mountpoint, as in:
type=AVC msg=audit(1274299341.160:370): avc:  denied  { getattr } for  pid=5192 comm="readlink" path="/home" dev=sda3 ino=8193 scontext=system_u:system_r:lvm_t:s0-s0:c0.c1023 tcontext=system_u:object_r:home_root_t:s0 tclass=dir

Comment 4 Daniel Walsh 2010-05-25 14:55:41 UTC
Why do you need 

lvm_domtrans(local_login_t)
lvm_domtrans(xdm_t)

I would figure you domtrans from 

local_login_t -> mount_t -> lvm_t

Doesn't the login program execute mount first?  


I don't mind allowing lvm to look at the home_root_t.

Comment 5 Tomáš Trnka 2010-05-25 16:31:28 UTC
(In reply to comment #4)
> Why do you need 
> 
> lvm_domtrans(local_login_t)
> lvm_domtrans(xdm_t)

I've added this since otherwise mount.crypt (lvm_exec_t) ran in local_login_t. Is there anything else that would have kept it from transitioning?

> I would figure you domtrans from 
> 
> local_login_t -> mount_t -> lvm_t

I don't think so, but I'm no SELinux expert...

> Doesn't the login program execute mount first?  

It doesn't, it calls /sbin/mount.crypt directly but I think this can be overriden in the pam_mount config file. I haven't tried that yet.

> I don't mind allowing lvm to look at the home_root_t.    

oK, I'll try to get this (mount.crypt in lvm_t called through mount_t) working tomorrow (sorry, no time today).

Comment 6 Tomáš Trnka 2010-05-26 22:32:28 UTC
So I've spent the evening playing with this and it works!

To make pam_mount call mount.crypt via mount (so as to get the necessary transitions), all that is needed are these two config elements (the exact syntax of the mount options is just stolen from pam_mount's rdconf1.c)

<cryptmount>mount -t crypt "%(if %(CIPHER),-ocipher=%(CIPHER))" "%(if %(FSKEYCIPHER),-ofsk_cipher=%(FSKEYCIPHER))" "%(if %(FSKEYHASH),-ofsk_hash=%(FSKEYHASH))" "%(if %(FSKEYPATH),-okeyfile=%(FSKEYPATH))" "%(if %(OPTIONS),-o%(OPTIONS))" %(VOLUME) %(MNTPT)</cryptmount>
<cryptumount>umount %(MNTPT)</cryptumount>

(I suppose this can be discussed with the upstream maintainer and perhaps made the default. Otherwise, it's a two-line patch to change the defaults if we want that.)

Now, with this and /sbin/mount.crypt set to lvm_exec_t, these rules are needed:

require {
        type local_login_t, xdm_t;
        type lvm_t;
        type home_root_t, user_home_dir_t;
        class fifo_file { write read ioctl getattr };
        class dir { getattr search };
        class file { write read };
}

allow lvm_t home_root_t:dir { getattr search };
allow lvm_t user_home_dir_t:dir getattr;

This is incomplete and needs to be replaced by something like "allow lvm_t to search any directory (mountpoint)" (it's just that I'm mounting the volume in question as my homedir).

allow lvm_t local_login_t:fifo_file { write read ioctl getattr };
allow lvm_t xdm_t:fifo_file { write read ioctl getattr };

Necessary for the passphrase to get passed down to mount.crypt.

mount_domtrans(lvm_t)

files_rw_etc_runtime_files(lvm_t)

mount.crypt needs to update /etc/mtab.  Apart from that, I'm still having /var/run/cmtab etc_runtime_t - in case it's going to return to /etc, no more rules are needed. If not, local_login_t/xdm_t/whatever_else_could_use_pam_mount_t must be able to read that file (local_login_t currently can't read var_run_t) and lvm_t must be able to create&rw it.

Comment 7 Bug Zapper 2011-06-02 13:37:24 UTC
This message is a reminder that Fedora 13 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 13.  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 '13'.

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 13'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 13 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 8 Tomáš Trnka 2011-06-06 15:58:05 UTC
This is still valid for F14 (pam_mount-2.5-1.fc14.x86_64, selinux-policy-targeted-3.9.7-42.fc14.noarch) with the unconfined policy module disabled (otherwise lvm_t is unconfined and everything works okay). Confined lvm_t still needs the allows mentioned above.

Comment 9 Daniel Walsh 2011-06-10 15:55:59 UTC
I have added a commit to Rawhide to allow this access.


375541b1fc18fa285068d3c9c4068089d63604f9

Probably should be back ported to F14 and F15.

Comment 10 Miroslav Grepl 2011-06-13 10:25:20 UTC
Fixed in selinux-policy-3.9.7-43.fc14

Comment 11 Fedora Update System 2011-10-20 11:57:10 UTC
selinux-policy-3.9.7-46.fc14 has been submitted as an update for Fedora 14.
https://admin.fedoraproject.org/updates/selinux-policy-3.9.7-46.fc14

Comment 12 Fedora Update System 2011-10-22 08:20:20 UTC
Package selinux-policy-3.9.7-46.fc14:
* should fix your issue,
* was pushed to the Fedora 14 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing selinux-policy-3.9.7-46.fc14'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2011-14734
then log in and leave karma (feedback).

Comment 13 Fedora Update System 2011-10-30 00:33:06 UTC
selinux-policy-3.9.7-46.fc14 has been pushed to the Fedora 14 stable repository.  If problems still persist, please make note of it in this bug report.


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