Red Hat Bugzilla – Bug 253722
/var/log/pm-suspend.log keeps getting the wrong selinux context
Last modified: 2015-03-04 20:19:07 EST
+++ 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.
This should take care of bz#245926. regards, Florian La Roche
Pulling in flags from 245926, since this fix if required to resolve 245926.
Maybe I'm being stupid, but applying that patch doesn't resolve the problem.
I'll give it a shot here as well to see if it works for me. Read ya, Phil
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
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
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?
[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
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.
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.
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
Building new packages atm, setting to modified. Read ya, Phil
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.
Reproduced on another fresh installation. /var/log/pm/suspend.log ends up with var_log_t context.
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
[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.
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
%dir /var/log/pm ofc
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
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
Great! Thanks Jay, and thanks for catching this. Read ya, Phil
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