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).
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
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
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
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.
(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).
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.
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
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.
I have added a commit to Rawhide to allow this access. 375541b1fc18fa285068d3c9c4068089d63604f9 Probably should be back ported to F14 and F15.
Fixed in selinux-policy-3.9.7-43.fc14
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
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).
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.