Bug 138358 - SELinux blocks pam_console access of /dev/pmu
SELinux blocks pam_console access of /dev/pmu
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: selinux-policy-strict (Show other bugs)
rawhide
powerpc Linux
medium Severity medium
: ---
: ---
Assigned To: Daniel Walsh
:
Depends On:
Blocks: 133471
  Show dependency treegraph
 
Reported: 2004-11-08 10:58 EST by W. Michael Petullo
Modified: 2007-11-30 17:10 EST (History)
1 user (show)

See Also:
Fixed In Version: 1.19.1-11
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-11-17 13:24:10 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description W. Michael Petullo 2004-11-08 10:58:57 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:
Comment 1 Daniel Walsh 2004-11-08 13:44:43 EST
Added policy to selinux-policy-strict-1.18.2-4

Dan
Comment 2 W. Michael Petullo 2004-11-11 16:01:22 EST
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-11 21:25:25 EST
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 16:53:35 EST
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 09:48:02 EST
/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 12:34:22 EST
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 13:24:10 EST
This seems to be fixed.  Thanks!

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