Bug 595508

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.