Hide Forgot
Description of problem: SELinux avoids logrotate if /var/lib/logrotate.status is a symlink due to DRBD/drbdlinks. [root@web1 ~]# ls -l /var/lib/logrotate.status lrwxrwxrwx. 1 root root 30 8. Jul 14:24 /var/lib/logrotate.status -> /data/var/lib/logrotate.status [root@web1 ~]# [root@web1 ~]# ls -lZ /var/lib/logrotate.status lrwxrwxrwx. root root system_u:object_r:logrotate_var_lib_t:s0 /var/lib/logrotate.status -> /data/var/lib/logrotate.status [root@web1 ~]# [root@web1 ~]# ls -l /data/var/lib/logrotate.status -rw-r--r--. 1 root root 597 8. Jul 03:40 /data/var/lib/logrotate.status [root@web1 ~]# [root@web1 ~]# ls -lZ /data/var/lib/logrotate.status -rw-r--r--. root root system_u:object_r:logrotate_var_lib_t:s0 /data/var/lib/logrotate.status [root@web1 ~]# Version-Release number of selected component (if applicable): logrotate-3.7.8-12.el6_0.1.x86_64 selinux-policy-3.7.19-93.el6.noarch selinux-policy-targeted-3.7.19-93.el6.noarch How reproducible: Everytime, see above. Actual results: SELinux avoids logrotate if /var/lib/logrotate.status is a symlink due to DRBD/drbdlinks Expected results: No AVC denied, just working. Additional info: type=AVC msg=audit(1310435293.365:185692): avc: denied { read } for pid=530 comm="logrotate" name="logrotate.status" dev=sda1 ino=392480 scontext=system_u:system_r:logrotate_t:s0-s0:c0.c1023 tcontext=system_u:object_r:logrotate_var_lib_t:s0 tclass=lnk_file type=SYSCALL msg=audit(1310435293.365:185692): arch=c000003e syscall=4 success=no exit=-13 a0=40a22e a1=7fff63d64930 a2=7fff63d64930 a3=e8 items=0 ppid=528 pid=530 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=2573 comm="logrotate" exe="/usr/sbin/logrotate" subj=system_u:system_r:logrotate_t:s0-s0:c0.c1023 key=(null)
Even though this looks like local customization, I have no problem with logrotate being allowed to read the link.
This is a local customization that is required in order to use drbdlinks, which is from EPEL. Drbdlinks is linking files and directories to a DRBD partition, which ensures that the primary system always has the same data no matter on which machine it is physically running. A solution could be a drbdlinks policy which has a SELinux boolean flag that can be triggered and once it's set to "on" it allows symlinking of files like this one. Alternatively you could allow this always, but that might allow symlink attacks? I've cross-filed this issue as Service Request 506722.
Fixed in selinux-policy-3.7.19-104.el6
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. http://rhn.redhat.com/errata/RHBA-2011-1511.html