Red Hat Bugzilla – Bug 138358
SELinux blocks pam_console access of /dev/pmu
Last modified: 2007-11-30 17:10:53 EST
From Bugzilla Helper: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7) Gecko/20040626 Firefox/0.8 Description of problem: The symptoms documented in bug #126024 are once again an issue, but the problem seems to be caused by SELinux now. When I log in with SELinux enforcing Fedora's selinux-policy-strict, GNOME notes, "Permissions on the file /dev/pmu are broken." /dev/pmu is a power management device used on Apple hardware that is managed by pam_console. /dev/pmu has a SELinux context of system_u:object_r:device_t. I notice that all of the other devices that are managed by pam_console have more specific contexts. One example is /dev/audio: system_u:object_r:sound_device_t. We probably need to give /dev/pmu a more specific context and then provide the proper access to this device to gdm, login, etc. Version-Release number of selected component (if applicable): 1.18.2-2 How reproducible: Always Steps to Reproduce: 1. Tell SELinux to enforce Fedora's strict policy. 2. Log in to GNOME Actual Results: GNOME notes, "Permissions on the file /dev/pmu are broken." Expected Results: Pam_console should assign /dev/pmu the appropriate permissions. Additional info:
Added policy to selinux-policy-strict-1.18.2-4 Dan
I am now using selinux-policy-strict-1.19.1-3. It looks like some more is needed. First, the following lines should be added to domains/program/login.te and xmd.te: allow local_login_t power_device_t:chr_file { setattr getattr }; allow xdm_t power_device_t:chr_file { setattr getattr }; Following that change, I realized that gnome-settings-daemon, the program that needs access to /dev/pmu, does not have access to the device. Gnome-settings-daemon runs with a context of user_u:user_r:user_t. I think a more specialized context needs to be created that gives gnome-settings-daemon access to /dev/pmu. The "Permissions one the file /dev/pmu are broken" window still pops up when I log in.
allow local_login_t power_device_t:chr_file { setattr getattr }; allow xdm_t power_device_t:chr_file { setattr getattr }; Why is local_login and xdm asking for this privs Shouldn't pam_console be setting the attributes on this device? What access does gnome-settings-daemon want for this device?
I just mimicked the existing rules for sound_device_t, mouse_device_t, etc. that are already in the policy for xdm_t and login_local_t. Does pam_console fork and execute a seperate program to chmod its devices? Otherwise, pam_console.so is just a shared library that would be pulled into gdm, login, etc.'s context. I have not looked at the code in pam_console since well before I started playing with SELinux so I don't know. As I said, I was just following the example of existing rules. This seems to do it for gnome-settings-daemon (though this should probably be a g-s-d-specific policy, not user_t): allow user_t power_device_t:chr_file { read write ioctl };
/sbin/pam_console is execed. But I do see those rules for sound device. So do you see any problems in allowing a normal user allow user_t power_device_t:chr_file { read write ioctl }; What would this allow the user to do? Turn the machine off? I can add this but want to make sure it is a good idea? Sorry for my ignorance. :^)
Never mind, I was wrong. I am adding the policy that you specified. Fixed in selinux-policy-strict-1.19.1-11
This seems to be fixed. Thanks!