Bug 138358

Summary:	SELinux blocks pam_console access of /dev/pmu
Product:	[Fedora] Fedora	Reporter:	W. Michael Petullo <redhat>
Component:	selinux-policy-strict	Assignee:	Daniel Walsh <dwalsh>
Status:	CLOSED RAWHIDE	QA Contact:
Severity:	medium	Docs Contact:
Priority:	medium
Version:	rawhide	CC:	walters
Target Milestone:	---
Target Release:	---
Hardware:	powerpc
OS:	Linux
Whiteboard:
Fixed In Version:	1.19.1-11	Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2004-11-17 18:24:10 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:
Bug Blocks:	133471

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:
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 18:44:43 UTC

Added policy to selinux-policy-strict-1.18.2-4

Dan

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!