Bug 599609

Summary: use mount -t crypt instead of mount.crypt for pam_mount crypt volumes for selinux support
Product: [Fedora] Fedora Reporter: Bill Nottingham <notting>
Component: pam_mountAssignee: Till Maas <opensource>
Status: CLOSED ERRATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: low    
Version: 13CC: dwalsh, jokatzer, jpazdziora, mgrepl, monahov, opensource, redhat-bugzilla, rvokal, steve
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: cryptsetup-luks-1.1.3-1.fc12 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2010-07-13 03:26:05 EDT Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:

Description Bill Nottingham 2010-06-03 11:28:05 EDT
Description of problem:

time->Thu Jun  3 11:22:55 2010
type=SYSCALL msg=audit(1275578575.721:153): arch=c000003e syscall=59 success=yes exit=0 a0=7fff66f15b07 a1=101e8a0 a2=101ed50 a3=7f8f3a5a4240 items=0 ppid=2060 pid=2077 auid=2166 uid=0 gid=2167 euid=0 suid=0 fsuid=0 egid=2167 sgid=2167 fsgid=2167 tty=(none) ses=2 comm="mount.crypt" exe="/sbin/mount.crypt" subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key=(null)
type=AVC msg=audit(1275578575.721:153): avc:  denied  { read open } for  pid=2077 comm="gdm-session-wor" name="mount.crypt" dev=sda2 ino=5899251 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:object_r:lvm_exec_t:s0 tclass=file
type=AVC msg=audit(1275578575.721:153): avc:  denied  { execute } for  pid=2077 comm="gdm-session-wor" name="mount.crypt" dev=sda2 ino=5899251 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:object_r:lvm_exec_t:s0 tclass=file

Version-Release number of selected component (if applicable):

3.7.19-23

How reproducible:

100%
Comment 1 Daniel Walsh 2010-06-03 16:58:27 EDT
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
Comment 2 Till Maas 2010-06-28 16:52:13 EDT
(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
Comment 3 Jan Pazdziora 2010-07-02 08:41:57 EDT
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
Comment 4 Till Maas 2010-07-02 12:48:11 EDT
(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.
Comment 5 Fedora Update System 2010-07-02 15:28:09 EDT
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
Comment 6 Jan Pazdziora 2010-07-02 15:45:44 EDT
(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.
Comment 7 Till Maas 2010-07-02 16:36:35 EDT
(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.
Comment 8 Fedora Update System 2010-07-03 14:49:38 EDT
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
Comment 9 Fedora Update System 2010-07-06 13:12:45 EDT
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
Comment 10 Fedora Update System 2010-07-06 13:29:05 EDT
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
Comment 11 Jan Pazdziora 2010-07-07 06:07:19 EDT
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.
Comment 12 Jan Pazdziora 2010-07-07 06:09:18 EDT
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.
Comment 13 Till Maas 2010-07-07 06:33:04 EDT
(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.
Comment 14 Miroslav Grepl 2010-07-07 06:51:52 EDT
*** Bug 611007 has been marked as a duplicate of this bug. ***
Comment 15 Jan Pazdziora 2010-07-07 07:21:40 EDT
(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.
Comment 16 Jan Pazdziora 2010-07-07 07:23:07 EDT
(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.
Comment 17 Till Maas 2010-07-07 07:46:41 EDT
(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.
Comment 18 Till Maas 2010-07-07 08:27:13 EDT
(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?
Comment 19 Jan Pazdziora 2010-07-07 09:55:17 EDT
(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.
Comment 20 Jan Pazdziora 2010-07-07 10:00:19 EDT
(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
Comment 21 Fedora Update System 2010-07-13 03:25:42 EDT
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.
Comment 22 Fedora Update System 2010-08-06 16:58:32 EDT
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.
Comment 23 Joachim Katzer 2010-08-10 13:38:09 EDT
(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
Comment 24 Till Maas 2010-08-10 14:14:26 EDT
(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?
Comment 25 Joachim Katzer 2010-08-10 16:19:34 EDT
> 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.