| Summary: | Selinux prevents hourly logcheck from running | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Neil Squires <neil> |
| Component: | logcheck | Assignee: | Matthias Runge <mrunge> |
| Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | medium | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 16 | CC: | mrunge |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | x86_64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | logcheck-1.3.14-5.fc16 | Doc Type: | Bug Fix |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2012-01-16 21:21:48 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Bug Depends On: | 771127, 771609 | ||
| Bug Blocks: | |||
|
Description
Neil Squires
2011-12-19 02:52:53 UTC
If you disable selinux, the scheduled job runs and reports. To: <recipient address> Subject: [logcheck] sensi 2011-12-19 13:02 +1000 System Events Auto-Submitted: auto-generated MIME-Version: 1.0 (mime-construct 1.11) System Events =-=-=-=-=-=-= Dec 19 12:29:18 sensi systemd-logind[819]: Removed session c7. Dec 19 12:29:18 sensi su: pam_unix(su:session): session closed for user logcheck OK, I'll have a look on this.
I changed my /etc/logrotate.d/syslog file
[root@mrungexp ~]# cat /etc/logrotate.d/syslog
/var/log/messages /var/log/secure /var/log/maillog /var/log/spooler /var/log/boot.log /var/log/cron {
sharedscripts
create 0640 root adm
postrotate
/bin/kill -HUP `cat /var/run/syslogd.pid 2> /dev/null` 2> /dev/null || true
endscript
}
*create 0640 root adm* makes logfiles created as root and grouped in adm.
logcheck shall not be run as root for security reasons.
After leaving it run for 24 hours I re-enabled SELinux. The scheduled report runs fine. I will examine the context and try this "fix" on another of the systems and post the results. Contexts results between two systems: Erroring # ls -laZ /var/lib/logcheck/ drwxr-xr-x. logcheck logcheck system_u:object_r:var_lib_t:s0 . drwxr-xr-x. root root system_u:object_r:var_lib_t:s0 .. -rw-------. logcheck logcheck system_u:object_r:var_lib_t:s0 offset.var.log.messages -rw-------. logcheck logcheck system_u:object_r:var_lib_t:s0 offset.var.log.secure Working # ls -laZ /var/lib/logcheck/ drwxr-xr-x. logcheck logcheck unconfined_u:object_r:var_lib_t:s0 . drwxr-xr-x. root root system_u:object_r:var_lib_t:s0 .. -rw-------. logcheck logcheck unconfined_u:object_r:var_lib_t:s0 offset.var.log.messages -rw-------. logcheck logcheck unconfined_u:object_r:var_lib_t:s0 offset.var.log.secure SELinux message is still the same on the failing system. ]# sealert -l fb6618ea-bee9-4d5e-9394-93569ac3bd70 SELinux is preventing /usr/bin/perl from write access on the file /var/lib/logcheck/offset.var.log.messages. ***** Plugin restorecon (94.8 confidence) suggests ************************* If you want to fix the label. /var/lib/logcheck/offset.var.log.messages default label should be logwatch_cache_t. Then you can run restorecon. Do # /sbin/restorecon -v /var/lib/logcheck/offset.var.log.messages ***** Plugin catchall_labels (5.21 confidence) suggests ******************** If you want to allow perl to have write access on the offset.var.log.messages file Then you need to change the label on /var/lib/logcheck/offset.var.log.messages Do # semanage fcontext -a -t FILE_TYPE '/var/lib/logcheck/offset.var.log.messages' where FILE_TYPE is one of the following: logwatch_t, logwatch_lock_t, logwatch_var_run_t, afs_cache_t, user_cron_spool_t, logwatch_cache_t, logwatch_tmp_t. Then execute: restorecon -v '/var/lib/logcheck/offset.var.log.messages' ***** Plugin catchall (1.44 confidence) suggests *************************** If you believe that perl should be allowed write access on the offset.var.log.messages 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: # grep logtail2 /var/log/audit/audit.log | audit2allow -M mypol # semodule -i mypol.pp This policy module allows logcheck to run as a cron job.
module logtail 1.0;
require {
type logwatch_t;
type var_lib_t;
class file { read write ioctl open };
}
#============= logwatch_t ==============
allow logwatch_t var_lib_t:file open;
#!!!! This avc is allowed in the current policy
allow logwatch_t var_lib_t:file { read write };
This has to be done after logcheck is installed and the logcheck.conffile modified.
The ownership of the /var/log/secure & /var/log/message files are changed to root.adm and chmod g+r is also run against the files.
I also had to go and change the ownership of the var/lib/logcheck directory and create a var/run/logcheck directory.
I have added this policy to two machines and both are now working.
Update: Full process to enable the cron jobs following the install:
# vi /etc/logrotate.d/syslog
modify file to be
/var/log/messages /var/log/secure /var/log/maillog /var/log/spooler
/var/log/boot.log /var/log/cron {
sharedscripts
create 0640 root adm
postrotate
/bin/kill -HUP `cat /var/run/syslogd.pid 2> /dev/null` 2> /dev/null || true
endscript
}
# chown root.adm /var/log/messages /var/log/secure
# chmod g+r /var/log/messages /var/log/secure
# chown logcheck.logcheck /var/lib/logcheck
# vi logtail.te
Add the following
module logtail 1.0;
require {
type logwatch_t;
type var_lib_t;
class file { read write ioctl open };
}
#============= logwatch_t ==============
allow logwatch_t var_lib_t:file open;
#!!!! This avc is allowed in the current policy
allow logwatch_t var_lib_t:file { read write };
:wq
Compile the module
# checkmodule -M -m -o logtail.mod logtail.te
Create the package
# semodule_package -o logtail.pp -m logtail.mod
Install the package
# semodule -i logtail.pp
From this, the following changes are identified to be made in the logcheck or other packages:
1. The ownership and group permissions on the minimum base logcheck.logfile entries needs to be set to root.adm
2. File permissions on /var/log/messages and /var/log/secure should be 0640
3. The logcheck package needs to be modified as follows:
- The directory /var/lob/logcheck needs to be created with the ownership of logcheck.logcheck
- The selinux context should be set correctly to enable perl to access and run the logcheck process with it's default home directory set to /var/lig/logcheck
4. The fedora specific installation file should be modified to include the changes required for any log file included in the file to have it's permissions modfied as above.
5. The default /etc/logcheck.logfiles should be modified to include the following warning: "If any additional files are added, please ensure that the file permissions are changed to root.adm and 0640"
Or someone smart than me can find a better solution.
Thank you for your work on this issue! I really appreciate that!
OK, there are (at least two issues, I see here):
1. /var/lib/logcheck and /var/log/logcheck not being created. See 771127. I already prepared a newer version, which will not help you (because logcheck user exists on your systems)
2. /var/log/messages, /var/log/secure should be owned by root:adm and get rights 0640. This can't be handled so easy. Those files don't belong to any package, so I can't file a bug report against any other package. I guess, changing access rights on log files should become a feature for newer fedora versions.
2a) when using rsyslog, it is required to change logrotate in the way described earlier
2b) when using syslog-ng, one should change syslog-ng config file to change access rights of /var/log/messages etc. as described in 2:
(snippet from syslog-ng.conf (modified))
destination d_mesg {
file("/var/log/messages"
owner("root")
group("adm")
perm(0640)
);
};
destination d_auth {
file("/var/log/secure"
owner("root")
group("adm")
perm(0640)
);
};
Sadly, I can't reproduce your selinux-issues (neither on two different systems, nor on a freshly installed machine; I need another look into this).
logcheck-1.3.14-5.fc16 has been submitted as an update for Fedora 16. https://admin.fedoraproject.org/updates/logcheck-1.3.14-5.fc16 Package logcheck-1.3.14-5.fc16: * should fix your issue, * was pushed to the Fedora 16 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing logcheck-1.3.14-5.fc16' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2012-0222/logcheck-1.3.14-5.fc16 then log in and leave karma (feedback). logcheck-1.3.14-5.fc16 has been pushed to the Fedora 16 stable repository. If problems still persist, please make note of it in this bug report. |