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?
- Maura Dailey
On 8/13/13 3:25 PM, Maura Dailey 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.
With that said.... your regex-foo is strong and perhaps you could hack this out in 15min... ;)
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.
On Aug 13, 2013, at 4:16 PM, "Truhn, Chad M CTR NSWCDD, CXA30" chad.m.truhn.ctr@navy.mil 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
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 Joshua.Kayse@gtri.gatech.eduwrote:
On Aug 13, 2013, at 4:16 PM, "Truhn, Chad M CTR NSWCDD, CXA30" < chad.m.truhn.ctr@navy.mil> 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 scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
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 Joshua.Kayse@gtri.gatech.eduwrote:
On Aug 13, 2013, at 4:16 PM, "Truhn, Chad M CTR NSWCDD, CXA30" < chad.m.truhn.ctr@navy.mil> 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 scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
scap-security-guide mailing list scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
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 tmoor@redhat.com 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 Joshua.Kayse@gtri.gatech.eduwrote:
On Aug 13, 2013, at 4:16 PM, "Truhn, Chad M CTR NSWCDD, CXA30" < chad.m.truhn.ctr@navy.mil> 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 scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
scap-security-guide mailing list scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
scap-security-guide mailing list scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
On 08/13/2013 03:36 PM, Shawn Wells wrote:
On 8/13/13 3:25 PM, Maura Dailey 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.
With that said.... your regex-foo is strong and perhaps you could hack this out in 15min... ;) _______________________________________________ scap-security-guide mailing list scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
LOL, no, my regex is not that great. I played around with it this morning and got as far as the following check, but I can't even imagine how to handle rsyslog.conf's templating. If we have a consensus, perhaps the best strategy is just to delete both rsyslog log permissions checks. I can submit a patch that will do that pretty quickly.
- Maura Dailey
<def-group> <definition class="compliance" id="rsyslog_files_groupownership" version="1"> <metadata> <title>Confirm Existence and Permissions of System Log Files</title> <affected family="unix"> <platform>Red Hat Enterprise Linux 6</platform> </affected> <description>All syslog log files should be owned by the appropriate group.</description> </metadata> <criteria> <criterion comment="Check if group root owns all syslog log files" test_ref="test_rsyslog_files_groupownership" /> </criteria> </definition>
<ind:textfilecontent54_object comment="Find all /var/log files in rsyslog.conf" id="rsyslog_files" version="1"> ind:path/etc</ind:path> ind:filenamersyslog.conf</ind:filename> <ind:pattern operation="pattern match">^.*(/var/log/.*)$</ind:pattern> <ind:instance operation="greater than or equal" datatype="int">1</ind:instance> </ind:textfilecontent54_object>
<local_variable comment="Build list of log files" datatype="string" id="var_rsyslog_files_groupownership" version="1" > <object_component item_field="subexpression" object_ref="rsyslog_files" /> </local_variable>
<unix:file_state id="state_rsyslog_files_groupownership" version="1"> <unix:group_id datatype="int">0</unix:group_id> </unix:file_state>
<unix:file_object comment="Examine permissions of list of log files" id="object_rsyslog_files_groupownership" version="1"> <unix:filepath var_ref="var_rsyslog_files_groupownership" var_check="only one" /> </unix:file_object>
<unix:file_test check="all" check_existence="all_exist" id="test_rsyslog_files_groupownership" version="1" comment="Test to see if files in /var/log mentioned by rsyslog.conf have the correct group"> <unix:object object_ref="object_rsyslog_files_groupownership" /> <unix:state state_ref="state_rsyslog_files_groupownership" /> </unix:file_test> </def-group>
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 08/13/2013 03:08 PM, Maura Dailey wrote:
On 08/13/2013 03:36 PM, Shawn Wells wrote:
On 8/13/13 3:25 PM, Maura Dailey 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.
With that said.... your regex-foo is strong and perhaps you could hack this out in 15min... ;) _______________________________________________ scap-security-guide mailing list scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
LOL, no, my regex is not that great. I played around with it this morning and got as far as the following check, but I can't even imagine how to handle rsyslog.conf's templating. If we have a consensus, perhaps the best strategy is just to delete both rsyslog log permissions checks. I can submit a patch that will do that pretty quickly.
- Maura Dailey
Not to be a Debbie Downer but you forgot:
/etc/rsyslog.d/*
e.g.: /etc/rsyslog.d/spice-vdagentd.conf :
# A template to for higher precision timestamps + severity logging $template SpiceTmpl,"%TIMESTAMP%.%TIMESTAMP:::date-subseconds% %syslogtag% %syslogseverity-text%:%msg:::sp-if-no-1st-sp%%msg:::drop-last-lf%\n"
:programname, startswith, "spice-vdagent" /var/log/spice-vdagent.log;SpiceTmpl
- -- Kurt Seifried Red Hat Security Response Team (SRT) PGP: 0x5E267993 A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993
On 08/13/2013 07:18 PM, Kurt Seifried wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 08/13/2013 03:08 PM, Maura Dailey wrote:
On 08/13/2013 03:36 PM, Shawn Wells wrote:
On 8/13/13 3:25 PM, Maura Dailey 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.
With that said.... your regex-foo is strong and perhaps you could hack this out in 15min... ;) _______________________________________________ scap-security-guide mailing list scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
LOL, no, my regex is not that great. I played around with it this morning and got as far as the following check, but I can't even imagine how to handle rsyslog.conf's templating. If we have a consensus, perhaps the best strategy is just to delete both rsyslog log permissions checks. I can submit a patch that will do that pretty quickly.
- Maura Dailey
Not to be a Debbie Downer but you forgot:
/etc/rsyslog.d/*
e.g.: /etc/rsyslog.d/spice-vdagentd.conf :
# A template to for higher precision timestamps + severity logging $template SpiceTmpl,"%TIMESTAMP%.%TIMESTAMP:::date-subseconds% %syslogtag% %syslogseverity-text%:%msg:::sp-if-no-1st-sp%%msg:::drop-last-lf%\n"
:programname, startswith, "spice-vdagent" /var/log/spice-vdagent.log;SpiceTmpl
Meh, my /etc/rsyslog.d directory is empty. Can't miss what isn't there. The point is that the check I wrote in my last email isn't complete. I'm voting for deleting both the rsyslog permission checks.
- Maura Dailey
Kurt Seifried Red Hat Security Response Team (SRT) PGP: 0x5E267993 A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.13 (GNU/Linux)
iQIcBAEBAgAGBQJSCr7RAAoJEBYNRVNeJnmTSaoP+wfXA2BWYMpK37FFjqrk8nWF 4aBVyENJc5TscauFwkREN757bxTqZFsQiLVY0lSz1vkNElXKVCodLGb/48xrAG8c dsErzFNIC30O73RSrodJPIjG+oRNRtr01XEJQ4gyEz4huJBvZ8c7O6JByf/WQtX3 lrT2zA/jRtxgp2OfETYwJxu4cKCrV3WcoLEnyYKDJ30coiM7dVPNXTaud/Bf5DvR 73r7JzwEZQJ5W4Le2IyqZYAFRK6rw4zmMjTcONl7nzG3hzBftu6pVQF6os/kaAMC LZIlXPNi7aWOLYFjRq7wPIXfmEiV4M+r6LIL1Pf17sohAUbKMROk5yhHkX0Hl4bs 2rBZxXwY7G4Qhp/psETdmqbQkM3O3Ic8ywnATFYggkZqJNIXzXMStDO9tT0rMTba dBBL3swug5g7j1j5r15gkpfmMrT7xc7VpMLywBNdlLv4nMLcnqxJIB25F1JR7eF9 d7HRt88qfGU0SJ2sUjfxJtLgsFeZw/queRp1ebPq/X8f+tzcTI9BKQUodaXXDwny w032wvdSANNk3MNlGNGzwXrsmZV73FeM+y+m+m8rycCk/IymPJ3ak9O8GCBHzBwk /iPQSeL0vaLTw9r0UmVKCIPQdfm5h+IY2CAilpMmtRk6bjBZ7UcL85aMqDjHxSj9 FcCYT5DK8We9cEx0uXg6 =xJ8s -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 08/13/2013 05:24 PM, Maura Dailey wrote:
On 08/13/2013 07:18 PM, Kurt Seifried wrote: On 08/13/2013 03:08 PM, Maura Dailey wrote:
On 08/13/2013 03:36 PM, Shawn Wells wrote:
On 8/13/13 3:25 PM, Maura Dailey 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.
With that said.... your regex-foo is strong and perhaps you could hack this out in 15min... ;) _______________________________________________ scap-security-guide mailing list scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
LOL, no, my regex is not that great. I played around with it this
morning and got as far as the following check, but I can't even imagine how to handle rsyslog.conf's templating. If we have a consensus, perhaps the best strategy is just to delete both rsyslog log permissions checks. I can submit a patch that will do that pretty quickly.
- Maura Dailey
Not to be a Debbie Downer but you forgot:
/etc/rsyslog.d/*
e.g.: /etc/rsyslog.d/spice-vdagentd.conf :
# A template to for higher precision timestamps + severity logging $template SpiceTmpl,"%TIMESTAMP%.%TIMESTAMP:::date-subseconds% %syslogtag% %syslogseverity-text%:%msg:::sp-if-no-1st-sp%%msg:::drop-last-lf%\n"
:programname, startswith, "spice-vdagent" /var/log/spice-vdagent.log;SpiceTmpl
Meh, my /etc/rsyslog.d directory is empty. Can't miss what isn't there. The point is that the check I wrote in my last email isn't complete. I'm voting for deleting both the rsyslog permission checks.
- Maura Dailey
You can download the rpms and check their file listing/scripts for /etc/rsyslog* and whatnot content if you do want to find all instances of what Red Hat ships there.
_______________________________________________ scap-security-guide mailing list scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
- --
Kurt Seifried Red Hat Security Response Team (SRT) PGP: 0x5E267993 A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993
On 08/13/2013 07:29 PM, Kurt Seifried wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 08/13/2013 05:24 PM, Maura Dailey wrote:
On 08/13/2013 07:18 PM, Kurt Seifried wrote: On 08/13/2013 03:08 PM, Maura Dailey wrote:
On 08/13/2013 03:36 PM, Shawn Wells wrote:
On 8/13/13 3:25 PM, Maura Dailey 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.
With that said.... your regex-foo is strong and perhaps you could hack this out in 15min... ;) _______________________________________________ scap-security-guide mailing list scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
LOL, no, my regex is not that great. I played around with it this
morning and got as far as the following check, but I can't even imagine how to handle rsyslog.conf's templating. If we have a consensus, perhaps the best strategy is just to delete both rsyslog log permissions checks. I can submit a patch that will do that pretty quickly.
- Maura Dailey
Not to be a Debbie Downer but you forgot:
/etc/rsyslog.d/*
e.g.: /etc/rsyslog.d/spice-vdagentd.conf :
# A template to for higher precision timestamps + severity logging $template SpiceTmpl,"%TIMESTAMP%.%TIMESTAMP:::date-subseconds% %syslogtag% %syslogseverity-text%:%msg:::sp-if-no-1st-sp%%msg:::drop-last-lf%\n"
:programname, startswith, "spice-vdagent" /var/log/spice-vdagent.log;SpiceTmpl
Meh, my /etc/rsyslog.d directory is empty. Can't miss what isn't there. The point is that the check I wrote in my last email isn't complete. I'm voting for deleting both the rsyslog permission checks.
- Maura Dailey
You can download the rpms and check their file listing/scripts for /etc/rsyslog* and whatnot content if you do want to find all instances of what Red Hat ships there.
I *could*, but that's hundreds of packages, which may or may not be installed on any given system. It also doesn't include packages that might be available through EPEL or configuration files that people code by hand. The real problem is detecting and resolving templating. If that hard problem is solved, any number of files in rsyslog.d could be vacuumed up. I don't think I'm the one to do it, since I'm about at the limit of my regex skills, and I'm skeptical that OVAL is up to the challenge either. (The rsyslog package doesn't include the file you referred to, according to rpm -ql. We don't run spice agent on our computers, which is no doubt why we don't have it.)
- Maura Dailey
_______________________________________________ scap-security-guide mailing list scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
Kurt Seifried Red Hat Security Response Team (SRT) PGP: 0x5E267993 A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.13 (GNU/Linux)
iQIcBAEBAgAGBQJSCsFZAAoJEBYNRVNeJnmTrUUP/2wxg6GKKoUqVApYlS7UYK0n Fii05fhxbOqJ2Ugn5lwx1pLRsY0PCiM/VupQkzVYcNMUZAF3G2FE9TtzRBhs0qH4 0+2SJmLDp7Dn57Lyrc3LF865iPfYgv2fUJWEbMwT8W3G8l0QnhEGYqMGtaOV8C8O yIf699yQIZ6gebaoy05DYSs/WN44RO1bGmInKBm77JZno8rrU3rjoj7fHBPWDDWv aasRMY4M2PRz9GnHIhHu9Y2IKOUCJnbdjCnd74yz4Q1Cedp27QMFCNuXtLwpsejZ JW9XRe+5lakRu0LVEgZcPUS4PUReVI6gd3tKx4lUoJxA2baFkiHhXop8oROcqlEn NfoCtld5TR3UBvCUTUyR91IkTAMXyIGyHxKSzUOTuuKuSMX1SasR97rwtbOz9jEC xkT9fdepbjI6OFPRcOCv1Y3m64+ZUbnLKBMoNosmdZC9wkJXQ5jvoHhl9fBpWRl0 GGxD7ekGwhlO3HLfov+d2Heyvp2LsbgqjhTbJImERPHvq0BXZixesjpmVvZljyho 6RfjT3XH7F9VyCJE5XPULQtv7ZX+m/7fJtmTRzYcGmkjlKhsHPH9WiDZZj64eXMT JTAm50Yl+99/hIp+2CwYApLcCVi2dpT7qo8kBPiP27oDoXS2cyM8FQu40aZ/2dpV 47ww9He6G5rH0T1JP0DX =OEgw -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 08/14/2013 09:26 AM, Maura Dailey wrote:
I *could*, but that's hundreds of packages, which may or may not be installed on any given system. It also doesn't include packages that might be available through EPEL or configuration files that people code by hand. The real problem is detecting and resolving templating. If that hard problem is solved, any number of files in rsyslog.d could be vacuumed up. I don't think I'm the one to do it, since I'm about at the limit of my regex skills, and I'm skeptical that OVAL is up to the challenge either. (The rsyslog package doesn't include the file you referred to, according to rpm -ql. We don't run spice agent on our computers, which is no doubt why we don't have it.)
- Maura Dailey
It's only 3.5 gigs for the base RPMS, here's the results, first block is files included, second set is part of the scripts that talk to /var/log (just grep'ed), note many of these are dirs and would have files created within them:
389-ds-base-1.2.11.15-11.el6.x86_64.rpm.list:/var/log/dirsrv aide-0.14-3.el6_2.2.x86_64.rpm.list:/var/log/aide amanda-2.6.1p2-8.el6.i686.rpm.list:/var/log/amanda amanda-2.6.1p2-8.el6.x86_64.rpm.list:/var/log/amanda audit-2.2-2.el6.x86_64.rpm.list:/var/log/audit bacula-common-5.0.0-12.el6.x86_64.rpm.list:/var/log/bacula bind-9.8.2-0.17.rc1.el6.x86_64.rpm.list:/var/log/named.log bind-chroot-9.8.2-0.17.rc1.el6.x86_64.rpm.list:/var/named/chroot/var/log cman-3.0.12.1-49.el6.x86_64.rpm.list:/var/log/cluster conman-0.2.5-2.4.el6.x86_64.rpm.list:/var/log/conman conman-0.2.5-2.4.el6.x86_64.rpm.list:/var/log/conman.old ConsoleKit-0.4.1-3.el6.x86_64.rpm.list:/var/log/ConsoleKit corosync-1.4.1-15.el6.x86_64.rpm.list:/var/log/cluster cups-1.4.2-48.el6_3.3.x86_64.rpm.list:/var/log/cups dracut-004-303.el6.noarch.rpm.list:/var/log/dracut.log efax-0.9a-8.el6.x86_64.rpm.list:/var/log/fax filesystem-2.4.30-3.el6.x86_64.rpm.list:/var/log freeipmi-0.7.16-3.el6.i686.rpm.list:/var/log/ipmiconsole freeipmi-0.7.16-3.el6.x86_64.rpm.list:/var/log/ipmiconsole freeipmi-bmc-watchdog-0.7.16-3.el6.x86_64.rpm.list:/var/log/freeipmi freeradius-2.1.12-4.el6_3.x86_64.rpm.list:/var/log/radius freeradius-2.1.12-4.el6_3.x86_64.rpm.list:/var/log/radius/radacct freeradius-2.1.12-4.el6_3.x86_64.rpm.list:/var/log/radius/radius.log freeradius-2.1.12-4.el6_3.x86_64.rpm.list:/var/log/radius/radutmp gdm-2.30.4-39.el6.x86_64.rpm.list:/var/log/gdm hplip-3.12.4-4.el6.x86_64.rpm.list:/var/log/hp httpd-2.2.15-26.el6.x86_64.rpm.list:/var/log/httpd initscripts-9.03.38-1.el6.x86_64.rpm.list:/var/log/btmp initscripts-9.03.38-1.el6.x86_64.rpm.list:/var/log/wtmp iptraf-3.0.1-14.el6.x86_64.rpm.list:/var/log/iptraf isdn4k-utils-3.2-75.el6.i686.rpm.list:/var/log/vbox isdn4k-utils-3.2-75.el6.x86_64.rpm.list:/var/log/vbox libvirt-0.10.2-18.el6.x86_64.rpm.list:/var/log/libvirt libvirt-0.10.2-18.el6.x86_64.rpm.list:/var/log/libvirt/lxc libvirt-0.10.2-18.el6.x86_64.rpm.list:/var/log/libvirt/qemu libvirt-0.10.2-18.el6.x86_64.rpm.list:/var/log/libvirt/uml luci-0.26.0-37.el6.x86_64.rpm.list:/var/log/luci luci-0.26.0-37.el6.x86_64.rpm.list:/var/log/luci/luci.log mailman-2.1.12-18.el6.x86_64.rpm.list:/var/log/mailman mysql-server-5.1.66-2.el6_3.x86_64.rpm.list:/var/log/mysqld.log ntp-4.2.4p8-3.el6.x86_64.rpm.list:/var/log/ntpstats pam-1.1.1-13.el6.i686.rpm.list:/var/log/tallylog pam-1.1.1-13.el6.x86_64.rpm.list:/var/log/tallylog piranha-0.8.6-2.el6.x86_64.rpm.list:/var/log/piranha pm-utils-1.2.5-10.el6.x86_64.rpm.list:/var/log/pm-suspend.log ppp-2.4.5-5.el6.x86_64.rpm.list:/var/log/ppp prelink-0.4.6-3.el6.x86_64.rpm.list:/var/log/prelink prelink-0.4.6-3.el6.x86_64.rpm.list:/var/log/prelink/prelink.log quagga-0.99.15-7.el6_3.2.x86_64.rpm.list:/var/log/quagga samba4-common-4.0.0-55.el6.rc4.x86_64.rpm.list:/var/log/samba samba4-common-4.0.0-55.el6.rc4.x86_64.rpm.list:/var/log/samba/old samba-common-3.6.9-151.el6.i686.rpm.list:/var/log/samba samba-common-3.6.9-151.el6.i686.rpm.list:/var/log/samba/old samba-common-3.6.9-151.el6.x86_64.rpm.list:/var/log/samba samba-common-3.6.9-151.el6.x86_64.rpm.list:/var/log/samba/old sendmail-8.14.4-8.el6.x86_64.rpm.list:/var/log/mail sendmail-8.14.4-8.el6.x86_64.rpm.list:/var/log/mail/statistics setroubleshoot-server-3.0.47-6.el6.x86_64.rpm.list:/var/log/setroubleshoot setup-2.8.14-20.el6.noarch.rpm.list:/var/log/lastlog squid-3.1.10-16.el6.x86_64.rpm.list:/var/log/squid sssd-1.9.2-82.el6.x86_64.rpm.list:/var/log/sssd subscription-manager-1.1.23-1.el6.x86_64.rpm.list:/var/log/rhsm sysstat-9.0.4-20.el6.x86_64.rpm.list:/var/log/sa systemtap-server-1.8-7.el6.x86_64.rpm.list:/var/log/stap-server systemtap-server-1.8-7.el6.x86_64.rpm.list:/var/log/stap-server/log tomcat6-6.0.24-49.el6.noarch.rpm.list:/var/log/tomcat6 tomcat6-6.0.24-49.el6.noarch.rpm.list:/var/log/tomcat6/catalina.out tuned-0.2.19-11.el6.noarch.rpm.list:/var/log/tuned util-linux-ng-2.17.2-12.9.el6.i686.rpm.list:/var/log/lastlog util-linux-ng-2.17.2-12.9.el6.x86_64.rpm.list:/var/log/lastlog
ConsoleKit-0.4.1-3.el6.x86_64.rpm.scripts:if [ -f /var/log/ConsoleKit/history ]; then ConsoleKit-0.4.1-3.el6.x86_64.rpm.scripts: chmod a+r /var/log/ConsoleKit/history gdm-2.30.4-39.el6.x86_64.rpm.scripts: -e 's@^LogDir=/var/log/gdm@#&@' \ initscripts-9.03.38-1.el6.x86_64.rpm.scripts:touch /var/log/wtmp /var/run/utmp /var/log/btmp initscripts-9.03.38-1.el6.x86_64.rpm.scripts:chown root:utmp /var/log/wtmp /var/run/utmp /var/log/btmp initscripts-9.03.38-1.el6.x86_64.rpm.scripts:chmod 664 /var/log/wtmp /var/run/utmp initscripts-9.03.38-1.el6.x86_64.rpm.scripts:chmod 600 /var/log/btmp mysql-server-5.1.66-2.el6_3.x86_64.rpm.scripts:/bin/touch /var/log/mysqld.log openwsman-server-2.2.3-8.el6.i686.rpm.scripts:rm -f /var/log/wsmand.log openwsman-server-2.2.3-8.el6.x86_64.rpm.scripts:rm -f /var/log/wsmand.log pam-1.1.1-13.el6.i686.rpm.scripts:if [ ! -e /var/log/tallylog ] ; then pam-1.1.1-13.el6.i686.rpm.scripts: install -m 600 /dev/null /var/log/tallylog pam-1.1.1-13.el6.x86_64.rpm.scripts:if [ ! -e /var/log/tallylog ] ; then pam-1.1.1-13.el6.x86_64.rpm.scripts: install -m 600 /dev/null /var/log/tallylog rsyslog-5.8.10-6.el6.x86_64.rpm.scripts:for n in /var/log/{messages,secure,maillog,spooler} selinux-policy-minimum-3.7.19-195.el6.noarch.rpm.scripts:restorecon -R /root /var/log /var/run 2> /dev/null selinux-policy-minimum-3.7.19-195.el6.noarch.rpm.scripts: restorecon -R /root /var/log /var/run 2> /dev/null; selinux-policy-mls-3.7.19-195.el6.noarch.rpm.scripts: restorecon -R /root /var/log /var/run 2> /dev/null selinux-policy-mls-3.7.19-195.el6.noarch.rpm.scripts: restorecon - -R /root /var/log /var/run 2> /dev/null; selinux-policy-targeted-3.7.19-195.el6.noarch.rpm.scripts:); restorecon -R /root /var/log /var/run 2> /dev/null selinux-policy-targeted-3.7.19-195.el6.noarch.rpm.scripts: restorecon -R /root /var/log /var/run 2> /dev/null; squid-3.1.10-16.el6.x86_64.rpm.scripts:for i in /var/log/squid /var/spool/squid ; do squid-3.1.10-16.el6.x86_64.rpm.scripts: rm -f /var/log/squid/* sysstat-9.0.4-20.el6.x86_64.rpm.scripts: rm -f /var/log/sa/* systemtap-server-1.8-7.el6.x86_64.rpm.scripts:test -e /var/log/stap-server/log || { systemtap-server-1.8-7.el6.x86_64.rpm.scripts: touch /var/log/stap-server/log systemtap-server-1.8-7.el6.x86_64.rpm.scripts: chmod 664 /var/log/stap-server/log systemtap-server-1.8-7.el6.x86_64.rpm.scripts: chown stap-server:stap-server /var/log/stap-server/log util-linux-ng-2.17.2-12.9.el6.i686.rpm.scripts:# only for minimal buildroots without /var/log util-linux-ng-2.17.2-12.9.el6.i686.rpm.scripts:[ -d /var/log ] || /bin/mkdir -p /var/log util-linux-ng-2.17.2-12.9.el6.i686.rpm.scripts:/bin/touch /var/log/lastlog util-linux-ng-2.17.2-12.9.el6.i686.rpm.scripts:/bin/chown root:root /var/log/lastlog util-linux-ng-2.17.2-12.9.el6.i686.rpm.scripts:/bin/chmod 0644 /var/log/lastlog util-linux-ng-2.17.2-12.9.el6.i686.rpm.scripts: SECXT=$( /usr/sbin/matchpathcon -n /var/log/lastlog 2> /dev/null ) util-linux-ng-2.17.2-12.9.el6.i686.rpm.scripts: /usr/bin/chcon "$SECXT" /var/log/lastlog >/dev/null 2>&1 || : util-linux-ng-2.17.2-12.9.el6.x86_64.rpm.scripts:# only for minimal buildroots without /var/log util-linux-ng-2.17.2-12.9.el6.x86_64.rpm.scripts:[ -d /var/log ] || /bin/mkdir -p /var/log util-linux-ng-2.17.2-12.9.el6.x86_64.rpm.scripts:/bin/touch /var/log/lastlog util-linux-ng-2.17.2-12.9.el6.x86_64.rpm.scripts:/bin/chown root:root /var/log/lastlog util-linux-ng-2.17.2-12.9.el6.x86_64.rpm.scripts:/bin/chmod 0644 /var/log/lastlog util-linux-ng-2.17.2-12.9.el6.x86_64.rpm.scripts: SECXT=$( /usr/sbin/matchpathcon -n /var/log/lastlog 2> /dev/null ) util-linux-ng-2.17.2-12.9.el6.x86_64.rpm.scripts: /usr/bin/chcon "$SECXT" /var/log/lastlog >/dev/null 2>&1 || :
- -- Kurt Seifried Red Hat Security Response Team (SRT) PGP: 0x5E267993 A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993
scap-security-guide@lists.fedorahosted.org
-
Kayse, Josh -
Kurt Seifried -
Maura Dailey -
Shawn Wells -
Tim Moor -
Trevor Vaughan -
Truhn, Chad M CTR NSWCDD, CXA30