Description of problem: A customer is using rotatelogs (httpd_rotatelogs_t) to process the HTTP logs, which is the standard tool shipped within the httpd package. For convenience, he instructed rotatelogs to process files accessed through using /etc/httpd/logs path which is a symlink to "../../var/log/httpd". For some unclear reason, there is no rule to allow this: -------- 8< ---------------- 8< ---------------- 8< ---------------- 8< -------- # ls -Z /etc/httpd/logs lrwxrwxrwx. root root system_u:object_r:httpd_log_t:s0 /etc/httpd/logs -> ../../var/log/httpd -------- 8< ---------------- 8< ---------------- 8< ---------------- 8< -------- AVC: -------- 8< ---------------- 8< ---------------- 8< ---------------- 8< -------- allow httpd_rotatelogs_t httpd_log_t : lnk_file { ioctl read getattr lock } ; -------- 8< ---------------- 8< ---------------- 8< ---------------- 8< -------- Browsing the rawhide policy, in ancient times there was the rule in the policy: -------- 8< ---------------- 8< ---------------- 8< ---------------- 8< -------- read_lnk_files_pattern(httpd_rotatelogs_t, httpd_log_t, httpd_log_t) -------- 8< ---------------- 8< ---------------- 8< ---------------- 8< -------- This was introduced by the following commit: -------- 8< ---------------- 8< ---------------- 8< ---------------- 8< -------- commit 3e3d1c7188c45831a36e2add27c54ab74a8ed338 Author: Dominick Grift <dominick.grift> Date: Mon Sep 17 23:58:11 2012 +0200 -------- 8< ---------------- 8< ---------------- 8< ---------------- 8< -------- It was there until commit 7054491bc92b356a5e2e14207a4dcdd02539fb51: -------- 8< ---------------- 8< ---------------- 8< ---------------- 8< -------- $ git show 7054491bc:apache.te | grep -A1 "manage_files_pattern(httpd_rotatelogs_t" manage_files_pattern(httpd_rotatelogs_t, httpd_log_t, httpd_log_t) read_lnk_files_pattern(httpd_rotatelogs_t, httpd_log_t, httpd_log_t) -------- 8< ---------------- 8< ---------------- 8< ---------------- 8< -------- But it disappeared when the tree having the above commit was merged (2b369a4fd48155ca5de5e0373b11287116ed95f9) -------- 8< ---------------- 8< ---------------- 8< ---------------- 8< -------- $ git show 2b369a4fd:apache.te | grep -A1 "manage_files_pattern(httpd_rotatelogs_t" manage_files_pattern(httpd_rotatelogs_t, httpd_log_t, httpd_log_t) -------- 8< ---------------- 8< ---------------- 8< ---------------- 8< -------- I consider this is a bug, I do not see any reason httpd_rotatelogs_t wouldn't be able to access a symlink labeled properly and living in the httpd package tree. I consider that having rotatelogs use the /etc/httpd/logs path is the proper way to access the logs, in order to be distribution vendor agnostic. Version-Release number of selected component (if applicable): RHEL7 and RHEL8 policies How reproducible: Always Steps to Reproduce: 1. Setup rotatelogs to access files through the /etc/httpd/logs symlink Actual results: AVC Expected results: No AVC
We need an additional rule: allow httpd_rotatelogs_t httpd_config_t:dir search; This to allow rotatelogs to create the file correctly, because rotatelogs internally uses openat(AT_FDCWD, ...) syscall with current directory /etc/httpd, hence needs to search the directory. REPRODUCER: 1. Create `/etc/httpd/conf.d/example.conf` configuration file -------- 8< ---------------- 8< ---------------- 8< ---------------- 8< -------- <VirtualHost *:80> ServerName www.example.com DocumentRoot /var/www/html CustomLog "|/usr/sbin/rotatelogs /etc/httpd/logs/www-access.example.com 3600" combined ErrorLog "|/usr/sbin/rotatelogs /etc/httpd/logs/www-error.example.com 3600" </VirtualHost> -------- 8< ---------------- 8< ---------------- 8< ---------------- 8< -------- 2. Start httpd service
3. Trigger a request (to populate the log) $ curl http://localhost
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 (selinux-policy bug fix and enhancement update), 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://access.redhat.com/errata/RHBA-2023:2965