0

on a Centos 8 server, I attached a bigger disk mounted to /mnt/data. The server runs rsyslogd which has a policy to write logs from external systems to /mnt/data/logs/$HOSTNAME. I do now have the problem that either logrotate doesn't rotate the logs when selinux fcontext for /mnt/data/logs is set to "syslogd_var_lib_t" , or rsyslod doesn't write data to files when fcontext is set to "logrotate_var_lib_t".

I found several solutions for samba and httpd where bools are set to "*anon_write 1", but for syslog and logrotate, I don't see bools.

Is there a way to let selinux allow both logrotate and rsyslogd in /mnt/data/logs ?

sealert output with fcontext of /mnt/data/logs is set to 'logrotate_var_lib_t':

SELinux is preventing /usr/sbin/rsyslogd from append access on the file 10.9.7.15.log.                     

*****  Plugin catchall (100. confidence) suggests   **************************

If you believe that rsyslogd should be allowed append access on the 10.9.7.15.log file by default.
Then you should report this as a bug.
You can generate a local policy module to allow this access.
Do
allow this access for now by executing:
# ausearch -c 'rs:main Q:Reg' --raw | audit2allow -M my-rsmainQReg
# semodule -X 300 -i my-rsmainQReg.pp


Additional Information:
Source Context                system_u:system_r:syslogd_t:s0
Target Context                system_u:object_r:logrotate_var_lib_t:s0
Target Objects                10.9.7.15.log [ file ]
Source                        rs:main Q:Reg
Source Path                   /usr/sbin/rsyslogd
Port                          <Unknown>
Host                          HAMS010125.global.bdfgroup.net
Source RPM Packages           rsyslog-8.1911.0-6.el8.x86_64
Target RPM Packages
SELinux Policy RPM            selinux-policy-targeted-3.14.3-54.el8.noarch
Local Policy RPM              selinux-policy-targeted-3.14.3-54.el8.noarch
Selinux Enabled               True
Policy Type                   targeted
Enforcing Mode                Enforcing
Host Name                     HAMS010125.global.bdfgroup.net
Platform                      Linux HAMS010125.global.bdfgroup.net
                              4.18.0-240.1.1.el8_3.x86_64 #1 SMP Thu Nov 19
                              17:20:08 UTC 2020 x86_64 x86_64
Alert Count                   68679
First Seen                    2021-03-30 07:47:58 CEST
Last Seen                     2021-03-30 10:47:03 CEST
Local ID                      5ee9e182-0188-4ac8-b28e-5c8c9ab18933

Raw Audit Messages
type=AVC msg=audit(1617094023.794:76568): avc:  denied  { append } for  pid=1452 comm=72733A6D61696E20513A526567 n
ame="10.9.7.15.log" dev="dm-3" ino=23330820 scontext=system_u:system_r:syslogd_t:s0 tcontext=system_u:object_r:log
rotate_var_lib_t:s0 tclass=file permissive=0


type=SYSCALL msg=audit(1617094023.794:76568): arch=x86_64 syscall=openat success=no exit=EACCES a0=ffffff9c a1=7f8
2b40a4fa0 a2=80541 a3=1a4 items=0 ppid=1 pid=1452 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0
fsgid=0 tty=(none) ses=4294967295 comm=rs:main Q:Reg exe=/usr/sbin/rsyslogd subj=system_u:system_r:syslogd_t:s0 ke
y=(null)

Hash: rs:main Q:Reg,syslogd_t,logrotate_var_lib_t,file,append

sealert output with fcontext of /mnt/data/logs set to 'syslogd_var_lib_t':

SELinux is preventing /usr/sbin/logrotate from read access on the file 10.9.7.16.log.

*****  Plugin catchall (100. confidence) suggests   **************************

If you believe that logrotate should be allowed read access on the 10.9.7.16.log file by default.
Then you should report this as a bug.
You can generate a local policy module to allow this access.
Do
allow this access for now by executing:
# ausearch -c 'logrotate' --raw | audit2allow -M my-logrotate
# semodule -X 300 -i my-logrotate.pp


Additional Information:
Source Context                system_u:system_r:logrotate_t:s0-s0:c0.c1023
Target Context                system_u:object_r:syslogd_var_lib_t:s0
Target Objects                10.9.7.16.log [ file ]
Source                        logrotate
Source Path                   /usr/sbin/logrotate
Port                          <Unknown>
Host                          HAMS010125.global.bdfgroup.net
Source RPM Packages
Target RPM Packages
SELinux Policy RPM            selinux-policy-targeted-3.14.3-54.el8.noarch
Local Policy RPM              selinux-policy-targeted-3.14.3-54.el8.noarch
Selinux Enabled               True
Policy Type                   targeted
Enforcing Mode                Enforcing
Host Name                     HAMS010125.global.bdfgroup.net
Platform                      Linux HAMS010125.global.bdfgroup.net
                              4.18.0-240.1.1.el8_3.x86_64 #1 SMP Thu Nov 19
                              17:20:08 UTC 2020 x86_64 x86_64
Alert Count                   8
 First Seen                    2021-03-26 02:51:01 CET
 Last Seen                     2021-03-29 02:51:01 CEST
 Local ID                      9ee8b323-1833-484b-b7c7-4b746c30d60b

Raw Audit Messages
type=AVC msg=audit(1616979061.951:6206): avc:  denied  { read } for  pid=632546 comm="logrotate" name="10.9.7.16.$
og" dev="dm-3" ino=23330825 scontext=system_u:system_r:logrotate_t:s0-s0:c0.c1023 tcontext=system_u:object_r:sysl$
gd_var_lib_t:s0 tclass=file permissive=0

 
Hash: logrotate,logrotate_t,syslogd_var_lib_t,file,read

Any hint appreciated, thanks.

2
  • Did you see the remark "You can generate a local policy module to allow this access" in the sealert output? Mar 31, 2021 at 7:59
  • Yes, of course. I tried to generate local policies, but when one alert was gone, the next came up. I came to the point to think about, if this would be the right way to build several policies or if it would be better to check labeling. Mar 31, 2021 at 10:25

1 Answer 1

1

You can mark your log directory with the same label as the /var/log has. Then call restorecon on it to take effect.

semanage fcontext -a -t var_log_t /mnt/data/logs
restorecon /mnt/data/logs

It will work as long as the actual files under /mnt/data/logs are created by rsyslog and rotated with logrotate. You may have to mark your $HOSTNAME directories; depending on your setup.

A bit more correct way is to create your own selinux policy which allows operations you need. This can be done automatically with relevant audit.log lines and audit2allow tool.

Other possibility is to just set selinux to permissive for logrotate with semanage permissive -a logrotate_t. And the same way for rsyslog. But this effectively removes system-wide protection for logrotate and rsyslog should one of them went nuts, so I do not recommend it.

1
  • I just set semanage fcontext -m -e /var/log '/mnt/data/logs(/.*)?' and restorecon -vvR /mnt/data/logs and will wait for crontab initiated logrotate tomorrow. To be honest, I would prefer to avoid setting daemons to 'permissive'. My position is to configure things the right way and not to deactivate well developed security mechanisms. Mar 31, 2021 at 10:31

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .