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

Shawn Wells shawn at redhat.com
Tue Apr 16 00:07:15 UTC 2013


On 4/15/13 3:13 PM, Tomas Heinrich wrote:
> 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.

Any suggestions on how to parse out the logfiles names as variables in 
OVAL, then have it check the various user/group/file permissions? I 
can't find sample code on this =/

And to ask a silly question, since we're creating the guidance, is there 
a reason to not have rules which state "log authprive info to 
/var/log/secure," "log uucp,news.crit to /var/log/spool," etc? This 
would make things much easier. I can't imagine many people change away 
from the defaults, and if they do, let them create exceptions in their 
C&A docs.

##


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