Bug 138358 - SELinux blocks pam_console access of /dev/pmu
Summary: SELinux blocks pam_console access of /dev/pmu
Alias: None
Product: Fedora
Classification: Fedora
Component: selinux-policy-strict
Version: rawhide
Hardware: powerpc
OS: Linux
Target Milestone: ---
Assignee: Daniel Walsh
QA Contact:
Depends On:
Blocks: 133471
TreeView+ depends on / blocked
Reported: 2004-11-08 15:58 UTC by W. Michael Petullo
Modified: 2007-11-30 22:10 UTC (History)
1 user (show)

Clone Of:
Last Closed: 2004-11-17 18:24:10 UTC

Attachments (Terms of Use)

Description W. Michael Petullo 2004-11-08 15:58:57 UTC
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:

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):

How reproducible:

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

Expected Results:  Pam_console should assign /dev/pmu the appropriate

Additional info:

Comment 1 Daniel Walsh 2004-11-08 18:44:43 UTC
Added policy to selinux-policy-strict-1.18.2-4


Comment 2 W. Michael Petullo 2004-11-11 21:01:22 UTC
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.

Comment 3 Daniel Walsh 2004-11-12 02:25:25 UTC
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?

Comment 4 W. Michael Petullo 2004-11-13 21:53:35 UTC
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 };

Comment 5 Daniel Walsh 2004-11-15 14:48:02 UTC
/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.  :^)

Comment 6 Daniel Walsh 2004-11-16 17:34:22 UTC
Never mind, I was wrong.  I am adding the policy that you specified.

Fixed in selinux-policy-strict-1.19.1-11

Comment 7 W. Michael Petullo 2004-11-17 18:24:10 UTC
This seems to be fixed.  Thanks!

Note You need to log in before you can comment on or make changes to this bug.