Description of problem: Summary: SELinux is preventing ntpd(/usr/sbin/ntpd) (ntpd_t) "write" to /var/log/pm-suspend.log (var_log_t). Detailed Description: SELinux is preventing ntpd(/usr/sbin/ntpd) (ntpd_t) "write" to /var/log/pm-suspend.log (var_log_t). The SELinux type var_log_t, is a generic type for all files in the directory and very few processes (SELinux Domains) are allowed to write to this SELinux type. This type of denial usual indicates a mislabeled file. By default a file created in a directory has the gets the context of the parent directory, but SELinux policy has rules about the creation of directories, that say if a process running in one SELinux Domain (D1) creates a file in a directory with a particular SELinux File Context (F1) the file gets a different File Context (F2). The policy usually allows the SELinux Domain (D1) the ability to write, unlink, and append on (F2). But if for some reason a file (/var/log/pm-suspend.log) was created with the wrong context, this domain will be denied. The usual solution to this problem is to reset the file context on the target file, restorecon -v /var/log/pm-suspend.log. If the file context does not change from var_log_t, then this is probably a bug in policy. Please file a bug report (http://bugzilla.redhat.com/bugzilla/enter_bug.cgi) against the selinux-policy package. If it does change, you can try your application again to see if it works. The file context could have been mislabeled by editing the file or moving the file from a different directory, if the file keeps getting mislabeled, check the init scripts to see if they are doing something to mislabel the file. Allowing Access: You can attempt to fix file context by executing restorecon -v /var/log/pm-suspend.log The following command will allow this access: restorecon /var/log/pm-suspend.log Additional Information: Source Context system_u:system_r:ntpd_t Target Context system_u:object_r:var_log_t Target Objects /var/log/pm-suspend.log [ file ] Source ntpd(/usr/sbin/ntpd) Port <Unknown> Host narcis Source RPM Packages Target RPM Packages pm-utils-0.99.4-6.fc8 Policy RPM selinux-policy-3.0.8-76.fc8 Selinux Enabled True Policy Type targeted MLS Enabled True Enforcing Mode Enforcing Plugin Name mislabeled_file Host Name narcis Platform Linux narcis 2.6.23.14-115.fc8 #1 SMP Mon Jan 21 14:20:50 EST 2008 i686 i686 Alert Count 6 First Seen Fri 18 Jan 2008 08:36:52 AM CET Last Seen Sun 27 Jan 2008 11:21:18 PM CET Local ID ace2dc22-9a8c-4d38-94d2-9ac5e1d2fcc4 Line Numbers Raw Audit Messages host=narcis type=AVC msg=audit(1201472478.275:254): avc: denied { write } for pid=8183 comm="ntpd" path="/var/log/pm-suspend.log" dev=dm-2 ino=819254 scontext=system_u:system_r:ntpd_t:s0 tcontext=system_u:object_r:var_log_t:s0 tclass=file host=narcis type=AVC msg=audit(1201472478.275:254): avc: denied { write } for pid=8183 comm="ntpd" path="/var/log/pm-suspend.log" dev=dm-2 ino=819254 scontext=system_u:system_r:ntpd_t:s0 tcontext=system_u:object_r:var_log_t:s0 tclass=file host=narcis type=SYSCALL msg=audit(1201472478.275:254): arch=40000003 syscall=11 success=yes exit=0 a0=97df948 a1=97def60 a2=97dfe80 a3=0 items=0 ppid=8182 pid=8183 auid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) comm="ntpd" exe="/usr/sbin/ntpd" subj=system_u:system_r:ntpd_t:s0 key=(null) Version-Release number of selected component (if applicable): ntp-4.2.4p2-6.fc8 pm-utils-0.99.4-6.fc8 selinux-policy-targeted-3.0.8-81.fc8 How reproducible: 100% Steps to Reproduce: 1.suspend to disk 2. 3. Actual results: setroubleshoot complains Expected results: everything goes smoothly Additional info: audit2allow generated me this local policy: module crazyNTPWriteToSuspendLog 1.0; require { type var_log_t; type ntpd_t; class file write; } #============= ntpd_t ============== allow ntpd_t var_log_t:file write; crazyNTPWriteToSuspendLog.te (END) However, I am almost 100% persuaded that creating such policy is wrong. When looking into /var/log/pm-suspend.log it is obvious what is the problem -- the log messages "Starting/Stopping ntpd: [OK]" are written to the log, which seems to me wrong. However, I don't know exactly how to persuade /etc/init.d/ntp script to be totally quiet, so filing this bug without any real resolution.
Let's see what the selinux masters think about this.
I don't think this is Dan's problem -- I really think that printout is useless and shouldn't be there in the first place.
restorecon -R -v /var/log Whatever/Whoever create /var/log/pm-suspend.log created it with the wrong context. Allowing apps to write to var_log_t, would allow a compromised applications to zero out /var/log/messages.
(In reply to comment #3) > restorecon -R -v /var/log > > Whatever/Whoever create /var/log/pm-suspend.log created it with the wrong > context. Allowing apps to write to var_log_t, would allow a compromised > applications to zero out /var/log/messages. Well, [root@narcis ~]# restorecon -v -R /var/log/ [root@narcis ~]# ls -lZ /var/log/pm-suspend.log -rw-rw-r-- root root system_u:object_r:hald_log_t /var/log/pm-suspend.log [root@narcis ~]# if there is something which needs to be fixed by restorecon, it didn't happen apparently.
(In reply to comment #4) > [root@narcis ~]# restorecon -v -R /var/log/ > [root@narcis ~]# ls -lZ /var/log/pm-suspend.log > -rw-rw-r-- root root system_u:object_r:hald_log_t /var/log/pm-suspend.log > [root@narcis ~]# > > if there is something which needs to be fixed by restorecon, it didn't happen > apparently. What do you mean? In the initial report /var/log/pm-suspend.log had type var_log_t, at after restorecon it is hald_log_t. Do you experience problems now after restorecon?
Oh, I see -- I was confused by the silence of restorecon. OK, I will put myself in NEEDINFO and will let you know if something bad happens.
This probably means that the file had already had it's file context corrected. pm-utils I believe runs restorecon when it recreates the file.