Bug 253722 - /var/log/pm-suspend.log keeps getting the wrong selinux context
/var/log/pm-suspend.log keeps getting the wrong selinux context
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: pm-utils (Show other bugs)
5.1
All Linux
medium Severity medium
: ---
: ---
Assigned To: Phil Knirsch
: Desktop
Depends On: 238068
Blocks:
  Show dependency treegraph
 
Reported: 2007-08-21 10:33 EDT by Florian La Roche
Modified: 2015-03-04 20:19 EST (History)
4 users (show)

See Also:
Fixed In Version: RHBA-2007-0538
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-11-07 11:44:15 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Florian La Roche 2007-08-21 10:33:07 EDT
+++ 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@redhat.com 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 10:36:47 EDT
This should take care of bz#245926.

regards,

Florian La Roche
Comment 2 Jay Turner 2007-08-21 10:41:10 EDT
Pulling in flags from 245926, since this fix if required to resolve 245926.
Comment 3 Jay Turner 2007-08-21 10:48:47 EDT
Maybe I'm being stupid, but applying that patch doesn't resolve the problem.
Comment 4 Phil Knirsch 2007-08-21 11:02:35 EDT
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 11:29:10 EDT
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 11:31:13 EDT
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 11:38:19 EDT
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 11:43:50 EDT
[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 07:50:10 EDT
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 09:07:42 EDT
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 10:30:31 EDT
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 11:21:58 EDT
Building new packages atm, setting to modified.

Read ya, Phil
Comment 15 Jay Turner 2007-10-02 08:34:59 EDT
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 08:55:18 EDT
Reproduced on another fresh installation.  /var/log/pm/suspend.log ends up with
var_log_t context.
Comment 17 Daniel Walsh 2007-10-02 09:42:10 EDT
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 10:01:32 EDT
[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 10:19:21 EDT
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 10:38:25 EDT
%dir /var/log/pm ofc

Comment 21 Phil Knirsch 2007-10-02 10:48:17 EDT
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 11:24:34 EDT
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 11:33:24 EDT
Great! Thanks Jay, and thanks for catching this.

Read ya, Phil
Comment 27 errata-xmlrpc 2007-11-07 11:44:15 EST
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.