SELinux context for ossec.log to allow log rotation

[Craig Finch]

I have configured logrotate to rotate the log file /var/ossec/logs/ossec.log on a CentOS 7 system, since this file is not rotated by OSSEC itself. Rotation worked for a while, but in early October 2015, SELinux started denying the rotation of this particular log file. I suspect this change was linked to a system update that changed the SELinux policies on CentOS. I was able to re-enable log rotation by changing the context of /var/ossec/logs/ossec.log to 

unconfined_u:object_r:var_log_t:s0. Does anyone know the correct context for this log file? Does anyone see a security problem with using this context on this file?

[Santiago Bassett]

OSSEC log files are rotated by ossec-monitord process every day at midnight. I don't think you would need to use logrotate for this. Did you check ossec-monitord process is running?

If this is a test environement you can do a quick check changing the system timestamp.

On Mon, Nov 30, 2015 at 9:27 PM, Craig Finch <cr...@rootwork.it> wrote:

I have configured logrotate to rotate the log file /var/ossec/logs/ossec.log on a CentOS 7 system, since this file is not rotated by OSSEC itself. Rotation worked for a while, but in early October 2015, SELinux started denying the rotation of this particular log file. I suspect this change was linked to a system update that changed the SELinux policies on CentOS. I was able to re-enable log rotation by changing the context of /var/ossec/logs/ossec.log to 

unconfined_u:object_r:var_log_t:s0. Does anyone know the correct context for this log file? Does anyone see a security problem with using this context on this file?

--

---
You received this message because you are subscribed to the Google Groups "ossec-list" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ossec-list+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Antonio Querubin]

On Tue, 1 Dec 2015, Santiago Bassett wrote:

> OSSEC log files are rotated by ossec-monitord process every day at
> midnight. I don't think you would need to use logrotate for this. Did you
> check ossec-monitord process is running?

Monitord only touches the alerts, archives, and firewall logs. The
active-responses.log and ossec.log are handled by a logrotate job (which
is found in the RPM packages). If selinux is enabled, the context of the
/var/ossec/logs directory would need to be changed for logrotate to
operate on those files (or a targeted selinux policy created). This info
should be captured somewhere in the documentation or integrated into the
install scripts.

Antonio Querubin
e-mail: to...@lavanauts.org
xmpp: antonio...@gmail.com

[Antonio Querubin]

An errant 'restorecon -r' in the wrong directory would undo that (or be a
potential source of confusion since it's underneath /var). A targeted
policy might be a little more 'robust' against a quick cleanup of /var.

[Santiago Bassett]

It seems you are right and I was wrong. Thanks Antonio for the explanation, and sorry for the confusion. 

I'll actually add this to the Debian/Ubuntu packages as well. What is weird is that I don't see any logrotate configuration file added when using install.sh script. Wouldn't it make sense to add it there as well?

Best regards

[Antonio Querubin]

On Wed, 2 Dec 2015, Santiago Bassett wrote:

> I'll actually add this to the Debian/Ubuntu packages as well. What is weird
> is that I don't see any logrotate configuration file added when using
> install.sh script. Wouldn't it make sense to add it there as well?

I've only seen the logrotate script in RPMs. It's currently not in the
master branch but probably should be added, and as you say, also
integrated into install.sh. On top of that, if SELINUX is enabled, either
a policy would need to be added (say logrotate-ossec to keep it separate
from any existing logrotate policy which by the way exists in RHEL 7 but
not in RHEL 6 derivatives), or add a chcon to the startup scripts.