Jiri,

In this bz and in bz#1823672, we have a request, based on a customer case, to support imfile/omfile in a custom path including those non-conforming to FHS.

Could you share your expert opinion if this is considered a good practice and supported solution for rsyslog?

The non_security_file_type attribute contains about 3000 domains, so from selinux point of view allowing this kind of access is very questionable.

(In reply to Zdenek Pytela from comment #1)
> Jiri,
> 
> In this bz and in bz#1823672, we have a request, based on a customer case,
> to support imfile/omfile in a custom path including those non-conforming to
> FHS.
> 
> Could you share your expert opinion if this is considered a good practice
> and supported solution for rsyslog?
> 
> The non_security_file_type attribute contains about 3000 domains, so from
> selinux point of view allowing this kind of access is very questionable.

It is definitely supported solution,as for being a good practice is debatable, and I would say up to each customer/user. From design POV both imfile and omfile modules have no restrictions and can operate on whole file-system tree. However they expect that if you configure them so you also take care about corresponding permissions.

I would like to increase Priority/Severity because it may lead to rsyslogd dumping core and not being able to start.

Typical scenario is if "top directory" of imfile files is a symlink to a directory labeled with var_t:

-------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------
# mkdir -p /var/my/place
# ln -s /var/my/place /var/log/myplace_symlink

# ls -Zd /var/my/place /var/log/myplace_symlink
lrwxrwxrwx. root root unconfined_u:object_r:var_log_t:s0 /var/log/myplace_symlink -> /var/my/place
drwxr-xr-x. root root unconfined_u:object_r:var_t:s0   /var/my/place
-------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------

rsyslog imfile configuration (/etc/rsyslog.d/imfile.conf):
-------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------
module(load="imfile" PollingInterval="10")

input(type="imfile"
      file="/var/log/myplace_symlink/file.log"
      tag="myplace_file"
      severity="info"
      facility="local5"
)
-------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------

Start rsyslog:

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

# systemctl status rsyslog
[...]
  Process: 5725 ExecStart=/usr/sbin/rsyslogd -n $SYSLOGD_OPTIONS (code=killed, signal=SEGV)
[...]
-------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------

Of course I'll file a BZ against rsyslog for hardening this.

See also rsyslog BZ #1843994 (RHEL 8)

This bug has not been fully acknowledged by the subsystem to be resolved during the RHEL 8.4 development and testing phase, so it will be evaluated for inclusion into the next minor product update.

If you still want to pursue this issue further, please attach information regarding severity of the bugzilla.

Renaud,

Is this request still valid? Given:
- both the support cases were closed
- they were open on RHEL 7
- rsyslog does not segfault any longer
- the imfile module is reportedly still functional
- the #c2 indicates valid configuration change, but permissions need to be taken care of

SELinux permissions belong there too, they are a subject of user change.

The biggest concern is that with the universal solution using the non_security_file_type attribute, rsyslog would be given access to 3000 types, which is quite a big number despite this access being concealed behind a boolean, and some of them are surprisingly sensitive.

Tailored local policy, on the other hand, can give the access only to types which are required in the particular environment.

Hi Zdenek,

Yes this is still valid and needs to be addressed somehow.
I understand that non_security_file_type attribute has tons of types, but do we have an alternate solution?
We definitely cannot let the customer handle this on his own, unless we guide him step by step.

Hence if we want to avoid the boolean, I see no other choice than having an official documentation about this (not a KCS).

Needs backporting:
commit 3422c911479a75be4189407c4b1397e2443e424d
Author: Zdenek Pytela <zpytela>
Date:   Wed May 26 21:46:32 2021 +0200

    Introduce logging_syslogd_list_non_security_dirs tunable

    In customized configurations with rsyslog using the imfile input
    module to read files with a non-standard path, rsyslog since v8.24.0
    requests reading all parent directories in the path of the logfile.

    To enable reading all directories in the path with SELinux types
    which are a part of the non_security_file_type attribute,
    the ruleset is allowed conditionally after turning on the
    logging_syslogd_list_non_security_dirs tunable which is off by default.

    Resolves: rhbz#1823669

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:4420