<div dir="ltr">Unfortunately, you might miss a lot of files this way. While most files will *normally* be in /var/log, some may not depending on a given configuration so you really need to parse from rsyslog outward.<div><br>
</div><div>Trevor</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Aug 19, 2013 at 12:21 AM, Tim Moor <span dir="ltr"><<a href="mailto:tmoor@redhat.com" target="_blank">tmoor@redhat.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Wouldn't it be possible to walk the /var/log/directory and for each file<br>
perform a look up in the rsyslog configuration file. If it exists then<br>
it is managed by rsyslog and therefore must have specific ownership. If<br>
the grep fails to return a record from either /etc/rsyslog.conf or a<br>
file within /etc/rsyslog.d/ then it would be safe to ignore.<br>
<br>
Your thoughts?<br>
<div class="HOEnZb"><div class="h5"><br>
On Sat, 2013-08-17 at 13:54 -0400, Trevor Vaughan wrote:<br>
> This would definitely be a case where I'd use an external helper script.<br>
><br>
> From the configs that I have, you only seem to care about:<br>
><br>
> $IncludeConfig .* <= Parse whatever this glob results in.<br>
><br>
> Anything that does not start with $[A-Z], ends a line, has spaces before<br>
> it, and has a slash in it.<br>
><br>
> IF the file referenced exists, then check the file for permissions.<br>
><br>
> That should at least get you to the 80% mark.<br>
><br>
> If you want to get fancy, you could point out things in /var/log (or all<br>
> base directories that you discover) that aren't referenced and have them be<br>
> automatically checked.<br>
><br>
> Trevor<br>
><br>
><br>
> On Tue, Aug 13, 2013 at 4:38 PM, Kayse, Josh<br>
> <<a href="mailto:Joshua.Kayse@gtri.gatech.edu">Joshua.Kayse@gtri.gatech.edu</a>>wrote:<br>
><br>
> ><br>
> > On Aug 13, 2013, at 4:16 PM, "Truhn, Chad M CTR NSWCDD, CXA30" <<br>
> > <a href="mailto:chad.m.truhn.ctr@navy.mil">chad.m.truhn.ctr@navy.mil</a>> wrote:<br>
> ><br>
> > >>> How do you think we should handle file owner and group permission<br>
> > >>> checks on rsyslog files? Should we look for a predetermined list of<br>
> > >>> files (trying to search for *.log is insufficient, since at the very<br>
> > >>> least, /var/log/messages, /var/log/secure, and /var/log/maillog would<br>
> > >>> get passed over)? Or should we try ninja regex to parse rsyslog.conf?<br>
> > >>><br>
> > >> I'm torn. The 'right way' would be regex ninja. However that's hard, and<br>
> > >> has resulted in nothing getting done. Personally I'd rather have<br>
> > >> *something* hard coded, then evolve into ninja regex.<br>
> > ><br>
> > > I don't know if it is even really an option, but I would personally like<br>
> > to see it always fail with something like a manual check rather than hard<br>
> > coding some things that will not necessarily reflect the real state of the<br>
> > system. If you hard code fileA, fileB, and fileC and I also have fileD,<br>
> > you could potentially give a false Pass if fileD was 777.<br>
> > ><br>
> > > I think a regex is the only way that you could ever pass with some<br>
> > degree of confidence, but the rsyslog config file is SUPER hard. I don't<br>
> > want to downplay anyone's regex skills, but rsyslog deals with some<br>
> > variables (like %HOSTNAME%, %syslogfacility%, etc) that can be used in the<br>
> > file path/name. How could you ever be able to derive that? I think any<br>
> > normal person would have a system where syslog sends things to a directory<br>
> > where other files should not be, but is it safe to assume?<br>
> > ><br>
> > > I could be negatively skewed here, but I personally would prefer to have<br>
> > a false failure or a manual check than a false pass. The CISSP stuff beat<br>
> > that into my head with a rather large bat. But I'm not the one doing the<br>
> > hard work here, you guys are. Just my $0.02.<br>
> > ><br>
> ><br>
> > I would add my concurrence to this suggestion. You can use an include dir<br>
> > in rsyslog such that the configuration is built up amongst multiple files;<br>
> > how would that be handled?<br>
> ><br>
> > -josh<br>
> > _______________________________________________<br>
> > scap-security-guide mailing list<br>
> > <a href="mailto:scap-security-guide@lists.fedorahosted.org">scap-security-guide@lists.fedorahosted.org</a><br>
> > <a href="https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide" target="_blank">https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide</a><br>
> ><br>
> ><br>
><br>
><br>
> _______________________________________________<br>
> scap-security-guide mailing list<br>
> <a href="mailto:scap-security-guide@lists.fedorahosted.org">scap-security-guide@lists.fedorahosted.org</a><br>
> <a href="https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide" target="_blank">https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide</a><br>
<br>
_______________________________________________<br>
scap-security-guide mailing list<br>
<a href="mailto:scap-security-guide@lists.fedorahosted.org">scap-security-guide@lists.fedorahosted.org</a><br>
<a href="https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide" target="_blank">https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br>Trevor Vaughan<br>Vice President, Onyx Point, Inc<br>(410) 541-6699<br><a href="mailto:tvaughan@onyxpoint.com">tvaughan@onyxpoint.com</a><br><br>-- This account not approved for unencrypted proprietary information --
</div>