Bug 1131460

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

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.

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

What AVCs do you see if the /var/log/core directory is labeled var_log_t?

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?

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"
#

Other types which match both criteria mentioned in comment#3 are:
 * qemu_var_run_t
 * tmp_t
 * var_run_t

which one do you recommend using on the /var/log/core/* ?
So that it won't create any security breaches... ?

I would recommend using qemu_var_run_t as a workaround, until somebody comes with a better solution.

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

Danken, please advise

My advise is to integrate with "abrt" ;-)

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

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?

Yes, if there's a valid SELinux fix for 7.1, it should be backported to 7.0.z (and 6.6.z).

*** Bug 1066407 has been marked as a duplicate of this bug. ***

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.

Still waiting for backport of selinux-policy fix to 6.6.z and 6.7

*** Bug 1040177 has been marked as a duplicate of this bug. ***

# 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

IMO you should unlink BZ917062 from dependency as this BZ obviously does not wait for ABRT and tries to solve the issue now.

Were there any SELinux denials?

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

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)

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.

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')?

'su vdsm kvm' is in the configuration for logrotate for many years now.

Jiri, I see you have opened https://bugzilla.redhat.com/show_bug.cgi?id=1265547.
So can we close this as verified?

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!

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