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-Februar...
... 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