I'm seeing a lot of chatter from selinux - including avc denied - when I log in as a user with a pam_mount'ed LUKS partition. I found bug #426785, but I'm running selinux-policy-3.0.8-76.fc8 (and pam_mount-0.18-2.fc8) and the mount itself seems to be successful - the home directory is present. The home directory isn't unmounted when I log out - I suspect that could be broken by selinux. It looks similar to #426785, but for pam_mount in regard to sshd and login rather than gdm. I have pam_mount configured for: sshd, login, and gdm. I'll attach the relevant log sections of audit.log, messages, and secure; the summary of which is: gdm: 0 avc denied sshd on login: 17 avc denied (1 avc denied it the user doesn't have an encrypted home) sshd on logout: 3 avc denied login on login: 1 avc denied login on logout: 3 avc denied I can provide more log information if needed (I wasn't which would be most useful). This appears to be a regression from FC6.
Created attachment 293213 [details] logs when logging in via gdm (no avc denied)
Created attachment 293214 [details] logs: sshd login
Created attachment 293215 [details] logs: sshd logout
Created attachment 293216 [details] logs: sshd - user without pam_mounted crypted home
Created attachment 293217 [details] logs: login user login
Created attachment 293218 [details] logs: login user logout
Kevin thanks for reporting these. In Fedora 8 Login and sshd are confined, which is why you are seeing these. I have done some investigation into the pam_mount package and have seen some SELinux problems. Labeling on /sbin/mount.crypt and /sbin/umount.crypt should be fixed in the next release. You can temporarily change the context on these files by executing chcon -t mount_exec_t /sbin/mount.crypt /sbin/umount/crypt After you do this you can login in permissive mode to generate all of the AVC messages. Then you can temporarily update you policy, by executing # grep AVC /var/log/audit/audit.log | audit2allow -M mypolicy # semodule -i mypolicy.pp This should get you back to enforcing mode. pam_mount maintainers: I am not sure what pmvarrun purpose is, if it creates files in /var/run/pam_mount Then this directory should be owned by the package. /var/run/pam_mount should be labeled pam_var_run_t, which will allow the login programs to use that directory. I will change the SELinux policy to match that labeling, but the directory should be part of the spec to get created with the right context on install. Man page for pmvarrun states: A separate program is needed so that /var/run/pam_mount/user may be created with a pam_mount-specific security context (otherwise SELinux policy will conflict with gdm, which also creates file in /var/run). I have no idea what this means and I believe this is false. Finally this package ships some policy files for strict policy which probably should be removed and if additional privs are required they should be added to the base package. Labeling will be fixed in selinux-policy-3.0.8-82
(In reply to comment #7) > I am not sure what pmvarrun purpose is, if it creates files in /var/run/pam_mount > Then this directory should be owned by the package. /var/run/pam_mount should > be labeled pam_var_run_t, which will allow the login programs to use that > directory. I will change the SELinux policy to match that labeling, but the > directory should be part of the spec to get created with the right context on > install. Is it reasonable to build a new pam_mount package that owns /var/run/pam_mount for F8, even when there are no other changes? Do I need to run restorecon in %post? > Man page for pmvarrun states: > A separate program is needed so that /var/run/pam_mount/user may be > created with a pam_mount-specific security context (otherwise SELinux > policy will conflict with gdm, which also creates file in /var/run). > > > I have no idea what this means and I believe this is false. Pam_mount upstream interpreted this in http://sourceforge.net/mailarchive/message.php?msg_name=Pine.LNX.4.64.0801300114250.14907%40fbirervta.pbzchgretzou.qr the following: Using a separate programm makes sure that the context of the files in /var/run/pam_mount are independent from the programm that loads pam_mount.so. E.g. the context of gdm and ssh may differ, so that after a login via gdm, the file in /var/run/pam_mount could not be updated when one logs in via ssh. But I do not know, whether this is really an issue. Better you also read the original mail from upstream. > Finally this package ships some policy files for strict policy which probably > should be removed and if additional privs are required they should be added to > the base package. I will try to test whether pam_mount works without its own policy files.
In RHEL5 and beyond, both gdm/sshd can write to directories labeled pam_var_run_t. So if you create this directory in the rpm and we have labeling setup, no additional programs should be necessary. RPM has a builtin "restorecon" So no you do not need to run restorecon in the post install script. All packages should own the directories they create, so package removal will remove the directories. If you want pam_mount to work properly with selinux then you will need to update the package.
(cross-posted to the pam-mount-user list; I don't know if that's a better place to resolve this issue: http://tinyurl.com/yvsta4 ) I'm now running selinux-policy-3.0.8-84.fc8, but still see AVC denied messages when logging in (and so using pam_mount). I'm unclear as to whether the selinux-policy changes alone should have fixed these errors, or whether pmvarrun and the superfluous policy files need to be fixed? (as opposed to it just being nice for them to be fixed!) On 2008-01-30 00:24, Jan Engelhardt wrote: > >Btw. could you maybe adjust the autotools stuff in a way, that the > >directory /var/run/pam_mount/ is created on install? > Can do that. See changeset r407. Ok, so /var/run/pam_mount will be created on install of pam_mount - great! > pmvarrun.c -- Updates /var/run/pam_mount/<user>. [snip] > But since pam_mount.so is also > run from console and perhaps other login managers, there could be a > conflict on /var/run/pam_mount files. At least that's what I would > make of this message that I inherited from the previous maintainer > and kept through the releases. This is an incorrect assumption according to the Fedora selinux maintainer in comment #9 (and in earlier comments on that bug) Is there any reason why pmvarrun cannot be removed now? Or merged into the main pam_mount? AFAICT, with the creation of /var/run/pam_mount by the package pmvarrun is causing selinux problems, not solving them. > Centos perhaps, because they clone redhat. selinux is too complex > (read: nice shiny user interfaces missing) and I don't even bother > turning on AppArmor. The policy files are likely out of date, > obsolete or wrong. CentOS is based on RHEL, which in turn is based on Fedora. From the Fedora selinux maintainer in the RH bugzilla: "Finally this package ships some policy files for strict policy which probably should be removed and if additional privs are required they should be added to the base package." Could these policy files be removed from the pam_mount install? If this will cause problems elsewhere than Fedora/RHEL/CentOS, would it be possible for a configure option to ignore them?
What is the labeling on /var/run/pam_mount ls -lZd /var/run/pam_mount Does restorecon -R -v /var/run/pam_mount fix it.
(In reply to comment #11) > What is the labeling on /var/run/pam_mount > ls -lZd /var/run/pam_mount drwxr-xr-x root root system_u:object_r:pam_var_run_t /var/run/pam_mount > Does restorecon -R -v /var/run/pam_mount fix it. Sorry, no.
Ok what AVC messages are you seeing now?
Created attachment 295953 [details] audit.log for ssh login I can only grab debug for ssh logins at the moment (I already tried restorecon and login with gdm yesterday; I double checked restorecon today too). Attached is audit.log for a ssh login to a user with two pam_mount directories, one being the home directory.
You can allow this for now by executing # audit2allow -M mypol -i /var/log/audit/audit.log # semodule -i mypol.pp Fixed in selinux-policy-3.0.8-89.fc8
>In RHEL5 and beyond, both gdm/sshd can write to directories >labeled pam_var_run_t. So if you create this directory in >the rpm and we have labeling setup, no additional programs >should be necessary. Well ok, but there is not just gdm or sshd. Anything that call the PAM stack in "session" mode, including su/kdm/cron and possibly many others must be able to write into it. Instead of giving policy files to them all (which is impossible, given the uncountable number of user-written programs), pmvarrun is used to switch to pam_var_run_t context and then operate on the files. So far the theory from my --disabled-selinux standpoint. :-)
su/kdm/cron can also write there. Any login program or program that is confined and uses pam. pam_var_run_t is a file context not a process context. Processes get the access not the files. If a process is using pam, is setuid and is confined, it will need to have this permissions, and labeling will need to be setup correctly.
The AVCs are indeed gone with the latest F8 policy - thanks. I've left the bug open as there seems to be a useful discussion regarding pmvarrun; feel free to close the bug if this is best continued elsewhere.
This message is a reminder that Fedora 8 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 8. 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 '8'. 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 8'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 8 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
As this bug is in MODIFIED, Fedora believes that a fix has been committed that resolves the problem listed in this bug report. If this is not the case, please re-open this report, noting the version of the package that you reproduced the bug against. Thanks for the report!