Bug 253722 - /var/log/pm-suspend.log keeps getting the wrong selinux context
Summary: /var/log/pm-suspend.log keeps getting the wrong selinux context
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: pm-utils
Version: 5.1
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
: ---
Assignee: Phil Knirsch
QA Contact:
URL:
Whiteboard:
Depends On: 238068
Blocks:
TreeView+ depends on / blocked
 
Reported: 2007-08-21 14:33 UTC by Florian La Roche
Modified: 2015-03-05 01:19 UTC (History)
4 users (show)

Fixed In Version: RHBA-2007-0538
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2007-11-07 16:44:15 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2007:0538 0 normal SHIPPED_LIVE pm-utils bug fix and enhancement update 2007-10-30 16:16:54 UTC

Description Florian La Roche 2007-08-21 14:33:07 UTC
+++ This bug was initially created as a clone of Bug #238068 +++

Description of problem:
pm-suspend.log is supposed to have the hald_log_t context, but it keeps getting
reset to var_log_t, causing avc denials such the following on resume:

avc: denied { write } for comm="ntpd" dev=sda3 egid=0 euid=0
exe="/usr/sbin/ntpd" exit=0 fsgid=0 fsuid=0 gid=0 items=0 name="pm-suspend.log"
path="/var/log/pm-suspend.log" pid=3051 scontext=user_u:system_r:ntpd_t:s0
sgid=0 subj=user_u:system_r:ntpd_t:s0 suid=0 tclass=file
tcontext=user_u:object_r:var_log_t:s0 tty=(none) uid=0 
avc: denied { write } for comm="pm-suspend" dev=sda3 egid=0 euid=0
exe="/bin/bash" exit=-13 fsgid=0 fsuid=0 gid=0 items=0 name="pm-suspend.log"
pid=3028 scontext=system_u:system_r:hald_t:s0 sgid=0
subj=system_u:system_r:hald_t:s0 suid=0 tclass=file
tcontext=user_u:object_r:var_log_t:s0 tty=(none) uid=0 
avc: denied { getattr } for comm="pm-suspend" dev=sda3 egid=0 euid=0
exe="/bin/bash" exit=-13 fsgid=0 fsuid=0 gid=0 items=0 name="pm-suspend.log"
path="/var/log/pm-suspend.log" pid=3028 scontext=system_u:system_r:hald_t:s0
sgid=0 subj=system_u:system_r:hald_t:s0 suid=0 tclass=file
tcontext=user_u:object_r:var_log_t:s0 tty=(none) uid=0 

Version-Release number of selected component (if applicable):
pm-utils-0.99.3-1.fc7.i386

How reproducible:
Always

-- Additional comment from dwalsh on 2007-04-27 10:39 EST --
Created an attachment (id=153625)
Fix labeling on pm-suspend.log file

This patch will restore the context on the pm-suspend.log file so hal can deal
with it.

Comment 1 Florian La Roche 2007-08-21 14:36:47 UTC
This should take care of bz#245926.

regards,

Florian La Roche


Comment 2 Jay Turner 2007-08-21 14:41:10 UTC
Pulling in flags from 245926, since this fix if required to resolve 245926.

Comment 3 Jay Turner 2007-08-21 14:48:47 UTC
Maybe I'm being stupid, but applying that patch doesn't resolve the problem.

Comment 4 Phil Knirsch 2007-08-21 15:02:35 UTC
I'll give it a shot here as well to see if it works for me.

Read ya, Phil

Comment 5 Phil Knirsch 2007-08-21 15:29:10 UTC
Ok. The patch fixes the issues for those entries:

Aug 21 17:07:23 kfurt setroubleshoot:      SELinux is preventing bash (hald_t)
"getattr" access to /var/log/pm-suspend.log (var_log_t).      For complete
SELinux messages. run sealert -l 907ef732-54e5-4de7-8471-dc3e7509ee78
Aug 21 17:07:23 kfurt setroubleshoot:      SELinux is preventing bash (hald_t)
"write" to pm-suspend.log (var_log_t).      For complete SELinux messages. run
sealert -l 013c2899-0a62-4dd8-883b-b3d08c6a6fbc
Aug 21 17:07:23 kfurt setroubleshoot:      SELinux is preventing bash (hald_t)
"write" to pm-suspend.log (var_log_t).      For complete SELinux messages. run
sealert -l 013c2899-0a62-4dd8-883b-b3d08c6a6fbc

But there are 3 more that come from the 90clock hook script:

Aug 21 17:10:37 kfurt setroubleshoot:      SELinux is preventing 90clock
(hald_t) "getattr" access to /var/run/pm-ntpd.lock (var_run_t).      For
complete SELinux messages. run sealert -l 0b1b84c0-7ddc-4fb5-95bf-d3fb9a62d07d
Aug 21 17:10:37 kfurt setroubleshoot:      SELinux is preventing /bin/touch
(hald_t) "write" to pm-ntpd.lock (var_run_t).      For complete SELinux
messages. run sealert -l a7e98b38-1347-4d7c-aea6-7989689445fb
Aug 21 17:10:37 kfurt last message repeated 3 times
Aug 21 17:10:56 kfurt setroubleshoot:      SELinux is preventing /bin/rm
(hald_t) "unlink" access to pm-ntpd.lock (var_run_t).      For complete SELinux
messages. run sealert -l 030a3083-4d02-414a-ad6c-7795e99a43c0

For which we would need another selinux-policy-targeted entries (same for
pm-ntpd.lock as for pm-suspend.log) as well as the restorecon line in 90clock
after the touch is being done.

Read ya, Phil

Comment 6 Phil Knirsch 2007-08-21 15:31:13 UTC
Nvm, need proper hald_run_t for the 2nd ones ofc, but basically the same fix
/var/run/pm-ntpd.lock like for /var/log/pm-suspend.log.

Read ya, Phi

Comment 7 Daniel Walsh 2007-08-21 15:38:19 UTC
Phil, Are you saying these files are not being created correctly ie with
hald_var_run_t?  Or are you saying they get bad context because the pm stuff
deletes and recreates them?

Comment 8 Phil Knirsch 2007-08-21 15:43:50 UTC
[root@kfurt ICE]# ls -Z /var/run/pm-ntpd.lock
-rw-r--r--  root root user_u:object_r:var_run_t        /var/run/pm-ntpd.lock

So 90clock recreates those files which is typical for lockfiles. And that files
ends up like shown above with the current -83 policy from RHEL-5.1.0.

Checking the current policy only these files get hald_var_run_t flagged:

[root@kfurt ICE]# grep -r hald_var_run_t /etc/selinux/targeted/contexts/
/etc/selinux/targeted//contexts/files/file_contexts:/var/run/haldaemon.pid    
--       system_u:object_r:hald_var_run_t:s0
/etc/selinux/targeted//contexts/files/file_contexts:/var/run/vbestate   --    
system_u:object_r:hald_var_run_t:s0

So seems the file_context for /var/run/pm-ntpd.lock and the appropriate
restorecon in the 90clock script are missing to get rid of those, too.

Read ya, Phil

Comment 9 Jay Turner 2007-08-22 11:50:10 UTC
Just from my prospective, it appears my problems were a combination of older
packages and a hosed up configuration.  So I'm no longer seeing problems coming
out of suspend.  Appear Phil has found additional issues which need to be
resolved, so I'm not monkeying with the bug state.

Comment 10 Jay Turner 2007-08-22 13:07:42 UTC
Actually, should have added that I hacked in the functions change that phil
recommended above, so that might very well be needed to fix things.

Comment 11 Phil Knirsch 2007-08-22 14:30:31 UTC
Yeah, i'll review the current scripts in pm-utils in case we have missed some
log/lockfile somewhere and will be building a new package today with at least
the fixes mentioned here.

Sounds like thats all we need according to Jay's comment #9 and comment #10.

Read ya, Phil

Comment 12 Phil Knirsch 2007-08-22 15:21:58 UTC
Building new packages atm, setting to modified.

Read ya, Phil

Comment 15 Jay Turner 2007-10-02 12:34:59 UTC
And it appears to be back.  Fresh install of the 20070927.0 tree:

selinux-policy-2.4.6-101.el5
pm-utils-0.99.3-6.el5.16

# ls -Z /var/log/pm/suspend.log 
-rw-------  root root system_u:object_r:var_log_t      /var/log/pm/suspend.log

More details to follow.

Comment 16 Jay Turner 2007-10-02 12:55:18 UTC
Reproduced on another fresh installation.  /var/log/pm/suspend.log ends up with
var_log_t context.

Comment 17 Daniel Walsh 2007-10-02 13:42:10 UTC
What does restorecon -R -v /var/log/pm do?

The problem is the directory should be created by the rpm and not created on the
fly.  We can not guarantee which application/script creates the directory.   But
if it is created via rpm, it will get the correct file context.

rpm -qf /var/log/pm
error: file /var/log/pm: No such file or directory


Comment 18 Jay Turner 2007-10-02 14:01:32 UTC
[root@haring ~]# restorecon -R -v /var/log/pm
restorecon reset /var/log/pm context
system_u:object_r:var_log_t:s0->system_u:object_r:pmtools_log_t:s0
restorecon reset /var/log/pm/suspend.log context
system_u:object_r:var_log_t:s0->system_u:object_r:pmtools_log_t:s0
[root@haring ~]# ls -Z /var/log/pm/suspend.log 
-rw-------  root root system_u:object_r:pmtools_log_t  /var/log/pm/suspend.log

I'm not sure if that's the right context, but at least it's different.  All that
having been said, appears that we have a problem in that nothing owns /var/log/pm.

Comment 19 Phil Knirsch 2007-10-02 14:19:21 UTC
Argh. Seems i forgot to package the directory:

%dir /var/log/run

That should fix it the problem.

Quickly building a new package, please reopen the errata to NEED_RESPIN if possible.

Thanks,

Read ya, Phil

Comment 20 Phil Knirsch 2007-10-02 14:38:25 UTC
%dir /var/log/pm ofc



Comment 21 Phil Knirsch 2007-10-02 14:48:17 UTC
I've built pm-utils-0.99.3-6.el5.17 which now package %dir /var/log/pm as well
for testing.

Thanks,

Read ya, Phil

Comment 22 Jay Turner 2007-10-02 15:24:34 UTC
After installing 6.el5.17, the context for /var/log/pm and
/var/log/pm/suspend.log appear to be correct:

[root@et-10 i386]# ls -dZ /var/log/pm 
drwxr-xr-x  root root system_u:object_r:pmtools_log_t  /var/log/pm
[root@et-10 i386]# ls -Z /var/log/pm 
-rw-------  root root system_u:object_r:pmtools_log_t  suspend.log


Comment 23 Phil Knirsch 2007-10-02 15:33:24 UTC
Great! Thanks Jay, and thanks for catching this.

Read ya, Phil

Comment 27 errata-xmlrpc 2007-11-07 16:44:15 UTC
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2007-0538.html



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