Bug 982715 - SELinux is preventing /usr/sbin/mdadm from write access on the file /var/log/rear/rear-ws1.log
SELinux is preventing /usr/sbin/mdadm from write access on the file /var/log/...
Status: CLOSED WORKSFORME
Product: Fedora
Classification: Fedora
Component: rear (Show other bugs)
19
x86_64 Linux
unspecified Severity low
: ---
: ---
Assigned To: Gratien D'haese
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-07-09 12:20 EDT by Emmett Culley
Modified: 2013-12-23 06:47 EST (History)
8 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-12-23 06:47:32 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Emmett Culley 2013-07-09 12:20:43 EDT
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:
Comment 1 Daniel Walsh 2013-07-09 16:13:53 EDT
Do you have some kind of cron job that is outputing to /var/log/rear/rear-ws1.log
Comment 2 Daniel Walsh 2013-07-09 16:29:01 EDT
 Can you read /etc/selinux/targeted/policy/policy.29
Comment 3 Emmett Culley 2013-07-09 18:22:58 EDT
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.
Comment 4 Daniel Walsh 2013-07-10 19:16:33 EDT
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
Comment 5 Emmett Culley 2013-07-10 21:50:13 EDT
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.
Comment 6 Emmett Culley 2013-07-12 14:09:07 EDT
I take it back.  It is not fixed as I saw this alert again yesterday.
Comment 7 Emmett Culley 2013-07-13 13:33:12 EDT
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.
Comment 8 Miroslav Grepl 2013-07-15 01:52:09 EDT
Any chance to look on your cron jobs if there is a job handling /var/log/rear/rear-ws1.log?
Comment 9 Jes Sorensen 2013-07-15 03:55:49 EDT
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
Comment 10 Daniel Walsh 2013-07-15 17:41:55 EDT
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.
Comment 11 Emmett Culley 2013-07-15 23:09:12 EDT
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
Comment 12 Jes Sorensen 2013-07-16 04:17:56 EDT
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
Comment 13 Gratien D'haese 2013-07-19 04:22:22 EDT
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
Comment 14 Gratien D'haese 2013-12-23 06:47:32 EST
couldn't reproduce the error report - sorry - bug report is just hanging here - we better close it and re-open it if required.

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