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