RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1823672 - rsyslog "omfile" cannot append to custom file locations
Summary: rsyslog "omfile" cannot append to custom file locations
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 8
Classification: Red Hat
Component: selinux-policy
Version: 8.1
Hardware: All
OS: Linux
high
medium
Target Milestone: rc
: 8.4
Assignee: Zdenek Pytela
QA Contact: Milos Malik
URL:
Whiteboard:
Depends On:
Blocks: 1894575
TreeView+ depends on / blocked
 
Reported: 2020-04-14 08:32 UTC by Renaud Métrich
Modified: 2023-09-07 22:47 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Feature: A new logging_syslogd_append_public_content tunable was added to the policy to allow to search the parent directories of logfiles with customized path and to append to files labeled public_content_rw_t when logs are exported using http or ftp. Reason: When the rsyslogd service is set to use a logfile in an arbitrary path, the permission to search the logfile parent directories may not be allowed. To enable exporting of logs labeled public_content_rw_t using http or ftp, also the append permission to files with the public_content_rw_t type is needed. Result: After turning the logging_syslogd_append_public_content tunable on, the rsyslogd service is able to work with logfiles in an arbitrary path.
Clone Of:
Environment:
Last Closed: 2021-05-18 14:57:37 UTC
Type: Bug
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

Description Renaud Métrich 2020-04-14 08:32:50 UTC
Description of problem:

When rsyslog is configured to write logs to a file in a non-standard place (e.g. /my/custom/log directory labeled "public_content_rw_t"), AVCs related to browsing the parent directories are seen *and* rsyslog is not functional:

-------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------
allow syslogd_t public_content_rw_t:dir search;
-------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------

In the logs we can see a lot of Permission denies:
-------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------
error during config processing: omfile: creating parent directories for file  '/my/custom/log/file' failed: Permission denied [v8.37.0-13.el8 try http://www.rsyslog.com/e/2207 ]
-------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------

See also BZ #1821725 on RHEL 7.


Version-Release number of selected component (if applicable):

rsyslog-8.37.0-13.el8.x86_64 & selinux-policy-3.14.3-20.el8.noarch


How reproducible:

ALWAYS

Steps to Reproduce:
1. Create a custom directory containing log files

-------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------
# mkdir -p /my/custom/log
# semanage fcontext -a -t public_content_rw_t "/my/custom(/.*)?"
# restorecon -Frv /my
-------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------

2. Configure rsyslog to write logs to this location

/etc/rsyslog.conf:
-------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------
*.info;mail.none;authpriv.none;cron.none                /my/custom/log/file
-------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------

3. Restart rsyslog

-------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------
# systemctl restart rsyslog

# ausearch -m avc -ts recent
-------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------

Actual results:

-------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------
#============= syslogd_t ==============
allow syslogd_t public_content_rw_t:dir search;
allow syslogd_t public_content_rw_t:file { append getattr ioctl open };
-------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------

Expected results:

Only AVC related to appending to the log file since rsyslog cannot append to public_content_rw_t file by default:
-------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------
allow syslogd_t public_content_rw_t:file { append getattr ioctl open };
-------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------

Additional info:

The example above was taken from a real customer case where the customer wants to export logs through http/ftp.
Of course, appending to the log file would require a dedicated rule, which is not covered here.

The failure happens due to rsyslog not being able to browse the parent directories up to the log file.
In most use cases, it is not sufficient to only add a rule for "public_content_rw_t:dir" but for any non security file type instead:

non_security_file_type:dir

Comment 3 Zdenek Pytela 2020-11-10 18:21:19 UTC
Renaud,

This is the solution as agreed in our team:

There will be a boolean allowing syslogd_t append permissions to public_content_rw_t:file and search permissions to non_security_file_type:dir. This boolean will be off by default.

Is this acceptable?

I am also curious if alternative solutions were considered, e. g. using bind mounts were considered for this use case.

Comment 4 Renaud Métrich 2020-11-11 12:26:50 UTC
Hi Zdenek,

I'm ok with the boolean to write to http public content.
For "searching non_security_file_type dirs", I think this should be available by default.

Using bind mounts is an alternative but it's too complicated / error prone:
indeed rsyslog doesn't depend on the network, so if we tell customers to bind mounts for that, we surely will have ordering cycles created, e.g. when bind mounting NFS file systems.

Comment 5 Zdenek Pytela 2020-11-11 16:28:16 UTC
I've submitted a Fedora PR to address the issue:
https://github.com/fedora-selinux/selinux-policy/pull/477

The search rule is conditionally allowed, too: syslogd_t is allowed to search on all base file types which can appear at the top directory level.

Comment 21 errata-xmlrpc 2021-05-18 14:57:37 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 (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-2021:1639


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