Bug 1131460 - vdsm package causes logrotate to trigger selinux AVC alerts
Summary: vdsm package causes logrotate to trigger selinux AVC alerts
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: vdsm
Version: 3.4.1-1
Hardware: x86_64
OS: Linux
unspecified
low
Target Milestone: ovirt-3.6.1
: 3.6.0
Assignee: Oved Ourfali
QA Contact: Jiri Belka
URL:
Whiteboard:
: 1040177 1066407 (view as bug list)
Depends On: 917062 1064322 1064326 1153333 1159834 1220860
Blocks: 1195113
TreeView+ depends on / blocked
 
Reported: 2014-08-19 10:49 UTC by Barak Korren
Modified: 2016-03-09 19:24 UTC (History)
17 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
: 1195113 (view as bug list)
Environment:
Last Closed: 2016-03-09 19:24:25 UTC
oVirt Team: Infra
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2016:0362 normal SHIPPED_LIVE vdsm 3.6.0 bug fix and enhancement update 2016-03-09 23:49:32 UTC
oVirt gerrit 33667 master ABANDONED spec: set a different label for /var/log/core/* Never
oVirt gerrit 36861 master MERGED spec: require selinux that allows logrotate to manage virt_cache Never
oVirt gerrit 37194 ovirt-3.5 MERGED spec: require selinux that allows logrotate to manage virt_cache Never

Description Barak Korren 2014-08-19 10:49:49 UTC
Description of problem:

The "/var/log/core/" directory is created by the "vdsm" package as well as the "/etc/logrotate.d/vdsm" file that configures logrotate to clean it up. However, the selinux label set for that directory prevents logrotate from reading it. This in turn causes the following AVC alerts to be triggered by the logrotate nightly run:

type=AVC msg=audit(1408438861.907:577): avc:  denied  { read } for  pid=11361 comm="logrotate" name="core" dev=dm-1 ino=289949 scontext=system_u:system_r:logrotate_t:s0-s0:c0.c1023 tcontext=system_u:object_r:virt_cache_t:s0 tclass=dir

type=SYSCALL msg=audit(1408438861.907:577): arch=x86_64 syscall=open success=no exit=EACCES a0=7fff8d58b300 a1=90800 a2=8a781e a3=fffffffffffffff0 items=0 ppid=11359 pid=11361 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=90 comm=logrotate exe=/usr/sbin/logrotate subj=system_u:system_r:logrotate_t:s0-s0:c0.c1023 key=(null)


Version-Release number of selected component (if applicable):
Package version: 4.14.13-1.el6ev

How reproducible:
Easily

Steps to Reproduce:
1. Install RHEL6.5 wiht selinux in enforcing/targeted mode
2. Install the vdsm package
3. Wait for the nightly logrotate run

Actual results:
AVC alerts logged to the audit.log file

Expected results:
No alerts

Comment 1 Yeela Kaplan 2014-10-01 15:17:29 UTC
This depends on the following selinux-policy bug:

Bug 1064326 - SELinux prevents logrotate from reading /var/log/core directory

This bug is in VERIFIED state, and been fixed in version:

selinux-policy-3.7.19-249.el6

Comment 2 Milos Malik 2014-10-02 09:05:53 UTC
During the installation of vdsm packages the /var/log/core directory gets a new labeling. If you remove the semanage command from the rpm scriptlets, the AVC will go away and the /var/log/core directory will be labeled var_log_t, which is OK. The other option is to apply virt_log_t label instead of virt_cache_t as described in BZ#1066407.

Comment 3 Yeela Kaplan 2014-10-06 08:50:32 UTC
Milos,
We need in vdsm both libvirt to access /var/log/core so it can create the core dump,
and we also need logrotate to access /var/log/core...
Is there a way to change the selinux-policy itself to allow this?

Because using a vdsm hack to change the label to either virt_cache_t or virt_log_t seems wrong....

and using var_log_t won't allow libvirt the access...

thanks

Comment 4 Milos Malik 2014-10-06 09:13:17 UTC
What AVCs do you see if the /var/log/core directory is labeled var_log_t?

Comment 5 Yeela Kaplan 2014-10-06 11:52:35 UTC
You can see the AVCs in the following bug (comment 16):

https://bugzilla.redhat.com/show_bug.cgi?id=1005031#c16

Due to this bug the semanage hack was added to vdsm.

according to the following comment:
https://bugzilla.redhat.com/show_bug.cgi?id=1005031#c19

It does not show a virt_log_t tag that libvirt can write to...
where can I find all these tags specifics?

Reading the following comments I can see that there was a discussion there with selinux guys claiming it's not a bug... 
what do you think?

Comment 6 Milos Malik 2014-10-06 13:09:47 UTC
So far I found just 2 types which match both criteria mentioned in comment#3, but I don't recommend using any of them:

 * cifs_t
 * nfs_t

# for I in `seinfo -t | sort` ; do
    COUNT=0
    sesearch -s svirt_t -t $I -c dir -p write -A -C | grep -q allow && let "COUNT += 1"
    sesearch -s logrotate_t -t $I -c dir -p read -A -C | grep -q allow && let "COUNT += 1"
    echo "$I: $COUNT"
done | grep ": 2"
#

Comment 7 Milos Malik 2014-10-06 13:33:54 UTC
Other types which match both criteria mentioned in comment#3 are:
 * qemu_var_run_t
 * tmp_t
 * var_run_t

Comment 8 Yeela Kaplan 2014-10-07 11:30:18 UTC
which one do you recommend using on the /var/log/core/* ?
So that it won't create any security breaches... ?

Comment 9 Milos Malik 2014-10-07 12:28:47 UTC
I would recommend using qemu_var_run_t as a workaround, until somebody comes with a better solution.

Comment 10 Yeela Kaplan 2014-10-14 11:10:48 UTC
Milos,
Trying qemu_var_run_t on /var/log/core/* causes a lot of AVC denials...
I've tried audit2allow on one of them:

audit2allow -a 'type=AVC msg=audit(1413284480.844:105463): avc:  denied  { write } for  pid=17679 comm="logrotate" name="core.9951.1399914966.dump" dev=dm-0 ino=1057687 scontext=system_u:system_r:logrotate_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:qemu_var_run_t:s0 tclass=file'

#============= logrotate_t ==============
allow logrotate_t qemu_var_run_t:file write;
allow logrotate_t virt_cache_t:dir read;


Looks like it's not the solution we're looking for... 
what do you think? 
do you have any new ideas?
thanks

Comment 11 Barak 2014-10-21 12:03:18 UTC
Danken, please advise

Comment 12 Dan Kenigsberg 2014-10-21 13:21:24 UTC
My advise is to integrate with "abrt" ;-)

Until that happens, maybe Miroslav can suggest an SELinux label trick not mentioned earlier?

Comment 13 Yeela Kaplan 2014-10-22 13:25:04 UTC
This is also reproduced for RHEL 6.6 and RHEL 7.0.

The fix is contained in the RHEl-7.1 selinux-policy (can be seen it the following bug: https://bugzilla.redhat.com/show_bug.cgi?id=1064322)

We could file a bug to selinux-policy to backport it for RHEL-7.0.


I think a good option would be to open a bug on RHEL 7.0 so it'll be backported.
 and for RHEL 6.5/6.6 there is already a bug opened ( https://bugzilla.redhat.com/show_bug.cgi?id=1153333) , which we can escalate its severity to cause it to be backported to EL6.6...



Barak/ Dan, what do you think?

Comment 14 Dan Kenigsberg 2014-10-22 13:55:30 UTC
Yes, if there's a valid SELinux fix for 7.1, it should be backported to 7.0.z (and 6.6.z).

Comment 15 Yaniv Bronhaim 2014-10-27 13:43:54 UTC
*** Bug 1066407 has been marked as a duplicate of this bug. ***

Comment 16 Barak 2015-01-06 12:38:28 UTC
It looks like we have all dependency releases accomplished (6.6 , 6.7, 7.1 & 7.0.z), Yeela please verify and add the required dependency.

Comment 17 Yeela Kaplan 2015-01-08 13:50:19 UTC
Still waiting for backport of selinux-policy fix to 6.6.z and 6.7

Comment 18 Yaniv Bronhaim 2015-01-12 16:56:40 UTC
*** Bug 1040177 has been marked as a duplicate of this bug. ***

Comment 21 Jiri Belka 2015-06-25 10:21:46 UTC
# strace -ff -o /tmp/out /etc/cron.hourly/vdsm-logrotate
error: error opening /var/log/core/core.1269.1435222664.dump: Permission denied
error: error opening /var/log/core/core.519.1435222212.dump: Permission denied
error: error creating output file /var/lib/logrotate.status.tmp: Read-only file system

Does _not_ work because /etc/vdsm/logrotate/vdsm (vdsm-4.17.0-1028.git7f5e1f2.el7.noarch) contains:

# tail -n2 /etc/vdsm/logrotate/vdsm 
    su vdsm kvm
}

which causes:

setresgid(-1, 36, -1)                   = 0
setresuid(-1, 36, -1)                   = 0
...snip...
getxattr("/var/log/core/core.1269.1435222664.dump", "security.selinux", "system_u:object_r:virt_cache_t:s0", 255) = 34
open("/proc/self/task/2760/attr/fscreate", O_RDONLY|O_CLOEXEC) = 3
read(3, "", 4095)                       = 0
close(3)                                = 0
open("/proc/self/task/2760/attr/fscreate", O_RDWR|O_CLOEXEC) = 3
write(3, "system_u:object_r:virt_cache_t:s"..., 34) = 34
close(3)                                = 0
rename("/var/log/core/core.1269.1435222664.dump.1.xz", "/var/log/core/core.1269.1435222664.dump.2.xz") = -1 ENOENT (No such file or directory)
rename("/var/log/core/core.1269.1435222664.dump.0.xz", "/var/log/core/core.1269.1435222664.dump.1.xz") = -1 ENOENT (No such file or directory)
access("/var/log/core/core.1269.1435222664.dump.2.xz", F_OK) = -1 ENOENT (No such file or directory)
open("/var/log/core/core.1269.1435222664.dump", O_RDWR|O_NOFOLLOW) = -1 EACCES (Permission denied)
open("/usr/share/locale/locale.alias", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/usr/share/locale/en_US.utf8/LC_MESSAGES/libc.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/share/locale/en_US/LC_MESSAGES/libc.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/share/locale/en.utf8/LC_MESSAGES/libc.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/share/locale/en/LC_MESSAGES/libc.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
write(2, "error: ", 7)                  = 7
write(2, "error opening /var/log/core/core"..., 73) = 73
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=118, ...}) = 0
getxattr("/var/log/core/core.519.1435222212.dump", "security.selinux", "system_u:object_r:virt_cache_t:s0", 255) = 34
rename("/var/log/core/core.519.1435222212.dump.1.xz", "/var/log/core/core.519.1435222212.dump.2.xz") = -1 ENOENT (No such file or directory)
rename("/var/log/core/core.519.1435222212.dump.0.xz", "/var/log/core/core.519.1435222212.dump.1.xz") = -1 ENOENT (No such file or directory)
access("/var/log/core/core.519.1435222212.dump.2.xz", F_OK) = -1 ENOENT (No such file or directory)
open("/var/log/core/core.519.1435222212.dump", O_RDWR|O_NOFOLLOW) = -1 EACCES (Permission denied)
write(2, "error: ", 7)                  = 7
write(2, "error opening /var/log/core/core"..., 72) = 72

Thus 'su vdsm kvm' causes setres(uid|gid) syscall and then logrotate can't read dump files:

error: error opening /var/log/core/core.1269.1435222664.dump: Permission denied
error: error opening /var/log/core/core.519.1435222212.dump: Permission denied

Solution is either remove 'su vdsm kvm' or to change mask for files which are going to be created in /var/log/core.

The rest is OK.

# sesearch -s logrotate_t -c file -Ad | grep virt_cache_t
   allow logrotate_t virt_cache_t : file { ioctl read write create getattr setattr lock append unlink link rename open } ;

# rpm --scripts -q vdsm | sed -n '32,38p'
# hack until we replace core dump with abrt
if /usr/sbin/selinuxenabled; then
    /usr/sbin/semanage fcontext -a -t virt_cache_t '/var/log/core(/.*)?'
fi
/sbin/restorecon -R /var/log/core >/dev/null 2>&1
# hack until we replace core dump with abrt

# ls -ldZ /var/log/core
drwxrwxrwt. root root system_u:object_r:virt_cache_t:s0 /var/log/core

# find /var/log/core/
/var/log/core/
/var/log/core/core.1269.1435222664.dump
/var/log/core/core.519.1435222212.dump

-bash-4.2$ ls -lZ /var/log/core/
-rw-------. qemu qemu system_u:object_r:virt_cache_t:s0 core.21142.1435224772.dump
-bash-4.2$ file /var/log/core/core.21142.1435224772.dump 
/var/log/core/core.21142.1435224772.dump: regular file, no read permission
-bash-4.2$ id
uid=36(vdsm) gid=36(kvm) groups=36(kvm),107(qemu),179(sanlock) context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023

Comment 22 Jiri Belka 2015-06-25 10:23:04 UTC
IMO you should unlink BZ917062 from dependency as this BZ obviously does not wait for ABRT and tries to solve the issue now.

Comment 23 Milos Malik 2015-06-25 10:38:49 UTC
Were there any SELinux denials?

# ausearch -m avc -m user_avc -m selinux_err -i -ts today

Comment 24 Jiri Belka 2015-06-25 11:32:45 UTC
You were reading wrong #21.

It's usual UNIX DAC involved... See 'su vdsm kvm' part, that's why 'setresuid/gid' is get involved.

setresgid(-1, 36, -1)                   = 0
setresuid(-1, 36, -1)                   = 0

see setresuid(2) and it explains:

open("/var/log/core/core.519.1435222212.dump", O_RDWR|O_NOFOLLOW) = -1 EACCES (Permission denied)

Comment 25 Yeela Kaplan 2015-09-24 15:05:23 UTC
Jiri, 
The issue you are raising is related to UNIX DAC and different from the original one, caused by selinux policy.

I think that you should open a new bug for this new issue and we'll handle it separately.

Comment 26 Jiri Belka 2015-10-11 20:40:41 UTC
It seems logrotate script was working fine in the past https://bugzilla.redhat.com/show_bug.cgi?id=1195113#c2 Could you check history of the script (especially 'su vdsm kvm')?

Comment 27 Yeela Kaplan 2015-10-14 10:46:06 UTC
'su vdsm kvm' is in the configuration for logrotate for many years now.

Comment 28 Yeela Kaplan 2015-10-14 11:08:42 UTC
Jiri, I see you have opened https://bugzilla.redhat.com/show_bug.cgi?id=1265547.
So can we close this as verified?

Comment 29 Jiri Belka 2015-10-23 16:06:36 UTC
IMO you can close this BZ because BZ1195113 related to selinux policy was already shipped long time ago and there is _NO_ issue with selinux.

But there's an issue with UNIX DAC.

[root@dell-r210ii-04 core]# ls -l
total 52960
-rw-------. 1 qemu qemu 1269874688 Oct 23 17:39 core.15104.1445614743.dump

^^^ WORKAROUND: to bypass an issue with DAC (BZ1265547) I changed owner:group to 'vdsm:kvm'. If there would be selinux issue it would fail but it did not.

[root@dell-r210ii-04 core]# chown vdsm:kvm core.15104.1445614743.dump 
[root@dell-r210ii-04 core]# ls -l
total 52960
-rw-------. 1 vdsm kvm 1269874688 Oct 23 17:39 core.15104.1445614743.dump
[root@dell-r210ii-04 core]# ls -lZ
-rw-------. vdsm kvm system_u:object_r:virt_cache_t:s0 core.15104.1445614743.dump
[root@dell-r210ii-04 core]# logrotate -v -f /etc/vdsm/logrotate/vdsm 2>&1 | sed -n '/^rotating pattern: \/var\/log\/core/,$p'                                                                                       
rotating pattern: /var/log/core/*.dump  forced from command line (1 rotations)
empty log files are rotated, old logs are removed
switching euid to 36 and egid to 36
considering log /var/log/core/core.15104.1445614743.dump
  log needs rotating
rotating log /var/log/core/core.15104.1445614743.dump, log->rotateCount is 1
dateext suffix '-20151023'
glob pattern '-[0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9]'
renaming /var/log/core/core.15104.1445614743.dump.1.xz to /var/log/core/core.15104.1445614743.dump.2.xz (rotatecount 1, logstart 1, i 1), 
old log /var/log/core/core.15104.1445614743.dump.1.xz does not exist
renaming /var/log/core/core.15104.1445614743.dump.0.xz to /var/log/core/core.15104.1445614743.dump.1.xz (rotatecount 1, logstart 1, i 0), 
old log /var/log/core/core.15104.1445614743.dump.0.xz does not exist
log /var/log/core/core.15104.1445614743.dump.2.xz doesn't exist -- won't try to dispose of it
fscreate context set to system_u:object_r:virt_cache_t:s0
renaming /var/log/core/core.15104.1445614743.dump to /var/log/core/core.15104.1445614743.dump.1
compressing log with: /usr/bin/xz
switching uid to 36 and gid to 36
switching euid to 0 and egid to 0
set default create context


Please read also again #22, useless BZ is still linked to this one!

Comment 32 errata-xmlrpc 2016-03-09 19:24:25 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHBA-2016-0362.html


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