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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ scap-security-guide mailing list [email protected] https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
