Hide Forgot
Description of problem: Since upgrading from Fedora 17 to Fedoar 19 (via fedup) I am seeing the following from SETroubleshoot: ----------------------------- SELinux is preventing /usr/sbin/mdadm from write access on the file /var/log/rear/rear-ws1.log. ***** Plugin restorecon (93.9 confidence) suggests ************************* If you want to fix the label. /var/log/rear/rear-ws1.log default label should be var_log_t. Then you can run restorecon. Do # /sbin/restorecon -v /var/log/rear/rear-ws1.log ***** Plugin leaks (6.10 confidence) suggests ****************************** If you want to ignore mdadm trying to write access the rear-ws1.log file, because you believe it should not need this access. Then you should report this as a bug. You can generate a local policy module to dontaudit this access. Do # grep /usr/sbin/mdadm /var/log/audit/audit.log | audit2allow -D -M mypol # semodule -i mypol.pp ***** Plugin catchall (1.43 confidence) suggests *************************** If you believe that mdadm should be allowed write access on the rear-ws1.log file by default. Then you should report this as a bug. You can generate a local policy module to allow this access. Do allow this access for now by executing: # grep mdadm /var/log/audit/audit.log | audit2allow -M mypol # semodule -i mypol.pp Additional Information: Source Context system_u:system_r:mdadm_t:s0-s0:c0.c1023 Target Context system_u:object_r:cron_log_t:s0 Target Objects /var/log/rear/rear-ws1.log [ file ] Source mdadm Source Path /usr/sbin/mdadm Port <Unknown> Host ws1.webengineer.com Source RPM Packages mdadm-3.2.6-19.fc19.x86_64 Target RPM Packages Policy RPM selinux-policy-3.12.1-59.fc19.noarch Selinux Enabled True Policy Type targeted Enforcing Mode Permissive Host Name ws1.webengineer.com Platform Linux ws1.webengineer.com 3.9.9-301.fc19.x86_64 #1 SMP Thu Jul 4 15:10:36 UTC 2013 x86_64 x86_64 Alert Count 2 First Seen 2013-07-09 01:30:05 PDT Last Seen 2013-07-09 01:30:13 PDT Local ID 9bdcf8cc-fd0f-489f-9bd9-a8d5f034eb2b Raw Audit Messages type=AVC msg=audit(1373358613.735:287): avc: denied { write } for pid=21684 comm="mdadm" path="/var/log/rear/rear-ws1.log" dev="dm-3" ino=2490373 scontext=system_u:system_r:mdadm_t:s0-s0:c0.c1023 tcontext=system_u:object_r:cron_log_t:s0 tclass=file type=SYSCALL msg=audit(1373358613.735:287): arch=x86_64 syscall=execve success=yes exit=0 a0=1cc6460 a1=1cc8d50 a2=1cb4230 a3=8 items=0 ppid=21683 pid=21684 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 ses=18 tty=(none) comm=mdadm exe=/usr/sbin/mdadm subj=system_u:system_r:mdadm_t:s0-s0:c0.c1023 key=(null) Hash: mdadm,mdadm_t,cron_log_t,file,write ------------------------------------------- I believe that whatever package installed the rear package should have set the permissions correctly. Especially during an upgrade. Version-Release number of selected component (if applicable): Fully updated Fedora 19 (as of 7/8/13 8:50 AM How reproducible: Every time mdadm tries to write to that log. Steps to Reproduce: 1. Anytime this machime runs that selinus alert happens 2. 3. Actual results: SELinux alert caused my mdamd writing to log Expected results: No AVC Additional info:
Do you have some kind of cron job that is outputing to /var/log/rear/rear-ws1.log
Can you read /etc/selinux/targeted/policy/policy.29
I assume mdadm was being run by a cron job. Before I followed the instruction for enabling var_log_t I saw the the file mentioned had cron_log_t access. Now it is var_log_t. The file /etc/selinux/targeted/policy/policy.29 appears to be a binary file. What app should I use to view it.
Emmet ignore commend about policy.29 meant for a different bugzilla. With the label of var_log_t it would still be blocked, have you seen new AVCs
No I haven't. And checking the log I found that it was written to this morning, so it seems to have been resolved by the change to var_log_t.
I take it back. It is not fixed as I saw this alert again yesterday.
And I take that last back. Turns out someting changed it back to cron_log_t [emmett@ws1 rear]$ ls -Z -rw-r--r--. root root system_u:object_r:cron_log_t:s0 rear-ws1.log -rw-r--r--. root root system_u:object_r:cron_log_t:s0 rear-ws1.log.lockless -rw-r--r--. root root system_u:object_r:cron_log_t:s0 rear-ws1.log.lockless.old -rw-r--r--. root root system_u:object_r:cron_log_t:s0 rear-ws1.log.old And I am still seeing this once each day.
Any chance to look on your cron jobs if there is a job handling /var/log/rear/rear-ws1.log?
This is the first I have ever heard of the package named 'rear'. I have no idea why mdadm on your system would try to write to this file - mdadm should have no knowledge of it at all. Could you please verify that your /etc/mdadm.conf doesn't try to point it there? Jes
I don't think this has anything to do with mdadm, I think the rear package is redirecting output of its cron jobs to /var/log/rear/rear-ws1.log? via a write and mdadm is just getting handed this as standard out. SELinux does not like this so it blocks the write access. If rear had opened the file for append then it probably would work fine.
There is nothing in mdadm.conf regarding rear. I checked the /root/install.log and found that rear was install November 20, which is wierd since I skipped Fedora 18. This didn't start happening until I upgraded my feddora 17 workstation to fedora 19 via fedup. I see no reference to rear-ws1.log in any file in /etc
Daniel, I agree - I tried installing rear here on my test system, but I still wasn't able to reproduce the problem. Admittedly I didn't do much besides installing the rpm. Cheers, Jes
Did a test on Fedora 19 with rear executing from cron: $ ls -lZ /var/log/rear/ -rw-r--r--. root root system_u:object_r:cron_log_t:s0 rear-fedora19.log -rw-r--r--. root root unconfined_u:object_r:var_log_t:s0 rear-fedora19.log.old and afterwards, ran rear manually again: $ ls -lZ /var/log/rear/ -rw-r--r--. root root unconfined_u:object_r:var_log_t:s0 rear-fedora19.log -rw-r--r--. root root system_u:object_r:cron_log_t:s0 rear-fedora19.log.old I did not get an error whatsoever. The /var/log/rear directory itself has the settings: $ ls -ldZ /var/log/rear drwxr-xr-x. root root unconfined_u:object_r:var_log_t:s0 /var/log/rear
couldn't reproduce the error report - sorry - bug report is just hanging here - we better close it and re-open it if required.