Bug 631064 - SELinux is preventing /sbin/hdparm "read" to /var/run/pm-utils/locks/pm-suspend.lock.
Summary: SELinux is preventing /sbin/hdparm "read" to /var/run/pm-utils/locks/pm-suspe...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: selinux-policy
Version: 14
Hardware: All
OS: Linux
low
medium
Target Milestone: ---
Assignee: Daniel Walsh
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2010-09-07 16:26 UTC by Steve Tyler
Modified: 2010-09-11 03:42 UTC (History)
2 users (show)

Fixed In Version: selinux-policy-3.9.3-1.fc14
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2010-09-11 03:42:04 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
selinux-alert.1.log (2.58 KB, text/plain)
2010-09-07 16:26 UTC, Steve Tyler
no flags Details
selinux-alert.2.log (2.34 KB, text/plain)
2010-09-07 16:32 UTC, Steve Tyler
no flags Details
selinux-alert.3.log (2.42 KB, text/plain)
2010-09-07 16:34 UTC, Steve Tyler
no flags Details

Description Steve Tyler 2010-09-07 16:26:37 UTC
Created attachment 443775 [details]
selinux-alert.1.log

Description of problem:
In an F14 VM, I get three selinux alerts after attempting to suspend. Suspend fails and the desktop immediately returns.

Version-Release number of selected component (if applicable):
selinux-policy-3.9.0-2.fc14
hdparm-9.27-1.fc13
kernel-2.6.35.4-12.fc14.x86_64

How reproducible:
Always.

Steps to Reproduce:
1. Install F14 to a VM, boot, update.
2. Relabel on reboot.
3. Login and attempt to suspend.

I'm using "qemu-kvm -hda f14-alpha.img -m 512m"
  
Actual results:
The suspend fails and the desktop immediately returns.
Three selinux alerts are reported.

Expected results:
No selinux alerts.

Additional info:
node=fir type=AVC msg=audit(1283875150.620:20): avc:  denied  { read } for  pid=1898 comm="hdparm" path="/var/run/pm-utils/locks/pm-suspend.lock" dev=dm-0 ino=260379 scontext=system_u:system_r:fsadm_t:s0 tcontext=system_u:object_r:hald_var_run_t:s0 tclass=file

node=fir type=SYSCALL msg=audit(1283875150.620:20): arch=c000003e syscall=59 success=yes exit=0 a0=2655d00 a1=2656150 a2=26579b0 a3=20 items=0 ppid=1897 pid=1898 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="hdparm" exe="/sbin/hdparm" subj=system_u:system_r:fsadm_t:s0 key=(null)

Comment 1 Steve Tyler 2010-09-07 16:32:29 UTC
Created attachment 443865 [details]
selinux-alert.2.log

SELinux is preventing /bin/bash "getattr" access on /.
98video-quirk-d has a permissive type (devicekit_power_t). This access was not
denied.

Comment 2 Steve Tyler 2010-09-07 16:34:53 UTC
Created attachment 443913 [details]
selinux-alert.3.log

Summary:

SELinux has prevented vbetool from performing an unsafe memory operation.

Detailed Description:

SELinux denied an operation requested by vbetool, a program used to alter video
hardware state. This program is known to use an unsafe operation on system
memory but so are a number of malware/exploit programs which masquerade as
vbetool. This tool is used to reset video state when a machine resumes from a
suspend. If your machine is not resuming properly your only choice is to allow
this operation and reduce your system security against such malware.

Comment 3 Steve Tyler 2010-09-07 16:38:46 UTC
qemu is running on an F13 system:

[stephent@walnut ~]$ rpm -qa 'qemu*' | sort
qemu-common-0.12.5-1.fc13.x86_64
qemu-img-0.12.5-1.fc13.x86_64
qemu-kvm-0.12.5-1.fc13.x86_64
qemu-system-x86-0.12.5-1.fc13.x86_64

Comment 4 Daniel Walsh 2010-09-07 17:37:28 UTC
Steven do not open three bugs all in the same report.  The first one is a problem reported against pm-utils. It is leaking a file descriptor.  The vbetool one is a bug in vbetool which should not need that access.  Also an existing bug on vbetool has been opened on this one.

The devicekit_power_t one is fixed in the latest policy.

Comment 5 Steve Tyler 2010-09-07 18:08:52 UTC
(In reply to comment #4)
> Steven do not open three bugs all in the same report.  The first one is a
> problem reported against pm-utils. It is leaking a file descriptor.  The
> vbetool one is a bug in vbetool which should not need that access.  Also an
> existing bug on vbetool has been opened on this one.
> 
> The devicekit_power_t one is fixed in the latest policy.

OK, thanks. Since they all had the same proximate cause I collected them here. If you need me to spin off separate bugs next time, please just ask and suggest the components.

Comment 6 Daniel Walsh 2010-09-07 18:13:39 UTC
No since they are all covered I will just close this bug as fixed in the next release.


Fixed in selinux-policy-3.9.3-1.fc14

Comment 7 Fedora Update System 2010-09-08 18:40:53 UTC
selinux-policy-3.9.3-1.fc14 has been submitted as an update for Fedora 14.
https://admin.fedoraproject.org/updates/selinux-policy-3.9.3-1.fc14

Comment 8 Steve Tyler 2010-09-08 22:49:46 UTC
(In reply to comment #7)
> selinux-policy-3.9.3-1.fc14 has been submitted as an update for Fedora 14.
> https://admin.fedoraproject.org/updates/selinux-policy-3.9.3-1.fc14

Thanks, Dan.
The devicekit_power_t alert does not occur after suspend fails in a VM.

Comment 9 Daniel Walsh 2010-09-09 01:31:48 UTC
Please update karma.

Comment 10 Fedora Update System 2010-09-09 04:11:14 UTC
selinux-policy-3.9.3-1.fc14 has been pushed to the Fedora 14 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update selinux-policy'.  You can provide feedback for this update here: https://admin.fedoraproject.org/updates/selinux-policy-3.9.3-1.fc14

Comment 11 Fedora Update System 2010-09-11 03:40:20 UTC
selinux-policy-3.9.3-1.fc14 has been pushed to the Fedora 14 stable repository.  If problems still persist, please make note of it in this bug report.


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