pam_mount is calling mount.crypt directly which now contains all of the code usually reserved for lvm executables.  This means I need to label it lvm_exec_t, which is causing this AVC.

The problem is, I now need to allow all login programs to transition to lvm_t.  I would prefer to only allow mount_t to transition to lvm_t, which is what current policy does.

xdm_t -> mount_exec_t (/bin/mount) -> mount_t -> lvm_exec_t (/bin/mount.crypt) -> lvm_t

Can you change pam_mount to execute /bin/mount rather then /bin/mount.crypt?


Translation can you run 


/sbin/mount -t crypt 

rather then

/sbin/mount.crypt

(In reply to comment #1)

> Translation can you run 
> 
> 
> /sbin/mount -t crypt 
> 
> rather then
> 
> /sbin/mount.crypt    

This is very likely. I just opened an upstream artifact:

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

Till,

the bugzilla in sourceforge has been Closed Fixed.

Are you planning on releasing new pam_mount soon? I believe both the severity and priority of this bug should be bumped up because it effectively prevent people from using crypted homes under Enforcing.

Thank you,

Jan

(In reply to comment #3)

> the bugzilla in sourceforge has been Closed Fixed.
> 
> Are you planning on releasing new pam_mount soon? I believe both the severity
> and priority of this bug should be bumped up because it effectively prevent
> people from using crypted homes under Enforcing.

The current release in Fedora stable should not suffer from this bug, but only a version that was in testing. Unluckily the latest pam_mount release does not work on F12 or F13, because cryptsetup-luks is too old there. And the upcomming 2.5 release of pam_mount for hopefully complete selinux support (there is another issue regarding selinux: bug 580585) I need to get another package included (hxtools, http://jengelh.medozas.de/projects/hxtools/).

Therefore it will take some more time until everything is resolved.

cryptsetup-luks-1.1.2-2.fc13,libHX-3.4-1.fc13,pam_mount-2.4-1.fc13 has been submitted as an update for Fedora 13.
http://admin.fedoraproject.org/updates/cryptsetup-luks-1.1.2-2.fc13,libHX-3.4-1.fc13,pam_mount-2.4-1.fc13

(In reply to comment #4)
> 
> The current release in Fedora stable should not suffer from this bug, but only
> a version that was in testing. Unluckily the latest pam_mount release does not

Actually, I saw the problem on Fedora 13 stable with pam_mount-1.32-1.fc12.i686, with exactly the same AVCs:

type=AVC msg=audit(1278073632.839:27): avc:  denied  { execute } for  pid=1753 comm="login" name="mount.crypt" dev=dm-0 ino=295815 scontext=system_u:system_r:local_login_t:s0-s0:c0.c1023 tcontext=system_u:object_r:lvm_exec_t:s0 tclass=file
type=AVC msg=audit(1278065817.011:27230): avc:  denied  { execute } for  pid=1746 comm="gdm-session-wor" name="mount.crypt" dev=dm-0 ino=295815 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:object_r:lvm_exec_t:s0 tclass=file

I've workarounded with

chcon -t mount_exec_t /sbin/mount.crypt

for from my investigation, Fedora 13 stable needs some fix as well.

(In reply to comment #6)

> for from my investigation, Fedora 13 stable needs some fix as well.    

Ah, ok. I suspected this to be the bug that was announced by an anonymous tester and this update comment:
| Beware! mount.crypt (and therefore any mounting of encrypted volumes) doesn't 
| work with SELinux Enforcing mode at all since mount.crypt doesn't have the
| necessary cryptsetup privileges (yet). I'll file a proper bugreport soon...

Nevertheless, I hope the announced update will fix this for F13.

cryptsetup-luks-1.1.3-1.fc12,libHX-3.4-1.fc12,pam_mount-2.4-2.fc12 has been submitted as an update for Fedora 12.
http://admin.fedoraproject.org/updates/cryptsetup-luks-1.1.3-1.fc12,libHX-3.4-1.fc12,pam_mount-2.4-2.fc12

cryptsetup-luks-1.1.3-1.fc12, pam_mount-2.4-2.fc12, libHX-3.4-1.fc12 has been pushed to the Fedora 12 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update cryptsetup-luks pam_mount libHX'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/cryptsetup-luks-1.1.3-1.fc12,libHX-3.4-1.fc12,pam_mount-2.4-2.fc12

cryptsetup-luks-1.1.3-1.fc13, pam_mount-2.4-2.fc13, libHX-3.4-1.fc13 has been pushed to the Fedora 13 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update cryptsetup-luks pam_mount libHX'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/cryptsetup-luks-1.1.3-1.fc13,libHX-3.4-1.fc13,pam_mount-2.4-2.fc13

This upgrade works for me, in the sense the existing configuration with

<volume user="username" fstype="crypt" path="/dev/vg0/lv4" mountpoint="/home/username" options="fstype=ext4"/>

which I had working previously with

chcon -t mount_exec_t /sbin/mount.crypt

now works both in login and in gdm logins with /sbin/mount.crypt set to lvm_exec_t. Thanks.

I'm facing two issues with the F13 setup which I did not see on F12 thou.

Upon login, I get

machine login: adelton
pam_mount password:
pam_mount(mount.c:64): Errors from underlying mount program:
pam_mount(mount.c:68): crypt_activate_by_passphrase: File exists
pam_mount(pam_mount.c:521): mount of /dev/vg0/lv4 failed
Last login: Wed Jul  7 11:36:12 on tty2
$

-- so pam_mount spits some errors but it mounts the volume just fine.

Another issue is that upon logout, the volume does not get unmounted.

(In reply to comment #12)
> I'm facing two issues with the F13 setup which I did not see on F12 thou.
> 
> Upon login, I get
> 
> machine login: adelton
> pam_mount password:
> pam_mount(mount.c:64): Errors from underlying mount program:
> pam_mount(mount.c:68): crypt_activate_by_passphrase: File exists
> pam_mount(pam_mount.c:521): mount of /dev/vg0/lv4 failed
> Last login: Wed Jul  7 11:36:12 on tty2
> $
> 
> -- so pam_mount spits some errors but it mounts the volume just fine.

Can you maybe report this upstream?

> Another issue is that upon logout, the volume does not get unmounted.    

The logout issue is probably the one in bug 580585. Afaik it will be addressed in pam_mount 2.5, but I also need to get to package one new dependency for it.

*** Bug 611007 has been marked as a duplicate of this bug. ***

(In reply to comment #13)
> > 
> > machine login: adelton
> > pam_mount password:
> > pam_mount(mount.c:64): Errors from underlying mount program:
> > pam_mount(mount.c:68): crypt_activate_by_passphrase: File exists
> > pam_mount(pam_mount.c:521): mount of /dev/vg0/lv4 failed
> > Last login: Wed Jul  7 11:36:12 on tty2
> > $
> > 
> > -- so pam_mount spits some errors but it mounts the volume just fine.
> 
> Can you maybe report this upstream?

I'd prefer not to interact with upstream directly. ;-)

> > Another issue is that upon logout, the volume does not get unmounted.    
> 
> The logout issue is probably the one in bug 580585. Afaik it will be addressed
> in pam_mount 2.5, but I also need to get to package one new dependency for it.    

Well, I do not see any AVCs in my audit.log -- it's completely clean.

(In reply to comment #15)
> > > 
> > > -- so pam_mount spits some errors but it mounts the volume just fine.
> > 
> > Can you maybe report this upstream?
> 
> I'd prefer not to interact with upstream directly. ;-)

But I can definitely craft a separate bugzilla with reproducer instructions on F13.

(In reply to comment #16)
> (In reply to comment #15)
> > > > 
> > > > -- so pam_mount spits some errors but it mounts the volume just fine.
> > > 
> > > Can you maybe report this upstream?
> > 
> > I'd prefer not to interact with upstream directly. ;-)

I cannot understand this, because he is very friendly.

> But I can definitely craft a separate bugzilla with reproducer instructions on
> F13.    

Yes, please.

(In reply to comment #15)
> (In reply to comment #13)

> > > Another issue is that upon logout, the volume does not get unmounted.    
> > 
> > The logout issue is probably the one in bug 580585. Afaik it will be addressed
> > in pam_mount 2.5, but I also need to get to package one new dependency for it.    
> 
> Well, I do not see any AVCs in my audit.log -- it's completely clean.    

Is there some pam_mount log output regarding the umount?

(In reply to comment #17)
> 
> I cannot understand this, because he is very friendly.

It's nothing personal. ;-) But I'd need to have an account on sourceforge and remember its password or I wouldn't be able to follow up on that bug submission. Plus it might turn up to be something Fedora-specific ...

> > But I can definitely craft a separate bugzilla with reproducer instructions on
> > F13.    
> 
> Yes, please.    

Filed bug 612179.

(In reply to comment #18)
it.    
> > 
> > Well, I do not see any AVCs in my audit.log -- it's completely clean.    
> 
> Is there some pam_mount log output regarding the umount?    

No. There's nothing in /var/log/messages. If I umount it as root, it just unmounts fine.

Funny thing is, when I did the fresh vmware installation of Fedora 13 for bug 612179, the home umounted every time without problems.

In the past, I remember that the pulse audit daemon stayed around for a while after logout which prevented the home directory to be unmounted. But it's not the case here as it's login on the console I I've checked that nothing but bash runs under my uid when I log in. I will watch the logou issue and if I'm able to do a deterministic reproducer, I'll file separate bugzilla.

Thanks,

Jan

cryptsetup-luks-1.1.3-1.fc13, pam_mount-2.4-2.fc13, libHX-3.4-1.fc13 has been pushed to the Fedora 13 stable repository.  If problems still persist, please make note of it in this bug report.

cryptsetup-luks-1.1.3-1.fc12, pam_mount-2.4-2.fc12, libHX-3.4-1.fc12 has been pushed to the Fedora 12 stable repository.  If problems still persist, please make note of it in this bug report.

(In reply to comment #22)
> cryptsetup-luks-1.1.3-1.fc12, pam_mount-2.4-2.fc12, libHX-3.4-1.fc12 has been
> pushed to the Fedora 12 stable repository.  If problems still persist, please
> make note of it in this bug report.    

Problem appeared after installing this "stable" update on my Fedora 12: I could no longer login unless SELinux is disabled.

As adviced in Comment 1, I have changed the <cryptmount> command to "mount -t crypt", but in addition I had to change the context of /sbin/mount.crypt as a workaround:

chcon -t lvm_exec_t /sbin/mount.crypt

Is lvm_exec_t now the intended context of mount.crypt? Currently, in selinux-policy-3.6.32-118.fc12.noarch it seems to be mount_exec_t which does not work:

# restorecon -v -n /sbin/mount.crypt
restorecon reset /sbin/mount.crypt context system_u:object_r:lvm_exec_t:s0->system_u:object_r:mount_exec_t:s0

(In reply to comment #23)
> (In reply to comment #22)
> > cryptsetup-luks-1.1.3-1.fc12, pam_mount-2.4-2.fc12, libHX-3.4-1.fc12 has been
> > pushed to the Fedora 12 stable repository.  If problems still persist, please
> > make note of it in this bug report.    
> 
> Problem appeared after installing this "stable" update on my Fedora 12: I could
> no longer login unless SELinux is disabled.

Sorry for the trouble, but there was also no negative feedback regarding this for the month the update was in testing.

> As adviced in Comment 1, I have changed the <cryptmount> command to "mount -t
> crypt", but in addition I had to change the context of /sbin/mount.crypt as a
> workaround:

There should be no <cryptmount> (or other helper program definition) in the config file, unless you want to do something special. The default value is already "mount -t crypt", so you should achieve the same by just removing the cryptmount definition. For umounting the workaround in bug 620583 comment 3 might be required. But afaik it is also broken with selinux because of bug 580585.

> chcon -t lvm_exec_t /sbin/mount.crypt
> 
> Is lvm_exec_t now the intended context of mount.crypt? Currently, in
> selinux-policy-3.6.32-118.fc12.noarch it seems to be mount_exec_t which does
> not work:

This is a different (but related) issue than the one described in this bug report, because here the problem was, can you please open a new bug report?

> This is a different (but related) issue than the one described in this bug
> report, because here the problem was, can you please open a new bug report?    

Thanks for quick feedback. I have opened a new bug report in https://bugzilla.redhat.com/show_bug.cgi?id=622929.