[PATCH 1/5] Updated XCCDF and OVAL of groupowner_rsyslog_files

Tomas Heinrich theinric at redhat.com
Mon Apr 15 19:13:31 UTC 2013


On 04/15/2013 04:15 PM, Jeffrey Blank wrote:
> NACK, though it is an improvement over what is there, so we could
> consider adding it as a stopgap, should there be committment with
> timeline to truly fixing it.  The remediations can't be allowed until
> the OVAL works, however.
>
> The problem is that this does not semantically agree with what the XCCDF
> says.
>
> David had even once proposed changing the XCCDF to agree with this
> approach, as shown here (and it's my bad for not responding earlier):
> https://lists.fedorahosted.org/pipermail/scap-security-guide/2013-February/002685.html
>
>
> ... but Leland (in conversation) pointed out that it should be possible
> for OVAL to determine what files are actually written by rsyslog (by
> looking in rsyslog.conf) and then performing the actual checks on those
> files.  That approach requires more complicated OVAL, though it is more

How reliable would you like this to be?

rsyslog is capable of generating file names based on message content 
(e.g. embedding the sender IP in it). This cannot be parsed out of a 
configuration file. Fixed-name log files would be possible.
rsyslog can also include config files recursively (through the 
$IncludeConfig directive) and I'm not sure OVAL can handle this.

You can get some results, but not perfect. The easiest way would be to 
include a list of log files provided by the rpm, which is the most 
typical scenario.

> desirable overall.  I might consider asking Petr or Simon or Steve for
> OVAL help here.  I still find much of the OVAL documentation
> incomprehensible.

I know a bit about rsyslog and OVAL if you have more questions.

> Relatedly, an automated check for ensuring that log files exist (Rule
> id=rsyslog_logfiles_exist)  would be particularly nice, since IIRC the
> behavior of syslog (possibly also rsyslog) is to not automatically
> create new log files (if they are deleted at some point).

They are recreated, as Shawn has pointed out.

> And that'll be easy once we figure out how to turn regex results from
> rsyslog.conf into filesystem queries (necessary for correct
> implementation of these checks too).

Tomas


More information about the scap-security-guide mailing list