Hey all,
Just ran oscap with the xml files available on the website (Benchmark version 0.9). Here are the issues that seem to be false positives. Prefix everything with "RHEL-06-000". These are all marked as fail but the server meets the STIG.
9 rhnsd can be on if configured to Satellite server or similar 57 ucredit 58 ocredit 59 lcredit 73 /etc/issue 98 No ipv6 installed 99 " 165 adjtimex 167 settimeofday 169 stime // Also, the STIG is wrong. There is no x86_64 stime syscall 171 clock_settime 184-196, 200 chmod, chown, etc... 206-211 No telnet installed or turned on 240 /etc/ssh/sshd_config Banner 271 If there are no removable partitions this is not a finding. 278 If the file permissions are more restrictive then it is not a finding. 324 No X running 326 " 346 Finding reported on umask 022 348 No vsftp installed, thus no file. 506 "hushlogin" 507 PrintLastLog
Am I confused in thinking a system in run level 3 should net need to worry about X/Gnome findings?
Leam
I'm not sure about the OSCAP results but if X is installed then you should secure it. Someone could accidentally set run level 5 or just do a startx and fire it up means any vulnerabilities and/or weaknesses would then be exposed. If X is not installed, you can probably mark it N/A.
-Rob
-----Original Message----- From: scap-security-guide-bounces@lists.fedorahosted.org [mailto:scap-security-guide-bounces@lists.fedorahosted.org] On Behalf Of leam hall Sent: Wednesday, August 28, 2013 12:04 To: scap-security-guide@lists.fedorahosted.org Subject: Various False Positives?
Hey all,
Just ran oscap with the xml files available on the website (Benchmark version 0.9). Here are the issues that seem to be false positives. Prefix everything with "RHEL-06-000". These are all marked as fail but the server meets the STIG.
9 rhnsd can be on if configured to Satellite server or similar
57 ucredit
58 ocredit
59 lcredit
73 /etc/issue
98 No ipv6 installed 99 "
165 adjtimex
167 settimeofday
169 stime // Also, the STIG is wrong. There is no x86_64 stime syscall
171 clock_settime
184-196, 200 chmod, chown, etc...
206-211 No telnet installed or turned on
240 /etc/ssh/sshd_config Banner
271 If there are no removable partitions this is not a finding.
278 If the file permissions are more restrictive then it is not a finding.
324 No X running 326 "
346 Finding reported on umask 022
348 No vsftp installed, thus no file.
506 "hushlogin"
507 PrintLastLog
Am I confused in thinking a system in run level 3 should net need to worry about X/Gnome findings?
Leam
This is not quite a practical strategy for us. We will recommend (and even write some Rules for removal of) some software which presents an attack surface such as network services, but scope explodes if we seriously attempt to configure all potentially installed software.
On Wed, Aug 28, 2013 at 12:57 PM, Hopkins, Robert J CTR BXPP, BXPP robert.j.hopkins1.ctr@navy.mil wrote:
I'm not sure about the OSCAP results but if X is installed then you should secure it. Someone could accidentally set run level 5 or just do a startx and fire it up means any vulnerabilities and/or weaknesses would then be exposed. If X is not installed, you can probably mark it N/A.
-Rob
-----Original Message----- From: scap-security-guide-bounces@lists.fedorahosted.org [mailto:scap-security-guide-bounces@lists.fedorahosted.org] On Behalf Of leam hall Sent: Wednesday, August 28, 2013 12:04 To: scap-security-guide@lists.fedorahosted.org Subject: Various False Positives?
Hey all,
Just ran oscap with the xml files available on the website (Benchmark version 0.9). Here are the issues that seem to be false positives. Prefix everything with "RHEL-06-000". These are all marked as fail but the server meets the STIG.
9 rhnsd can be on if configured to Satellite server or similar
57 ucredit
58 ocredit
59 lcredit
73 /etc/issue
98 No ipv6 installed 99 "
165 adjtimex
167 settimeofday
169 stime // Also, the STIG is wrong. There is no x86_64 stime syscall
171 clock_settime
184-196, 200 chmod, chown, etc...
206-211 No telnet installed or turned on
240 /etc/ssh/sshd_config Banner
271 If there are no removable partitions this is not a finding.
278 If the file permissions are more restrictive then it is not a finding.
324 No X running 326 "
346 Finding reported on umask 022
348 No vsftp installed, thus no file.
506 "hushlogin"
507 PrintLastLog
Am I confused in thinking a system in run level 3 should net need to worry about X/Gnome findings?
Leam
--
Mind on a Mission http://leamhall.blogspot.com/
scap-security-guide mailing list scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
On 9/2/13 10:45 PM, Jeffrey Blank wrote:
This is not quite a practical strategy for us. We will recommend (and even write some Rules for removal of) some software which presents an attack surface such as network services, but scope explodes if we seriously attempt to configure all potentially installed software.
On Wed, Aug 28, 2013 at 12:57 PM, Hopkins, Robert J CTR BXPP, BXPP robert.j.hopkins1.ctr@navy.mil wrote:
I'm not sure about the OSCAP results but if X is installed then you should secure it. Someone could accidentally set run level 5 or just do a startx and fire it up means any vulnerabilities and/or weaknesses would then be exposed. If X is not installed, you can probably mark it N/A.
This loops back to "should servers have desktops installed?" questions. For current content, the answer is no... however if someone cares enough about X/GNOME/Desktop content and is willing to create & maintain the XCCDF and OVAL, patches welcome
On 08/28/2013 12:04 PM, leam hall wrote:
Hey all,
Just ran oscap with the xml files available on the website (Benchmark version 0.9). Here are the issues that seem to be false positives. Prefix everything with "RHEL-06-000". These are all marked as fail but the server meets the STIG.
Stupid question, but what are you running against exactly? The RPM or the latest git checkout? I want to make sure that if I run this, I'm seeing the same results, and I've made a lot of changes to OVAL checks in the git repository in the past few weeks. I'm going to run through your list, comparing it against the OVAL checks.
9 rhnsd can be on if configured to Satellite server or similar
Fix text definitely implies this. It's not the only service that implies it's allowed in certain environments, but then proceeds to only accept a value of disabled.
57 ucredit 58 ocredit 59 lcredit
For the previous 3, I'd like to see the pam_cracklib.so line so I can troubleshoot.
73 /etc/issue
Going back to my many many OVAL check updates, I'd like to see your exact /etc/issue so I can debug what went wrong. If it's an exact copy of the text from the STIG, I'll work off that.
98 No ipv6 installed
Do you mean it's disabled on your system, but the OVAL checks are saying it isn't?
99 "
?
165 adjtimex 167 settimeofday 169 stime // Also, the STIG is wrong. There is no x86_64 stime syscall
The STIG actually says that stime is not necessary, which is kind of a strange wording, but the suggested line in the fix text prose is correct, at least. So far as OVAL checks go, I haven't gotten to testing audit checks yet. Maybe this is broken. I'll check it out once I've deciphered the OVAL check.
171 clock_settime 184-196, 200 chmod, chown, etc...
Haven't tested audit checks yet...
206-211 No telnet installed or turned on
These are both automated checks. Unless the package name is wrong, I don't know why they'd give false positives.
240 /etc/ssh/sshd_config Banner
The OVAL check was definitely working on my system when I last tested it.
271 If there are no removable partitions this is not a finding.
Working on testing this one now...
278 If the file permissions are more restrictive then it is not a finding. 324 No X running
Agreed, the GNOME checks need to be rewritten to have extended definitions to exclude machines that don't have X installed.
326 "
?
346 Finding reported on umask 022
This is DEFINITELY a bug. The check section is actually pointing to a different check. The actual check for this rule was never written.
348 No vsftp installed, thus no file.
No OVAL check exists in SSG.
506 "hushlogin"
This one isn't in the SSG at all.
507 PrintLastLog
This one isn't in the SSG at all.
- Maura Dailey
Am I confused in thinking a system in run level 3 should net need to worry about X/Gnome findings?
Leam
-- Mind on a Mission http://leamhall.blogspot.com/
scap-security-guide mailing list scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
Hey Maura!
I'm using the openscap-utils rpm and the content from the Fedorahosted zip file.
On Wed, Aug 28, 2013 at 1:05 PM, Maura Dailey maura@eclipse.ncsc.milwrote:
On 08/28/2013 12:04 PM, leam hall wrote:
Hey all,
Just ran oscap with the xml files available on the website (Benchmark version 0.9). Here are the issues that seem to be false positives. Prefix everything with "RHEL-06-000". These are all marked as fail but the server meets the STIG.
Stupid question, but what are you running against exactly? The RPM or the latest git checkout? I want to make sure that if I run this, I'm seeing the same results, and I've made a lot of changes to OVAL checks in the git repository in the past few weeks. I'm going to run through your list, comparing it against the OVAL checks.
9 rhnsd can be on if configured to Satellite server or similar
Fix text definitely implies this. It's not the only service that implies it's allowed in certain environments, but then proceeds to only accept a value of disabled.
57 ucredit 58 ocredit 59 lcredit
For the previous 3, I'd like to see the pam_cracklib.so line so I can troubleshoot.
73 /etc/issue
Going back to my many many OVAL check updates, I'd like to see your exact /etc/issue so I can debug what went wrong. If it's an exact copy of the text from the STIG, I'll work off that.
98 No ipv6 installed
Do you mean it's disabled on your system, but the OVAL checks are saying it isn't?
99 "
?
165 adjtimex 167 settimeofday 169 stime // Also, the STIG is wrong. There is no x86_64 stime syscall
The STIG actually says that stime is not necessary, which is kind of a strange wording, but the suggested line in the fix text prose is correct, at least. So far as OVAL checks go, I haven't gotten to testing audit checks yet. Maybe this is broken. I'll check it out once I've deciphered the OVAL check.
171 clock_settime 184-196, 200 chmod, chown, etc...
Haven't tested audit checks yet...
206-211 No telnet installed or turned on
These are both automated checks. Unless the package name is wrong, I don't know why they'd give false positives.
240 /etc/ssh/sshd_config Banner
The OVAL check was definitely working on my system when I last tested it.
271 If there are no removable partitions this is not a finding.
Working on testing this one now...
278 If the file permissions are more restrictive then it is not a finding. 324 No X running
Agreed, the GNOME checks need to be rewritten to have extended definitions to exclude machines that don't have X installed.
326 "
?
346 Finding reported on umask 022
This is DEFINITELY a bug. The check section is actually pointing to a different check. The actual check for this rule was never written.
348 No vsftp installed, thus no file.
No OVAL check exists in SSG.
506 "hushlogin"
This one isn't in the SSG at all.
507 PrintLastLog
This one isn't in the SSG at all.
- Maura Dailey
Am I confused in thinking a system in run level 3 should net need to worry about X/Gnome findings?
Leam
-- Mind on a Mission http://leamhall.blogspot.com/
scap-security-guide mailing listscap-security-guide@lists.fedorahosted.orghttps://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
Maura, I'm using the yum repos for my latest download also instead of git. I can corroborate several of the false positives on my RHEL6 box after locking things down with Security Blanket, and manually reviewing the failures. There are several that need additional scrutiny. I used SCC 3.1 GA to run the checks as it seems to give me more insight into the results than oscap does (any suggestions on increasing the who/what/where/how/why logging w/o having to rebuild oscap from source appreciated). I'd just reverted the VM where I'd done the SCC scan so I don't have the results in front of me, but from memory :
57/58/59 - SCC was showing the line, including the correct value, then complaining that the value didn't match what it was looking for. Wonder if this is a case of not handling the leading '-' incorrectly?
73 - I know the RHEL5 STIG had an issue with whitespace at one point that I'd gotten around
206-211 I don't have telnet on my box either, but I think it may be treating the failure of finding /etc/xinetd.d/telnet as not finding 'disabled' in that file
240 I had this also, but we set the file to point to /etc/issue rather than /etc/issue.net. The *contents* of both files are the same (the correct banner). Perhaps the check should be checking the contents of whatever banner is being used rather than just the setting references the right file name?
-Rob
________________________________ From: scap-security-guide-bounces@lists.fedorahosted.org [scap-security-guide-bounces@lists.fedorahosted.org] on behalf of leam hall [leamhall@gmail.com] Sent: Wednesday, August 28, 2013 2:02 PM To: scap-security-guide@lists.fedorahosted.org Subject: Re: Various False Positives?
Hey Maura!
I'm using the openscap-utils rpm and the content from the Fedorahosted zip file.
On Wed, Aug 28, 2013 at 1:05 PM, Maura Dailey <maura@eclipse.ncsc.milmailto:maura@eclipse.ncsc.mil> wrote: On 08/28/2013 12:04 PM, leam hall wrote: Hey all,
Just ran oscap with the xml files available on the website (Benchmark version 0.9). Here are the issues that seem to be false positives. Prefix everything with "RHEL-06-000". These are all marked as fail but the server meets the STIG. Stupid question, but what are you running against exactly? The RPM or the latest git checkout? I want to make sure that if I run this, I'm seeing the same results, and I've made a lot of changes to OVAL checks in the git repository in the past few weeks. I'm going to run through your list, comparing it against the OVAL checks.
9 rhnsd can be on if configured to Satellite server or similar Fix text definitely implies this. It's not the only service that implies it's allowed in certain environments, but then proceeds to only accept a value of disabled.
57 ucredit 58 ocredit 59 lcredit For the previous 3, I'd like to see the pam_cracklib.so line so I can troubleshoot. 73 /etc/issue Going back to my many many OVAL check updates, I'd like to see your exact /etc/issue so I can debug what went wrong. If it's an exact copy of the text from the STIG, I'll work off that. 98 No ipv6 installed Do you mean it's disabled on your system, but the OVAL checks are saying it isn't? 99 " ?
165 adjtimex 167 settimeofday 169 stime // Also, the STIG is wrong. There is no x86_64 stime syscall The STIG actually says that stime is not necessary, which is kind of a strange wording, but the suggested line in the fix text prose is correct, at least. So far as OVAL checks go, I haven't gotten to testing audit checks yet. Maybe this is broken. I'll check it out once I've deciphered the OVAL check.
171 clock_settime 184-196, 200 chmod, chown, etc... Haven't tested audit checks yet...
206-211 No telnet installed or turned on These are both automated checks. Unless the package name is wrong, I don't know why they'd give false positives. 240 /etc/ssh/sshd_config Banner The OVAL check was definitely working on my system when I last tested it.
271 If there are no removable partitions this is not a finding. Working on testing this one now...
278 If the file permissions are more restrictive then it is not a finding. 324 No X running Agreed, the GNOME checks need to be rewritten to have extended definitions to exclude machines that don't have X installed. 326 " ?
346 Finding reported on umask 022 This is DEFINITELY a bug. The check section is actually pointing to a different check. The actual check for this rule was never written.
348 No vsftp installed, thus no file. No OVAL check exists in SSG. 506 "hushlogin" This one isn't in the SSG at all. 507 PrintLastLog This one isn't in the SSG at all.
- Maura Dailey
Am I confused in thinking a system in run level 3 should net need to worry about X/Gnome findings?
Leam
-- Mind on a Missionhttp://leamhall.blogspot.com/
_______________________________________________ scap-security-guide mailing list scap-security-guide@lists.fedorahosted.orgmailto: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.orgmailto:scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
-- Mind on a Missionhttp://leamhall.blogspot.com/
I'm not the one packaging up the rpm, so I don't know how out of date that is. I'd like Leam and you both to test against the git repository to see if any of my recent OVAL patches fix any of these problems. That will help me prioritize anything that's still broken.
I'll do a full run myself against the git repository in a little bit here, but I have some uncommitted changes that might lead to different results
Thanks, - Maura Dailey
On 08/28/2013 02:21 PM, Robert Sanders wrote:
Maura, I'm using the yum repos for my latest download also instead of git. I can corroborate several of the false positives on my RHEL6 box after locking things down with Security Blanket, and manually reviewing the failures. There are several that need additional scrutiny. I used SCC 3.1 GA to run the checks as it seems to give me more insight into the results than oscap does (any suggestions on increasing the who/what/where/how/why logging w/o having to rebuild oscap from source appreciated). I'd just reverted the VM where I'd done the SCC scan so I don't have the results in front of me, but from memory :
57/58/59 - SCC was showing the line, including the correct value, then complaining that the value didn't match what it was looking for. Wonder if this is a case of not handling the leading '-' incorrectly?
73 - I know the RHEL5 STIG had an issue with whitespace at one point that I'd gotten around
206-211 I don't have telnet on my box either, but I think it may be treating the failure of finding /etc/xinetd.d/telnet as not finding 'disabled' in that file
240 I had this also, but we set the file to point to /etc/issue rather than /etc/issue.net. The *contents* of both files are the same (the correct banner). Perhaps the check should be checking the contents of whatever banner is being used rather than just the setting references the right file name?
-Rob
*From:* scap-security-guide-bounces@lists.fedorahosted.org [scap-security-guide-bounces@lists.fedorahosted.org] on behalf of leam hall [leamhall@gmail.com] *Sent:* Wednesday, August 28, 2013 2:02 PM *To:* scap-security-guide@lists.fedorahosted.org *Subject:* Re: Various False Positives?
Hey Maura!
I'm using the openscap-utils rpm and the content from the Fedorahosted zip file.
On Wed, Aug 28, 2013 at 1:05 PM, Maura Dailey <maura@eclipse.ncsc.mil mailto:maura@eclipse.ncsc.mil> wrote:
On 08/28/2013 12:04 PM, leam hall wrote:Hey all, Just ran oscap with the xml files available on the website (Benchmark version 0.9). Here are the issues that seem to be false positives. Prefix everything with "RHEL-06-000". These are all marked as fail but the server meets the STIG.Stupid question, but what are you running against exactly? The RPM or the latest git checkout? I want to make sure that if I run this, I'm seeing the same results, and I've made a lot of changes to OVAL checks in the git repository in the past few weeks. I'm going to run through your list, comparing it against the OVAL checks.9 rhnsd can be on if configured to Satellite server or similarFix text definitely implies this. It's not the only service that implies it's allowed in certain environments, but then proceeds to only accept a value of disabled.57 ucredit 58 ocredit 59 lcreditFor the previous 3, I'd like to see the pam_cracklib.so line so I can troubleshoot.73 /etc/issueGoing back to my many many OVAL check updates, I'd like to see your exact /etc/issue so I can debug what went wrong. If it's an exact copy of the text from the STIG, I'll work off that.98 No ipv6 installedDo you mean it's disabled on your system, but the OVAL checks are saying it isn't?99 "?165 adjtimex 167 settimeofday 169 stime // Also, the STIG is wrong. There is no x86_64 stime syscallThe STIG actually says that stime is not necessary, which is kind of a strange wording, but the suggested line in the fix text prose is correct, at least. So far as OVAL checks go, I haven't gotten to testing audit checks yet. Maybe this is broken. I'll check it out once I've deciphered the OVAL check.171 clock_settime 184-196, 200 chmod, chown, etc...Haven't tested audit checks yet...206-211 No telnet installed or turned onThese are both automated checks. Unless the package name is wrong, I don't know why they'd give false positives.240 /etc/ssh/sshd_config BannerThe OVAL check was definitely working on my system when I last tested it.271 If there are no removable partitions this is not a finding.Working on testing this one now...278 If the file permissions are more restrictive then it is not a finding. 324 No X runningAgreed, the GNOME checks need to be rewritten to have extended definitions to exclude machines that don't have X installed.326 "?346 Finding reported on umask 022This is DEFINITELY a bug. The check section is actually pointing to a different check. The actual check for this rule was never written.348 No vsftp installed, thus no file.No OVAL check exists in SSG.506 "hushlogin"This one isn't in the SSG at all.507 PrintLastLogThis one isn't in the SSG at all. - Maura DaileyAm I confused in thinking a system in run level 3 should net need to worry about X/Gnome findings? Leam -- Mind on a Mission <http://leamhall.blogspot.com/> _______________________________________________ scap-security-guide mailing list scap-security-guide@lists.fedorahosted.org <mailto: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 <mailto:scap-security-guide@lists.fedorahosted.org> https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide-- Mind on a Mission http://leamhall.blogspot.com/
scap-security-guide mailing list scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
On 8/28/13 2:02 PM, leam hall wrote:
Hey Maura!
I'm using the openscap-utils rpm and the content from the Fedorahosted zip file.
On Wed, Aug 28, 2013 at 1:05 PM, Maura Dailey <maura@eclipse.ncsc.mil mailto:maura@eclipse.ncsc.mil> wrote:
On 08/28/2013 12:04 PM, leam hall wrote:Hey all, Just ran oscap with the xml files available on the website (Benchmark version 0.9). Here are the issues that seem to be false positives. Prefix everything with "RHEL-06-000". These are all marked as fail but the server meets the STIG.Stupid question, but what are you running against exactly? The RPM or the latest git checkout? I want to make sure that if I run this, I'm seeing the same results, and I've made a lot of changes to OVAL checks in the git repository in the past few weeks. I'm going to run through your list, comparing it against the OVAL checks.9 rhnsd can be on if configured to Satellite server or similarFix text definitely implies this. It's not the only service that implies it's allowed in certain environments, but then proceeds to only accept a value of disabled.57 ucredit
STIG wants ucredit=-1, so to test:
[shawn@rhel6 checks]$ grep ucredit /etc/pam.d/system-auth password requisite pam_cracklib.so try_first_pass retry=3 ucredit=-1
[shawn@rhel6 checks]$ var_password_pam_cracklib_ucredit=-1 ; export var_password_pam_cracklib_ucredit [shawn@rhel6 checks]$ ./testcheck.py accounts_password_pam_cracklib_ucredit.xml external_variable with id : var_password_pam_cracklib_ucredit Evaluating with OVAL tempfile : /tmp/accounts_password_pam_cracklib_ucredit4WnLnw.xml Writing results to : /tmp/accounts_password_pam_cracklib_ucredit4WnLnw.xml-results Definition oval:scap-security-guide.testing:def:112: true Evaluation done.
/Side note: stig-rhel6-server was inheriting var_password_pam_cracklib_ucredit=2 from common. Created patch to set var_password_pam_cracklib_ucredit=-1 for STIG requirements./
58 ocredit
[shawn@rhel6 checks]$ grep ocredit /etc/pam.d/system-auth password requisite pam_cracklib.so try_first_pass retry=3 ucredit=-1 *ocredit=5* [shawn@rhel6 checks]$ var_password_pam_cracklib_ocredit=-1 ; export var_password_pam_cracklib_ocredit [shawn@rhel6 checks]$ ./testcheck.py accounts_password_pam_cracklib_ocredit.xml external_variable with id : var_password_pam_cracklib_ocredit Evaluating with OVAL tempfile : /tmp/accounts_password_pam_cracklib_ocreditatN3pc.xml Writing results to : /tmp/accounts_password_pam_cracklib_ocreditatN3pc.xml-results Definition oval:scap-security-guide.testing:def:117: false Evaluation done.
[shawn@rhel6 checks]$ sudo vim ocredit /etc/pam.d/system-auth [shawn@rhel6 checks]$ grep ocredit /etc/pam.d/system-auth password requisite pam_cracklib.so try_first_pass retry=3 ucredit=-1 *ocredit=-1* [shawn@rhel6 checks]$ ./testcheck.py accounts_password_pam_cracklib_ocredit.xml external_variable with id : var_password_pam_cracklib_ocredit Evaluating with OVAL tempfile : /tmp/accounts_password_pam_cracklib_ocreditKrBREl.xml Writing results to : /tmp/accounts_password_pam_cracklib_ocreditKrBREl.xml-results Definition oval:scap-security-guide.testing:def:117: true Evaluation done.
/Side note: var_password_pam_cracklib_ocredit=2 inherited from common. Updated STIG profile for var_password_pam_cracklib_ocredit=-1/
59 lcredit
[shawn@rhel6 checks]$ var_password_pam_cracklib_lcredit=-1 ; export var_password_pam_cracklib_lcredit [shawn@rhel6 checks]$ grep lcredit /etc/pam.d/system-auth password requisite pam_cracklib.so try_first_pass retry=3 ucredit=-1 ocredit=-1*lcredit=5* [shawn@rhel6 checks]$ ./testcheck.py accounts_password_pam_cracklib_lcredit.xml external_variable with id : var_password_pam_cracklib_lcredit Evaluating with OVAL tempfile : /tmp/accounts_password_pam_cracklib_lcredit40ApZj.xml Writing results to : /tmp/accounts_password_pam_cracklib_lcredit40ApZj.xml-results Definition oval:scap-security-guide.testing:def:122: false Evaluation done.
[shawn@rhel6 checks]$ sudo vim /etc/pam.d/system-auth [sudo] password for shawn: [shawn@rhel6 checks]$ sudo vim /etc/pam.d/system-auth [shawn@rhel6 checks]$ grep lcredit /etc/pam.d/system-auth password requisite pam_cracklib.so try_first_pass retry=3 ucredit=-1 ocredit=-1 *lcredit=-1* [shawn@rhel6 checks]$ ./testcheck.py accounts_password_pam_cracklib_lcredit.xml external_variable with id : var_password_pam_cracklib_lcredit Evaluating with OVAL tempfile : /tmp/accounts_password_pam_cracklib_lcreditxktRcT.xml Writing results to : /tmp/accounts_password_pam_cracklib_lcreditxktRcT.xml-results Definition oval:scap-security-guide.testing:def:122: true Evaluation done.
[shawn@rhel6 checks]$ sudo vim /etc/pam.d/system-auth [shawn@rhel6 checks]$ grep lcredit /etc/pam.d/system-auth password requisite pam_cracklib.so try_first_pass retry=3 ucredit=-1 ocredit=-1 *lcredit=-5* [shawn@rhel6 checks]$ ./testcheck.py accounts_password_pam_cracklib_lcredit.xml external_variable with id : var_password_pam_cracklib_lcredit Evaluating with OVAL tempfile : /tmp/accounts_password_pam_cracklib_lcreditZr4xu0.xml Writing results to : /tmp/accounts_password_pam_cracklib_lcreditZr4xu0.xml-results Definition oval:scap-security-guide.testing:def:122: true Evaluation done.
/Side note: var_password_pam_cracklib_lcredit=2 inherited from common. Updated STIG profile for var_password_pam_cracklib_lcredit=-1/
For the previous 3, I'd like to see the pam_cracklib.so line so I can troubleshoot.
As Maura mentioned, can you send your /etc/pam.d/system-auth file? I had trouble reproducing your results.
73 /etc/issueGoing back to my many many OVAL check updates, I'd like to see your exact /etc/issue so I can debug what went wrong. If it's an exact copy of the text from the STIG, I'll work off that.
Skipping since Maura has the regex foo for this :)
98 No ipv6 installedDo you mean it's disabled on your system, but the OVAL checks are saying it isn't?
[shawn@rhel6 checks]$ sudo vim /etc/modprobe.d/disabled.conf ; cat /etc/modprobe.d/disabled.conf ; \
./testcheck.py kernel_module_ipv6_option_disabled.xml ; \ sudo vim /etc/modprobe.d/disabled.conf ; cat
/etc/modprobe.d/disabled.conf ; \
./testcheck.py kernel_module_ipv6_option_disabled.xml
options ipv6 disable=1 Evaluating with OVAL tempfile : /tmp/kernel_module_ipv6_option_disabledv3NN_r.xml Writing results to : /tmp/kernel_module_ipv6_option_disabledv3NN_r.xml-results Definition oval:scap-security-guide.testing:def:127: true Evaluation done. Evaluating with OVAL tempfile : /tmp/kernel_module_ipv6_option_disabledTJDTEF.xml Writing results to : /tmp/kernel_module_ipv6_option_disabledTJDTEF.xml-results Definition oval:scap-security-guide.testing:def:127: false Evaluation done.
Appears working. Can you send where you disabled IPv6?
99 "?
RHEL-06-000099: The system must ignore ICMPv6 redirects by default. aka sysctl_net_ipv6_conf_default_accept_redirects.xml
[root@rhel6 checks]# sysctl -q -n -w net.ipv6.conf.default.accept_redirects=0 [root@rhel6 checks]# ./testcheck.py sysctl_net_ipv6_conf_default_accept_redirects.xml Evaluating with OVAL tempfile : /tmp/sysctl_net_ipv6_conf_default_accept_redirectsNkZern.xml Writing results to : /tmp/sysctl_net_ipv6_conf_default_accept_redirectsNkZern.xml-results Definition oval:scap-security-guide.testing:def:130: true Evaluation done. [root@rhel6 checks]# sysctl -q -n -w net.ipv6.conf.default.accept_redirects=1 [root@rhel6 checks]# ./testcheck.py sysctl_net_ipv6_conf_default_accept_redirects.xml Evaluating with OVAL tempfile : /tmp/sysctl_net_ipv6_conf_default_accept_redirects6Xp7Wz.xml Writing results to : /tmp/sysctl_net_ipv6_conf_default_accept_redirects6Xp7Wz.xml-results Definition oval:scap-security-guide.testing:def:130: false Evaluation done.
Can you send us the output of: `grep net.ipv6.conf.default.accept_redirects /etc/sysctl.conf` and `sysctl -a | grep net.ipv6.conf.default.accept_redirects`
165 adjtimex
[root@rhel6 checks]# echo "-a always,exit -F arch=b64 -S adjtimex -k audit_time_rules" >> /etc/audit/audit.rules [root@rhel6 checks]# ./testcheck.py audit_rules_time_adjtimex.xml Evaluating with OVAL tempfile : /tmp/audit_rules_time_adjtimexQoelxQ.xml Writing results to : /tmp/audit_rules_time_adjtimexQoelxQ.xml-results Definition oval:scap-security-guide.testing:def:137: true Definition oval:scap-security-guide.testing:def:135: false Definition oval:scap-security-guide.testing:def:134: true Evaluation done.
Since these operate on OR's, the false is checking for 32bit auditing rules. Ultimately, this results in a pass.
Can you send the output of 'grep adjtimex /etc/audit/audit.rules' ?
167 settimeofday
[root@rhel6 checks]# echo "-a always,exit -F arch=b64 -S settimeofday -k audit_time_rules" >> /etc/audit/audit.rules [root@rhel6 checks]# ./testcheck.py audit_rules_time_settimeofday.xml Evaluating with OVAL tempfile : /tmp/audit_rules_time_settimeofday9TYIqD.xml Writing results to : /tmp/audit_rules_time_settimeofday9TYIqD.xml-results Definition oval:scap-security-guide.testing:def:147: true Definition oval:scap-security-guide.testing:def:137: true Definition oval:scap-security-guide.testing:def:135: false Evaluation done. (passes)
Can you send the output of 'grep settimeofday /etc/audit/audit.rules' ?
169 stime // Also, the STIG is wrong. There is no x86_64 stime syscallThe STIG actually says that stime is not necessary, which is kind of a strange wording, but the suggested line in the fix text prose is correct, at least. So far as OVAL checks go, I haven't gotten to testing audit checks yet. Maybe this is broken. I'll check it out once I've deciphered the OVAL check.
[root@rhel6 RHEL6]# echo "-a always,exit -F arch=b32 -S stime -k audit_time_rules" >> /etc/audit/audit.rules [root@rhel6 RHEL6]# cd input/checks/ [root@rhel6 checks]# ./testcheck.py audit_rules_time_s audit_rules_time_settimeofday.xml audit_rules_time_stime.xml [root@rhel6 checks]# ./testcheck.py audit_rules_time_stime.xml Evaluating with OVAL tempfile : /tmp/audit_rules_time_stime4hUFRb.xml Writing results to : /tmp/audit_rules_time_stime4hUFRb.xml-results Definition oval:scap-security-guide.testing:def:152: true Definition oval:scap-security-guide.testing:def:137: true Definition oval:scap-security-guide.testing:def:135: false Evaluation done.
Can you send the output of 'grep stime /etc/audit/audit.rules' ?
171 clock_settime
[root@rhel6 checks]# echo "-a always,exit -F arch=b64 -S clock_settime -k audit_time_rules" >> /etc/audit/audit.rules [root@rhel6 checks]# ./testcheck.py audit_rules_time_clock_settime.xml Evaluating with OVAL tempfile : /tmp/audit_rules_time_clock_settime2SUHvv.xml Writing results to : /tmp/audit_rules_time_clock_settime2SUHvv.xml-results Definition oval:scap-security-guide.testing:def:155: true Definition oval:scap-security-guide.testing:def:137: true Definition oval:scap-security-guide.testing:def:135: false Evaluation done.
Can you send the output of 'grep clock_settime /etc/audit/audit.rules' ?
184-196, 200 chmod, chown, etc...Haven't tested audit checks yet...
[root@rhel6 checks]# echo "-a always,exit -F arch=b64 -S chmod -S fchmod -S fchmodat -F auid>=500 -F auid!=4294967295 -k perm_mod" >> /etc/audit/audit.rules [root@rhel6 checks]# ./testcheck.py audit_rules_dac_modification_chmod.xml Evaluating with OVAL tempfile : /tmp/audit_rules_dac_modification_chmodA0U8eF.xml Writing results to : /tmp/audit_rules_dac_modification_chmodA0U8eF.xml-results Definition oval:scap-security-guide.testing:def:160: true Definition oval:scap-security-guide.testing:def:137: true Evaluation done. [root@rhel6 checks]# ./testcheck.py audit_rules_dac_modification_fchmod.xml Evaluating with OVAL tempfile : /tmp/audit_rules_dac_modification_fchmodrqtEUo.xml Writing results to : /tmp/audit_rules_dac_modification_fchmodrqtEUo.xml-results Definition oval:scap-security-guide.testing:def:180: false Definition oval:scap-security-guide.testing:def:137: true Evaluation done. [root@rhel6 checks]# ./testcheck.py audit_rules_dac_modification_fchmodat.xml Evaluating with OVAL tempfile : /tmp/audit_rules_dac_modification_fchmodat5jgwg5.xml Writing results to : /tmp/audit_rules_dac_modification_fchmodat5jgwg5.xml-results Definition oval:scap-security-guide.testing:def:185: false Definition oval:scap-security-guide.testing:def:137: true Evaluation done.
[root@rhel6 checks]# echo "-a always,exit -F arch=b64 -S chown -S fchown -S fchownat -S lchown -F auid>=500 -F auid!=4294967295 -k perm_mod" >> /etc/audit/audit.rules [root@rhel6 checks]# ./testcheck.py audit_rules_dac_modification_fchown.xml Evaluating with OVAL tempfile : /tmp/audit_rules_dac_modification_fchownR4dTLm.xml Writing results to : /tmp/audit_rules_dac_modification_fchownR4dTLm.xml-results Definition oval:scap-security-guide.testing:def:165: false Definition oval:scap-security-guide.testing:def:137: true Evaluation done. [root@rhel6 checks]# ./testcheck.py audit_rules_dac_modification_fchownat.xml Evaluating with OVAL tempfile : /tmp/audit_rules_dac_modification_fchownata3WKRL.xml Writing results to : /tmp/audit_rules_dac_modification_fchownata3WKRL.xml-results Definition oval:scap-security-guide.testing:def:170: false Definition oval:scap-security-guide.testing:def:137: true Evaluation done. [root@rhel6 checks]# ./testcheck.py audit_rules_dac_modification_lchown.xml Evaluating with OVAL tempfile : /tmp/audit_rules_dac_modification_lchownmX0BTK.xml Writing results to : /tmp/audit_rules_dac_modification_lchownmX0BTK.xml-results Definition oval:scap-security-guide.testing:def:175: false Definition oval:scap-security-guide.testing:def:137: true Evaluation done.
Please send relevant lines from audit.rules
206-211 No telnet installed or turned onThese are both automated checks. Unless the package name is wrong, I don't know why they'd give false positives.
This is broke. I forgot who originally reported, but we still need to update the telnet checks to use the xinet templates.
240 /etc/ssh/sshd_config BannerThe OVAL check was definitely working on my system when I last tested it.
I'm able to reproduce...
[root@rhel6 checks]# cat /etc/issue You are accessing a U.S. Government (USG) Information System (IS) that is provided for USG-authorized use only. By using this IS (which includes any device attached to this IS), you consent to the following conditions: -The USG routinely intercepts and monitors communications on this IS for purposes including, but not limited to, penetration testing, COMSEC monitoring, network operations and defense, personnel misconduct (PM), law enforcement (LE), and counterintelligence (CI) investigations. -At any time, the USG may inspect and seize data stored on this IS. -Communications using, or data stored on, this IS are not private, are subject to routine monitoring, interception, and search, and may be disclosed or used for any USG-authorized purpose. -This IS includes security measures (e.g., authentication and access controls) to protect USG interests -- not for your personal benefit or privacy. -Notwithstanding the above, using this IS does not constitute consent to PM, LE or CI investigative searching or monitoring of the content of privileged communications, or work product, related to personal representation or services by attorneys, psychotherapists, or clergy, and their assistants. Such communications and work product are private and confidential. See User Agreement for details.
[root@rhel6 checks]# ./testcheck.py sshd_banner_set.xml Evaluating with OVAL tempfile : /tmp/sshd_banner_setXKCJxI.xml Writing results to : /tmp/sshd_banner_setXKCJxI.xml-results Definition oval:scap-security-guide.testing:def:193: false Definition oval:scap-security-guide.testing:def:191: false Definition oval:scap-security-guide.testing:def:190: false Evaluation done.
Maura, do you want to take a stab at this (noticed your signoff on the OVAL)?
FWIW, if I used the USGCB banner everything worked OK.
271 If there are no removable partitions this is not a finding.Working on testing this one now...
Skipping in my testing then
278 If the file permissions are more restrictive then it is not a finding.
This pairs with rpm_verify_permissions, which has the following criterion checks:
<criteria operator="AND"> <criterion test_ref="test_verify_all_rpms_user_ownership"comment="user ownership of all files matches local rpm database" /> <criterion test_ref="test_verify_all_rpms_group_ownership" comment="group ownership of all files matches local rpm database" /> <criterion test_ref="test_verify_all_rpms_mode" comment="mode of all files matches local rpm database" /> </criteria>
Can you send what files are being reported? It should only hit on ownership mismatches.
324 No X runningAgreed, the GNOME checks need to be rewritten to have extended definitions to exclude machines that don't have X installed.
Which package(s) should we check for? xorg-x11-server-Xorg? gnome-desktop?
326 "?
Same thing as 324
346 Finding reported on umask 022This is DEFINITELY a bug. The check section is actually pointing to a different check. The actual check for this rule was never written.
The XCCDF (set_daemon_umask) points to:
<oval id="umask_for_daemons" value="var_umask_for_daemons"/>
so, to test: [shawn@rhel6 checks]$ grep umask /etc/init.d/functions # Make sure umask is sane umask 022 [shawn@rhel6 checks]$ var_umask_for_daemons=022 ; export var_umask_for_daemons [shawn@rhel6 checks]$ ./testcheck.py umask_for_daemons.xml external_variable with id : var_umask_for_daemons Evaluating with OVAL tempfile : /tmp/umask_for_daemonsvX5U0G.xml Writing results to : /tmp/umask_for_daemonsvX5U0G.xml-results Definition oval:scap-security-guide.testing:def:212: false Evaluation done.
but then in the OVAL code, it's looking at the wrong place: <ind:textfilecontent54_object id="object_umask_for_daemons" version="1"> ind:path/etc/sysconfig</ind:path> ind:filenameinit</ind:filename> <ind:pattern operation="pattern match">umask[\s]+(.*)</ind:pattern> <ind:instance datatype="int">1</ind:instance> </ind:textfilecontent54_object>
verified no other XCCDF rule was using this OVAL: [shawn@rhel6 input]$ grep -rin umask_for_daemons system/* system/permissions/execution.xml:18:<Value id="var_umask_for_daemons" type="string" operator="equals" interactive="0"> system/permissions/execution.xml:47:<oval id="umask_for_daemons" value="var_umask_for_daemons"/>
.... wrote a patch to fix the pattern match expression, and file path things seem OK now: [shawn@rhel6 checks]$ var_umask_for_daemons=022 ; export var_umask_for_daemons [shawn@rhel6 checks]$ ./testcheck.py umask_for_daemons.xml external_variable with id : var_umask_for_daemons Evaluating with OVAL tempfile : /tmp/umask_for_daemons394CCR.xml Writing results to : /tmp/umask_for_daemons394CCR.xml-results Definition oval:scap-security-guide.testing:def:212: true Evaluation done.
348 No vsftp installed, thus no file.No OVAL check exists in SSG.
Created https://fedorahosted.org/scap-security-guide/ticket/411 to track
506 "hushlogin"This one isn't in the SSG at all.507 PrintLastLogThis one isn't in the SSG at all.
Not sure how/why DISA FSO slid these in. Leland?
Yes -- a few items seem to be surprise additions via FSO, but overall the working experience has been a positive one and we look forward to working together in the future per the Vendor STIG process.
We'll attempt to reach consensus on those items before long; we need an itemized list of these for evaluation.
On Sun, Sep 1, 2013 at 10:08 AM, Shawn Wells shawn@redhat.com wrote:
On 8/28/13 2:02 PM, leam hall wrote:
Hey Maura!
I'm using the openscap-utils rpm and the content from the Fedorahosted zip file.
On Wed, Aug 28, 2013 at 1:05 PM, Maura Dailey maura@eclipse.ncsc.mil wrote:
On 08/28/2013 12:04 PM, leam hall wrote:
Hey all,
Just ran oscap with the xml files available on the website (Benchmark version 0.9). Here are the issues that seem to be false positives. Prefix everything with "RHEL-06-000". These are all marked as fail but the server meets the STIG.
Stupid question, but what are you running against exactly? The RPM or the latest git checkout? I want to make sure that if I run this, I'm seeing the same results, and I've made a lot of changes to OVAL checks in the git repository in the past few weeks. I'm going to run through your list, comparing it against the OVAL checks.
9 rhnsd can be on if configured to Satellite server or similar
Fix text definitely implies this. It's not the only service that implies it's allowed in certain environments, but then proceeds to only accept a value of disabled.
57 ucredit
STIG wants ucredit=-1, so to test:
[shawn@rhel6 checks]$ grep ucredit /etc/pam.d/system-auth password requisite pam_cracklib.so try_first_pass retry=3 ucredit=-1
[shawn@rhel6 checks]$ var_password_pam_cracklib_ucredit=-1 ; export var_password_pam_cracklib_ucredit [shawn@rhel6 checks]$ ./testcheck.py accounts_password_pam_cracklib_ucredit.xml external_variable with id : var_password_pam_cracklib_ucredit Evaluating with OVAL tempfile : /tmp/accounts_password_pam_cracklib_ucredit4WnLnw.xml Writing results to : /tmp/accounts_password_pam_cracklib_ucredit4WnLnw.xml-results Definition oval:scap-security-guide.testing:def:112: true Evaluation done.
Side note: stig-rhel6-server was inheriting var_password_pam_cracklib_ucredit=2 from common. Created patch to set var_password_pam_cracklib_ucredit=-1 for STIG requirements.
58 ocredit
[shawn@rhel6 checks]$ grep ocredit /etc/pam.d/system-auth password requisite pam_cracklib.so try_first_pass retry=3 ucredit=-1 ocredit=5 [shawn@rhel6 checks]$ var_password_pam_cracklib_ocredit=-1 ; export var_password_pam_cracklib_ocredit [shawn@rhel6 checks]$ ./testcheck.py accounts_password_pam_cracklib_ocredit.xml external_variable with id : var_password_pam_cracklib_ocredit Evaluating with OVAL tempfile : /tmp/accounts_password_pam_cracklib_ocreditatN3pc.xml Writing results to : /tmp/accounts_password_pam_cracklib_ocreditatN3pc.xml-results Definition oval:scap-security-guide.testing:def:117: false Evaluation done.
[shawn@rhel6 checks]$ sudo vim ocredit /etc/pam.d/system-auth [shawn@rhel6 checks]$ grep ocredit /etc/pam.d/system-auth password requisite pam_cracklib.so try_first_pass retry=3 ucredit=-1 ocredit=-1 [shawn@rhel6 checks]$ ./testcheck.py accounts_password_pam_cracklib_ocredit.xml external_variable with id : var_password_pam_cracklib_ocredit Evaluating with OVAL tempfile : /tmp/accounts_password_pam_cracklib_ocreditKrBREl.xml Writing results to : /tmp/accounts_password_pam_cracklib_ocreditKrBREl.xml-results Definition oval:scap-security-guide.testing:def:117: true Evaluation done.
Side note: var_password_pam_cracklib_ocredit=2 inherited from common. Updated STIG profile for var_password_pam_cracklib_ocredit=-1
59 lcredit
[shawn@rhel6 checks]$ var_password_pam_cracklib_lcredit=-1 ; export var_password_pam_cracklib_lcredit [shawn@rhel6 checks]$ grep lcredit /etc/pam.d/system-auth password requisite pam_cracklib.so try_first_pass retry=3 ucredit=-1 ocredit=-1 lcredit=5 [shawn@rhel6 checks]$ ./testcheck.py accounts_password_pam_cracklib_lcredit.xml external_variable with id : var_password_pam_cracklib_lcredit Evaluating with OVAL tempfile : /tmp/accounts_password_pam_cracklib_lcredit40ApZj.xml Writing results to : /tmp/accounts_password_pam_cracklib_lcredit40ApZj.xml-results Definition oval:scap-security-guide.testing:def:122: false Evaluation done.
[shawn@rhel6 checks]$ sudo vim /etc/pam.d/system-auth [sudo] password for shawn: [shawn@rhel6 checks]$ sudo vim /etc/pam.d/system-auth [shawn@rhel6 checks]$ grep lcredit /etc/pam.d/system-auth password requisite pam_cracklib.so try_first_pass retry=3 ucredit=-1 ocredit=-1 lcredit=-1 [shawn@rhel6 checks]$ ./testcheck.py accounts_password_pam_cracklib_lcredit.xml external_variable with id : var_password_pam_cracklib_lcredit Evaluating with OVAL tempfile : /tmp/accounts_password_pam_cracklib_lcreditxktRcT.xml Writing results to : /tmp/accounts_password_pam_cracklib_lcreditxktRcT.xml-results Definition oval:scap-security-guide.testing:def:122: true Evaluation done.
[shawn@rhel6 checks]$ sudo vim /etc/pam.d/system-auth [shawn@rhel6 checks]$ grep lcredit /etc/pam.d/system-auth password requisite pam_cracklib.so try_first_pass retry=3 ucredit=-1 ocredit=-1 lcredit=-5 [shawn@rhel6 checks]$ ./testcheck.py accounts_password_pam_cracklib_lcredit.xml external_variable with id : var_password_pam_cracklib_lcredit Evaluating with OVAL tempfile : /tmp/accounts_password_pam_cracklib_lcreditZr4xu0.xml Writing results to : /tmp/accounts_password_pam_cracklib_lcreditZr4xu0.xml-results Definition oval:scap-security-guide.testing:def:122: true Evaluation done.
Side note: var_password_pam_cracklib_lcredit=2 inherited from common. Updated STIG profile for var_password_pam_cracklib_lcredit=-1
For the previous 3, I'd like to see the pam_cracklib.so line so I can troubleshoot.
As Maura mentioned, can you send your /etc/pam.d/system-auth file? I had trouble reproducing your results.
73 /etc/issue
Going back to my many many OVAL check updates, I'd like to see your exact /etc/issue so I can debug what went wrong. If it's an exact copy of the text from the STIG, I'll work off that.
Skipping since Maura has the regex foo for this :)
98 No ipv6 installed
Do you mean it's disabled on your system, but the OVAL checks are saying it isn't?
[shawn@rhel6 checks]$ sudo vim /etc/modprobe.d/disabled.conf ; cat /etc/modprobe.d/disabled.conf ; \
./testcheck.py kernel_module_ipv6_option_disabled.xml ; \ sudo vim /etc/modprobe.d/disabled.conf ; cat /etc/modprobe.d/disabled.conf ; \ ./testcheck.py kernel_module_ipv6_option_disabled.xml
options ipv6 disable=1 Evaluating with OVAL tempfile : /tmp/kernel_module_ipv6_option_disabledv3NN_r.xml Writing results to : /tmp/kernel_module_ipv6_option_disabledv3NN_r.xml-results Definition oval:scap-security-guide.testing:def:127: true Evaluation done. Evaluating with OVAL tempfile : /tmp/kernel_module_ipv6_option_disabledTJDTEF.xml Writing results to : /tmp/kernel_module_ipv6_option_disabledTJDTEF.xml-results Definition oval:scap-security-guide.testing:def:127: false Evaluation done.
Appears working. Can you send where you disabled IPv6?
99 "
?
RHEL-06-000099: The system must ignore ICMPv6 redirects by default. aka sysctl_net_ipv6_conf_default_accept_redirects.xml
[root@rhel6 checks]# sysctl -q -n -w net.ipv6.conf.default.accept_redirects=0 [root@rhel6 checks]# ./testcheck.py sysctl_net_ipv6_conf_default_accept_redirects.xml Evaluating with OVAL tempfile : /tmp/sysctl_net_ipv6_conf_default_accept_redirectsNkZern.xml Writing results to : /tmp/sysctl_net_ipv6_conf_default_accept_redirectsNkZern.xml-results Definition oval:scap-security-guide.testing:def:130: true Evaluation done. [root@rhel6 checks]# sysctl -q -n -w net.ipv6.conf.default.accept_redirects=1 [root@rhel6 checks]# ./testcheck.py sysctl_net_ipv6_conf_default_accept_redirects.xml Evaluating with OVAL tempfile : /tmp/sysctl_net_ipv6_conf_default_accept_redirects6Xp7Wz.xml Writing results to : /tmp/sysctl_net_ipv6_conf_default_accept_redirects6Xp7Wz.xml-results Definition oval:scap-security-guide.testing:def:130: false Evaluation done.
Can you send us the output of: `grep net.ipv6.conf.default.accept_redirects /etc/sysctl.conf` and `sysctl -a | grep net.ipv6.conf.default.accept_redirects`
165 adjtimex
[root@rhel6 checks]# echo "-a always,exit -F arch=b64 -S adjtimex -k audit_time_rules" >> /etc/audit/audit.rules [root@rhel6 checks]# ./testcheck.py audit_rules_time_adjtimex.xml Evaluating with OVAL tempfile : /tmp/audit_rules_time_adjtimexQoelxQ.xml Writing results to : /tmp/audit_rules_time_adjtimexQoelxQ.xml-results Definition oval:scap-security-guide.testing:def:137: true Definition oval:scap-security-guide.testing:def:135: false Definition oval:scap-security-guide.testing:def:134: true Evaluation done.
Since these operate on OR's, the false is checking for 32bit auditing rules. Ultimately, this results in a pass.
Can you send the output of 'grep adjtimex /etc/audit/audit.rules' ?
167 settimeofday
[root@rhel6 checks]# echo "-a always,exit -F arch=b64 -S settimeofday -k audit_time_rules" >> /etc/audit/audit.rules [root@rhel6 checks]# ./testcheck.py audit_rules_time_settimeofday.xml Evaluating with OVAL tempfile : /tmp/audit_rules_time_settimeofday9TYIqD.xml Writing results to : /tmp/audit_rules_time_settimeofday9TYIqD.xml-results Definition oval:scap-security-guide.testing:def:147: true Definition oval:scap-security-guide.testing:def:137: true Definition oval:scap-security-guide.testing:def:135: false Evaluation done. (passes)
Can you send the output of 'grep settimeofday /etc/audit/audit.rules' ?
169 stime // Also, the STIG is wrong. There is no x86_64 stime syscall
The STIG actually says that stime is not necessary, which is kind of a strange wording, but the suggested line in the fix text prose is correct, at least. So far as OVAL checks go, I haven't gotten to testing audit checks yet. Maybe this is broken. I'll check it out once I've deciphered the OVAL check.
[root@rhel6 RHEL6]# echo "-a always,exit -F arch=b32 -S stime -k audit_time_rules" >> /etc/audit/audit.rules [root@rhel6 RHEL6]# cd input/checks/ [root@rhel6 checks]# ./testcheck.py audit_rules_time_s audit_rules_time_settimeofday.xml audit_rules_time_stime.xml [root@rhel6 checks]# ./testcheck.py audit_rules_time_stime.xml Evaluating with OVAL tempfile : /tmp/audit_rules_time_stime4hUFRb.xml Writing results to : /tmp/audit_rules_time_stime4hUFRb.xml-results Definition oval:scap-security-guide.testing:def:152: true Definition oval:scap-security-guide.testing:def:137: true Definition oval:scap-security-guide.testing:def:135: false Evaluation done.
Can you send the output of 'grep stime /etc/audit/audit.rules' ?
171 clock_settime
[root@rhel6 checks]# echo "-a always,exit -F arch=b64 -S clock_settime -k audit_time_rules" >> /etc/audit/audit.rules [root@rhel6 checks]# ./testcheck.py audit_rules_time_clock_settime.xml Evaluating with OVAL tempfile : /tmp/audit_rules_time_clock_settime2SUHvv.xml Writing results to : /tmp/audit_rules_time_clock_settime2SUHvv.xml-results Definition oval:scap-security-guide.testing:def:155: true Definition oval:scap-security-guide.testing:def:137: true Definition oval:scap-security-guide.testing:def:135: false Evaluation done.
Can you send the output of 'grep clock_settime /etc/audit/audit.rules' ?
184-196, 200 chmod, chown, etc...
Haven't tested audit checks yet...
[root@rhel6 checks]# echo "-a always,exit -F arch=b64 -S chmod -S fchmod -S fchmodat -F auid>=500 -F auid!=4294967295 -k perm_mod" >> /etc/audit/audit.rules [root@rhel6 checks]# ./testcheck.py audit_rules_dac_modification_chmod.xml Evaluating with OVAL tempfile : /tmp/audit_rules_dac_modification_chmodA0U8eF.xml Writing results to : /tmp/audit_rules_dac_modification_chmodA0U8eF.xml-results Definition oval:scap-security-guide.testing:def:160: true Definition oval:scap-security-guide.testing:def:137: true Evaluation done. [root@rhel6 checks]# ./testcheck.py audit_rules_dac_modification_fchmod.xml Evaluating with OVAL tempfile : /tmp/audit_rules_dac_modification_fchmodrqtEUo.xml Writing results to : /tmp/audit_rules_dac_modification_fchmodrqtEUo.xml-results Definition oval:scap-security-guide.testing:def:180: false Definition oval:scap-security-guide.testing:def:137: true Evaluation done. [root@rhel6 checks]# ./testcheck.py audit_rules_dac_modification_fchmodat.xml Evaluating with OVAL tempfile : /tmp/audit_rules_dac_modification_fchmodat5jgwg5.xml Writing results to : /tmp/audit_rules_dac_modification_fchmodat5jgwg5.xml-results Definition oval:scap-security-guide.testing:def:185: false Definition oval:scap-security-guide.testing:def:137: true Evaluation done.
[root@rhel6 checks]# echo "-a always,exit -F arch=b64 -S chown -S fchown -S fchownat -S lchown -F auid>=500 -F auid!=4294967295 -k perm_mod" >> /etc/audit/audit.rules [root@rhel6 checks]# ./testcheck.py audit_rules_dac_modification_fchown.xml Evaluating with OVAL tempfile : /tmp/audit_rules_dac_modification_fchownR4dTLm.xml Writing results to : /tmp/audit_rules_dac_modification_fchownR4dTLm.xml-results Definition oval:scap-security-guide.testing:def:165: false Definition oval:scap-security-guide.testing:def:137: true Evaluation done. [root@rhel6 checks]# ./testcheck.py audit_rules_dac_modification_fchownat.xml Evaluating with OVAL tempfile : /tmp/audit_rules_dac_modification_fchownata3WKRL.xml Writing results to : /tmp/audit_rules_dac_modification_fchownata3WKRL.xml-results Definition oval:scap-security-guide.testing:def:170: false Definition oval:scap-security-guide.testing:def:137: true Evaluation done. [root@rhel6 checks]# ./testcheck.py audit_rules_dac_modification_lchown.xml Evaluating with OVAL tempfile : /tmp/audit_rules_dac_modification_lchownmX0BTK.xml Writing results to : /tmp/audit_rules_dac_modification_lchownmX0BTK.xml-results Definition oval:scap-security-guide.testing:def:175: false Definition oval:scap-security-guide.testing:def:137: true Evaluation done.
Please send relevant lines from audit.rules
206-211 No telnet installed or turned on
These are both automated checks. Unless the package name is wrong, I don't know why they'd give false positives.
This is broke. I forgot who originally reported, but we still need to update the telnet checks to use the xinet templates.
240 /etc/ssh/sshd_config Banner
The OVAL check was definitely working on my system when I last tested it.
I'm able to reproduce...
[root@rhel6 checks]# cat /etc/issue You are accessing a U.S. Government (USG) Information System (IS) that is provided for USG-authorized use only. By using this IS (which includes any device attached to this IS), you consent to the following conditions: -The USG routinely intercepts and monitors communications on this IS for purposes including, but not limited to, penetration testing, COMSEC monitoring, network operations and defense, personnel misconduct (PM), law enforcement (LE), and counterintelligence (CI) investigations. -At any time, the USG may inspect and seize data stored on this IS. -Communications using, or data stored on, this IS are not private, are subject to routine monitoring, interception, and search, and may be disclosed or used for any USG-authorized purpose. -This IS includes security measures (e.g., authentication and access controls) to protect USG interests -- not for your personal benefit or privacy. -Notwithstanding the above, using this IS does not constitute consent to PM, LE or CI investigative searching or monitoring of the content of privileged communications, or work product, related to personal representation or services by attorneys, psychotherapists, or clergy, and their assistants. Such communications and work product are private and confidential. See User Agreement for details.
[root@rhel6 checks]# ./testcheck.py sshd_banner_set.xml Evaluating with OVAL tempfile : /tmp/sshd_banner_setXKCJxI.xml Writing results to : /tmp/sshd_banner_setXKCJxI.xml-results Definition oval:scap-security-guide.testing:def:193: false Definition oval:scap-security-guide.testing:def:191: false Definition oval:scap-security-guide.testing:def:190: false Evaluation done.
Maura, do you want to take a stab at this (noticed your signoff on the OVAL)?
FWIW, if I used the USGCB banner everything worked OK.
271 If there are no removable partitions this is not a finding.
Working on testing this one now...
Skipping in my testing then
278 If the file permissions are more restrictive then it is not a finding.
This pairs with rpm_verify_permissions, which has the following criterion checks:
<criteria operator="AND"> <criterion test_ref="test_verify_all_rpms_user_ownership"comment="user ownership of all files matches local rpm database" /> <criterion test_ref="test_verify_all_rpms_group_ownership" comment="group ownership of all files matches local rpm database" /> <criterion test_ref="test_verify_all_rpms_mode" comment="mode of all files matches local rpm database" /> </criteria>
Can you send what files are being reported? It should only hit on ownership mismatches.
324 No X running
Agreed, the GNOME checks need to be rewritten to have extended definitions to exclude machines that don't have X installed.
Which package(s) should we check for? xorg-x11-server-Xorg? gnome-desktop?
326 "
?
Same thing as 324
346 Finding reported on umask 022
This is DEFINITELY a bug. The check section is actually pointing to a different check. The actual check for this rule was never written.
The XCCDF (set_daemon_umask) points to:
<oval id="umask_for_daemons" value="var_umask_for_daemons"/>
so, to test: [shawn@rhel6 checks]$ grep umask /etc/init.d/functions # Make sure umask is sane umask 022 [shawn@rhel6 checks]$ var_umask_for_daemons=022 ; export var_umask_for_daemons [shawn@rhel6 checks]$ ./testcheck.py umask_for_daemons.xml external_variable with id : var_umask_for_daemons Evaluating with OVAL tempfile : /tmp/umask_for_daemonsvX5U0G.xml Writing results to : /tmp/umask_for_daemonsvX5U0G.xml-results Definition oval:scap-security-guide.testing:def:212: false Evaluation done.
but then in the OVAL code, it's looking at the wrong place: <ind:textfilecontent54_object id="object_umask_for_daemons" version="1"> ind:path/etc/sysconfig</ind:path> ind:filenameinit</ind:filename> <ind:pattern operation="pattern match">umask[\s]+(.*)</ind:pattern> <ind:instance datatype="int">1</ind:instance> </ind:textfilecontent54_object>
verified no other XCCDF rule was using this OVAL: [shawn@rhel6 input]$ grep -rin umask_for_daemons system/* system/permissions/execution.xml:18:<Value id="var_umask_for_daemons" type="string" operator="equals" interactive="0"> system/permissions/execution.xml:47:<oval id="umask_for_daemons" value="var_umask_for_daemons"/>
.... wrote a patch to fix the pattern match expression, and file path things seem OK now: [shawn@rhel6 checks]$ var_umask_for_daemons=022 ; export var_umask_for_daemons [shawn@rhel6 checks]$ ./testcheck.py umask_for_daemons.xml external_variable with id : var_umask_for_daemons Evaluating with OVAL tempfile : /tmp/umask_for_daemons394CCR.xml Writing results to : /tmp/umask_for_daemons394CCR.xml-results Definition oval:scap-security-guide.testing:def:212: true Evaluation done.
348 No vsftp installed, thus no file.
No OVAL check exists in SSG.
Created https://fedorahosted.org/scap-security-guide/ticket/411 to track
506 "hushlogin"
This one isn't in the SSG at all.
507 PrintLastLog
This one isn't in the SSG at all.
Not sure how/why DISA FSO slid these in. Leland?
-- Shawn Wells Director, Innovation Programs shawn@redhat.com | 443.534.0130 @shawndwells
scap-security-guide mailing list scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
On 9/2/13 10:51 PM, Jeffrey Blank wrote:
Yes -- a few items seem to be surprise additions via FSO, but overall the working experience has been a positive one and we look forward to working together in the future per the Vendor STIG process.
Just in case I came across upset/disgruntled, I *very* much agree with this statement!
We'll attempt to reach consensus on those items before long; we need an itemized list of these for evaluation.
IIRC, wasn't Dave working on such a list?
240 /etc/ssh/sshd_config Banner The OVAL check was definitely working on my system when I last tested it. I'm able to reproduce... [root@rhel6 checks]# cat /etc/issue You are accessing a U.S. Government (USG) Information System (IS) that is provided for USG-authorized use only. By using this IS (which includes any device attached to this IS), you consent to the following conditions: -The USG routinely intercepts and monitors communications on this IS for purposes including, but not limited to, penetration testing, COMSEC monitoring, network operations and defense, personnel misconduct (PM), law enforcement (LE), and counterintelligence (CI) investigations. -At any time, the USG may inspect and seize data stored on this IS. -Communications using, or data stored on, this IS are not private, are subject to routine monitoring, interception, and search, and may be disclosed or used for any USG-authorized purpose. -This IS includes security measures (e.g., authentication and access controls) to protect USG interests -- not for your personal benefit or privacy. -Notwithstanding the above, using this IS does not constitute consent to PM, LE or CI investigative searching or monitoring of the content of privileged communications, or work product, related to personal representation or services by attorneys, psychotherapists, or clergy, and their assistants. Such communications and work product are private and confidential. See User Agreement for details. [root@rhel6 checks]# ./testcheck.py sshd_banner_set.xml Evaluating with OVAL tempfile : /tmp/sshd_banner_setXKCJxI.xml Writing results to : /tmp/sshd_banner_setXKCJxI.xml-results Definition oval:scap-security-guide.testing:def:193: false Definition oval:scap-security-guide.testing:def:191: false Definition oval:scap-security-guide.testing:def:190: false Evaluation done. Maura, do you want to take a stab at this (noticed your signoff on the OVAL)? FWIW, if I used the USGCB banner everything worked OK.
The ONLY thing the check is doing is checking that the line 'Banner /etc/issue' exists in /etc/ssh/sshd_config or that sshd is disabled. It doesn't care about the content of /etc/issue at all. I have no idea why it's failing for both of you guys. Full check is below my signature for comparison.
- Maura Dailey
<def-group> <definition class="compliance" id="sshd_banner_set" version="1"> <metadata> <title>Enable a Warning Banner</title> <affected family="unix"> <platform>Red Hat Enterprise Linux 6</platform> </affected> <description>SSH warning banner should be enabled (and dependencies are met)</description> <reference source="MED" ref_id="20130813" ref_url="test_attestation" /> </metadata> <criteria comment="SSH is not being used or conditions are met" operator="OR"> <extend_definition comment="sshd service is disabled" definition_ref="service_sshd_disabled" /> <criterion comment="Check Banner in /etc/ssh/sshd_config" test_ref="test_sshd_banner_set" /> </criteria> </definition> <ind:textfilecontent54_test check="all" check_existence="all_exist" comment="Tests the value of the Banner[\s]+/etc/issue setting in the /etc/ssh/sshd_config file" id="test_sshd_banner_set" version="1"> <ind:object object_ref="obj_sshd_banner_set" /> </ind:textfilecontent54_test> <ind:textfilecontent54_object id="obj_sshd_banner_set" version="1"> ind:path/etc/ssh</ind:path> ind:filenamesshd_config</ind:filename> <ind:pattern operation="pattern match">^[\s]*(?i)Banner(?-i)[\s]+/etc/issue[\s]*$</ind:pattern> <ind:instance datatype="int">1</ind:instance> </ind:textfilecontent54_object> </def-group>
Modifier spans like (?i) and (?-i) aren't supported in OVAL, though they will probably work in some interpreters depending on the regex implementation.
Shane Shaffer G2, Inc. shane.shaffer@g2-inc.com
On Tue, Sep 3, 2013 at 11:49 AM, Maura Dailey maura@eclipse.ncsc.milwrote:
240 /etc/ssh/sshd_config BannerThe OVAL check was definitely working on my system when I last tested it. I'm able to reproduce...
[root@rhel6 checks]# cat /etc/issue You are accessing a U.S. Government (USG) Information System (IS) that is provided for USG-authorized use only. By using this IS (which includes any device attached to this IS), you consent to the following conditions: -The USG routinely intercepts and monitors communications on this IS for purposes including, but not limited to, penetration testing, COMSEC monitoring, network operations and defense, personnel misconduct (PM), law enforcement (LE), and counterintelligence (CI) investigations. -At any time, the USG may inspect and seize data stored on this IS. -Communications using, or data stored on, this IS are not private, are subject to routine monitoring, interception, and search, and may be disclosed or used for any USG-authorized purpose. -This IS includes security measures (e.g., authentication and access controls) to protect USG interests -- not for your personal benefit or privacy. -Notwithstanding the above, using this IS does not constitute consent to PM, LE or CI investigative searching or monitoring of the content of privileged communications, or work product, related to personal representation or services by attorneys, psychotherapists, or clergy, and their assistants. Such communications and work product are private and confidential. See User Agreement for details.
[root@rhel6 checks]# ./testcheck.py sshd_banner_set.xml Evaluating with OVAL tempfile : /tmp/sshd_banner_setXKCJxI.xml Writing results to : /tmp/sshd_banner_setXKCJxI.xml-results Definition oval:scap-security-guide.testing:def:193: false Definition oval:scap-security-guide.testing:def:191: false Definition oval:scap-security-guide.testing:def:190: false Evaluation done.
Maura, do you want to take a stab at this (noticed your signoff on the OVAL)?
FWIW, if I used the USGCB banner everything worked OK.
The ONLY thing the check is doing is checking that the line 'Banner /etc/issue' exists in /etc/ssh/sshd_config or that sshd is disabled. It doesn't care about the content of /etc/issue at all. I have no idea why it's failing for both of you guys. Full check is below my signature for comparison.
- Maura Dailey
<def-group> <definition class="compliance" id="sshd_banner_set" version="1"> <metadata> <title>Enable a Warning Banner</title> <affected family="unix"> <platform>Red Hat Enterprise Linux 6</platform> </affected> <description>SSH warning banner should be enabled (and dependencies are met)</description> <reference source="MED" ref_id="20130813" ref_url="test_attestation" /> </metadata> <criteria comment="SSH is not being used or conditions are met" operator="OR"> <extend_definition comment="sshd service is disabled" definition_ref="service_sshd_disabled" /> <criterion comment="Check Banner in /etc/ssh/sshd_config" test_ref="test_sshd_banner_set" /> </criteria> </definition> <ind:textfilecontent54_test check="all" check_existence="all_exist" comment="Tests the value of the Banner[\s]+/etc/issue setting in the /etc/ssh/sshd_config file" id="test_sshd_banner_set" version="1"> <ind:object object_ref="obj_sshd_banner_set" /> </ind:textfilecontent54_test> <ind:textfilecontent54_object id="obj_sshd_banner_set" version="1"> <ind:path>/etc/ssh</ind:path> <ind:filename>sshd_config</ind:filename> <ind:pattern operation="pattern match">^[\s]*(?i)Banner(?-i)[\s]+/etc/issue[\s]*$</ind:pattern>
<ind:instance datatype="int">1</ind:instance></ind:textfilecontent54_object>
</def-group>
scap-security-guide mailing list scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
Huh, OK. I don't think that's what's going wrong here, since Shawn is talking about the content of /etc/issue (and since everyone is using the same interpreter), but I can go ahead and remove them from the small handful of checks that use it.
- Maura Dailey
On 09/03/2013 12:14 PM, Shane Shaffer wrote:
Modifier spans like (?i) and (?-i) aren't supported in OVAL, though they will probably work in some interpreters depending on the regex implementation. Shane Shaffer G2, Inc. shane.shaffer@g2-inc.com mailto:shane.shaffer@g2-inc.com
On Tue, Sep 3, 2013 at 11:49 AM, Maura Dailey <maura@eclipse.ncsc.mil mailto:maura@eclipse.ncsc.mil> wrote:
240 /etc/ssh/sshd_config Banner The OVAL check was definitely working on my system when I last tested it. I'm able to reproduce... [root@rhel6 checks]# cat /etc/issue You are accessing a U.S. Government (USG) Information System (IS) that is provided for USG-authorized use only. By using this IS (which includes any device attached to this IS), you consent to the following conditions: -The USG routinely intercepts and monitors communications on this IS for purposes including, but not limited to, penetration testing, COMSEC monitoring, network operations and defense, personnel misconduct (PM), law enforcement (LE), and counterintelligence (CI) investigations. -At any time, the USG may inspect and seize data stored on this IS. -Communications using, or data stored on, this IS are not private, are subject to routine monitoring, interception, and search, and may be disclosed or used for any USG-authorized purpose. -This IS includes security measures (e.g., authentication and access controls) to protect USG interests -- not for your personal benefit or privacy. -Notwithstanding the above, using this IS does not constitute consent to PM, LE or CI investigative searching or monitoring of the content of privileged communications, or work product, related to personal representation or services by attorneys, psychotherapists, or clergy, and their assistants. Such communications and work product are private and confidential. See User Agreement for details. [root@rhel6 checks]# ./testcheck.py sshd_banner_set.xml Evaluating with OVAL tempfile : /tmp/sshd_banner_setXKCJxI.xml Writing results to : /tmp/sshd_banner_setXKCJxI.xml-results Definition oval:scap-security-guide.testing:def:193: false Definition oval:scap-security-guide.testing:def:191: false Definition oval:scap-security-guide.testing:def:190: false Evaluation done. Maura, do you want to take a stab at this (noticed your signoff on the OVAL)? FWIW, if I used the USGCB banner everything worked OK.The ONLY thing the check is doing is checking that the line 'Banner /etc/issue' exists in /etc/ssh/sshd_config or that sshd is disabled. It doesn't care about the content of /etc/issue at all. I have no idea why it's failing for both of you guys. Full check is below my signature for comparison. - Maura Dailey <def-group> <definition class="compliance" id="sshd_banner_set" version="1"> <metadata> <title>Enable a Warning Banner</title> <affected family="unix"> <platform>Red Hat Enterprise Linux 6</platform> </affected> <description>SSH warning banner should be enabled (and dependencies are met)</description> <reference source="MED" ref_id="20130813" ref_url="test_attestation" /> </metadata> <criteria comment="SSH is not being used or conditions are met" operator="OR"> <extend_definition comment="sshd service is disabled" definition_ref="service_sshd_disabled" /> <criterion comment="Check Banner in /etc/ssh/sshd_config" test_ref="test_sshd_banner_set" /> </criteria> </definition> <ind:textfilecontent54_test check="all" check_existence="all_exist" comment="Tests the value of the Banner[\s]+/etc/issue setting in the /etc/ssh/sshd_config file" id="test_sshd_banner_set" version="1"> <ind:object object_ref="obj_sshd_banner_set" /> </ind:textfilecontent54_test> <ind:textfilecontent54_object id="obj_sshd_banner_set" version="1"> <ind:path>/etc/ssh</ind:path> <ind:filename>sshd_config</ind:filename> <ind:pattern operation="pattern match">^[\s]*(?i)Banner(?-i)[\s]+/etc/issue[\s]*$</ind:pattern> <ind:instance datatype="int">1</ind:instance> </ind:textfilecontent54_object> </def-group> _______________________________________________ scap-security-guide mailing list scap-security-guide@lists.fedorahosted.org <mailto: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
Maura, I just pulled the latest git stuff down and made it all, zipped up all the 'ssg-' files from the output directory and dropped that on the SCC3.1 GA scanner. A stock box had 6 passes and 5 failures out of total of 388 items. After locking it down with SB I went to 5 passes and 6 failures (yep - wrong way) out of 388. Operator error on making the packages ?
Couple of interesting questions on the results (after scan):
Set default bash umask (ditto for csh and default umask) Examing the indicated files shows there are two places where the umask could be set, one for 002 and one for 022, with the UID of the caller determining which is used. The scanner is catching the first instance.
Configure Auditd for space_left and admin_space_left: In both cases I inspected the /etc/audit/auditd.conf file and verify that the required line is present according to the prose. I do notice that the list of appropriate actions appears to be a single 'word' set to be:
ignoresyslogemailexecsuspendsinglehalt
Not sure what is going on under the hood to know if these are being glommed together for the prose but kept separate for the OVAL checks or not.
I need to try and rerun with the SCC rc6 beta, but may not have time today...
-Rob
________________________________ From: scap-security-guide-bounces@lists.fedorahosted.org [scap-security-guide-bounces@lists.fedorahosted.org] on behalf of Maura Dailey [maura@eclipse.ncsc.mil] Sent: Wednesday, August 28, 2013 1:05 PM To: scap-security-guide@lists.fedorahosted.org Subject: Re: Various False Positives?
On 08/28/2013 12:04 PM, leam hall wrote: Hey all,
Just ran oscap with the xml files available on the website (Benchmark version 0.9). Here are the issues that seem to be false positives. Prefix everything with "RHEL-06-000". These are all marked as fail but the server meets the STIG. Stupid question, but what are you running against exactly? The RPM or the latest git checkout? I want to make sure that if I run this, I'm seeing the same results, and I've made a lot of changes to OVAL checks in the git repository in the past few weeks. I'm going to run through your list, comparing it against the OVAL checks. 9 rhnsd can be on if configured to Satellite server or similar Fix text definitely implies this. It's not the only service that implies it's allowed in certain environments, but then proceeds to only accept a value of disabled. 57 ucredit 58 ocredit 59 lcredit For the previous 3, I'd like to see the pam_cracklib.so line so I can troubleshoot. 73 /etc/issue Going back to my many many OVAL check updates, I'd like to see your exact /etc/issue so I can debug what went wrong. If it's an exact copy of the text from the STIG, I'll work off that. 98 No ipv6 installed Do you mean it's disabled on your system, but the OVAL checks are saying it isn't? 99 " ? 165 adjtimex 167 settimeofday 169 stime // Also, the STIG is wrong. There is no x86_64 stime syscall The STIG actually says that stime is not necessary, which is kind of a strange wording, but the suggested line in the fix text prose is correct, at least. So far as OVAL checks go, I haven't gotten to testing audit checks yet. Maybe this is broken. I'll check it out once I've deciphered the OVAL check. 171 clock_settime 184-196, 200 chmod, chown, etc... Haven't tested audit checks yet... 206-211 No telnet installed or turned on These are both automated checks. Unless the package name is wrong, I don't know why they'd give false positives. 240 /etc/ssh/sshd_config Banner The OVAL check was definitely working on my system when I last tested it. 271 If there are no removable partitions this is not a finding. Working on testing this one now... 278 If the file permissions are more restrictive then it is not a finding. 324 No X running Agreed, the GNOME checks need to be rewritten to have extended definitions to exclude machines that don't have X installed. 326 " ? 346 Finding reported on umask 022 This is DEFINITELY a bug. The check section is actually pointing to a different check. The actual check for this rule was never written. 348 No vsftp installed, thus no file. No OVAL check exists in SSG. 506 "hushlogin" This one isn't in the SSG at all. 507 PrintLastLog This one isn't in the SSG at all.
- Maura Dailey
Am I confused in thinking a system in run level 3 should net need to worry about X/Gnome findings?
Leam
-- Mind on a Missionhttp://leamhall.blogspot.com/
_______________________________________________ scap-security-guide mailing list scap-security-guide@lists.fedorahosted.orgmailto:scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
For extra sauce, the 'space_left_action' check is the one that went from PASS to FAIL, and the current value went from 'SYSLOG' to 'email'.
________________________________ From: Robert Sanders Sent: Wednesday, August 28, 2013 4:52 PM To: scap-security-guide@lists.fedorahosted.org Subject: RE: Various False Positives?
Maura, I just pulled the latest git stuff down and made it all, zipped up all the 'ssg-' files from the output directory and dropped that on the SCC3.1 GA scanner. A stock box had 6 passes and 5 failures out of total of 388 items. After locking it down with SB I went to 5 passes and 6 failures (yep - wrong way) out of 388. Operator error on making the packages ?
Couple of interesting questions on the results (after scan):
Set default bash umask (ditto for csh and default umask) Examing the indicated files shows there are two places where the umask could be set, one for 002 and one for 022, with the UID of the caller determining which is used. The scanner is catching the first instance.
Configure Auditd for space_left and admin_space_left: In both cases I inspected the /etc/audit/auditd.conf file and verify that the required line is present according to the prose. I do notice that the list of appropriate actions appears to be a single 'word' set to be:
ignoresyslogemailexecsuspendsinglehalt
Not sure what is going on under the hood to know if these are being glommed together for the prose but kept separate for the OVAL checks or not.
I need to try and rerun with the SCC rc6 beta, but may not have time today...
-Rob
________________________________ From: scap-security-guide-bounces@lists.fedorahosted.org [scap-security-guide-bounces@lists.fedorahosted.org] on behalf of Maura Dailey [maura@eclipse.ncsc.mil] Sent: Wednesday, August 28, 2013 1:05 PM To: scap-security-guide@lists.fedorahosted.org Subject: Re: Various False Positives?
On 08/28/2013 12:04 PM, leam hall wrote: Hey all,
Just ran oscap with the xml files available on the website (Benchmark version 0.9). Here are the issues that seem to be false positives. Prefix everything with "RHEL-06-000". These are all marked as fail but the server meets the STIG. Stupid question, but what are you running against exactly? The RPM or the latest git checkout? I want to make sure that if I run this, I'm seeing the same results, and I've made a lot of changes to OVAL checks in the git repository in the past few weeks. I'm going to run through your list, comparing it against the OVAL checks. 9 rhnsd can be on if configured to Satellite server or similar Fix text definitely implies this. It's not the only service that implies it's allowed in certain environments, but then proceeds to only accept a value of disabled. 57 ucredit 58 ocredit 59 lcredit For the previous 3, I'd like to see the pam_cracklib.so line so I can troubleshoot. 73 /etc/issue Going back to my many many OVAL check updates, I'd like to see your exact /etc/issue so I can debug what went wrong. If it's an exact copy of the text from the STIG, I'll work off that. 98 No ipv6 installed Do you mean it's disabled on your system, but the OVAL checks are saying it isn't? 99 " ? 165 adjtimex 167 settimeofday 169 stime // Also, the STIG is wrong. There is no x86_64 stime syscall The STIG actually says that stime is not necessary, which is kind of a strange wording, but the suggested line in the fix text prose is correct, at least. So far as OVAL checks go, I haven't gotten to testing audit checks yet. Maybe this is broken. I'll check it out once I've deciphered the OVAL check. 171 clock_settime 184-196, 200 chmod, chown, etc... Haven't tested audit checks yet... 206-211 No telnet installed or turned on These are both automated checks. Unless the package name is wrong, I don't know why they'd give false positives. 240 /etc/ssh/sshd_config Banner The OVAL check was definitely working on my system when I last tested it. 271 If there are no removable partitions this is not a finding. Working on testing this one now... 278 If the file permissions are more restrictive then it is not a finding. 324 No X running Agreed, the GNOME checks need to be rewritten to have extended definitions to exclude machines that don't have X installed. 326 " ? 346 Finding reported on umask 022 This is DEFINITELY a bug. The check section is actually pointing to a different check. The actual check for this rule was never written. 348 No vsftp installed, thus no file. No OVAL check exists in SSG. 506 "hushlogin" This one isn't in the SSG at all. 507 PrintLastLog This one isn't in the SSG at all.
- Maura Dailey
Am I confused in thinking a system in run level 3 should net need to worry about X/Gnome findings?
Leam
-- Mind on a Missionhttp://leamhall.blogspot.com/
_______________________________________________ scap-security-guide mailing list scap-security-guide@lists.fedorahosted.orgmailto:scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
The variable for space_left_action is supposed to be set in the XCCDF Profile. The variable name is var_auditd_space_left_action and the stig profile just doesn't set it, so it defaults to email. I read the STIG, and the STIG agrees, it should be email (RHEL-06-000005).
- Maura Dailey
On 08/28/2013 05:05 PM, Robert Sanders wrote:
For extra sauce, the 'space_left_action' check is the one that went from PASS to FAIL, and the current value went from 'SYSLOG' to 'email'.
*From:* Robert Sanders *Sent:* Wednesday, August 28, 2013 4:52 PM *To:* scap-security-guide@lists.fedorahosted.org *Subject:* RE: Various False Positives?
Maura, I just pulled the latest git stuff down and made it all, zipped up all the 'ssg-' files from the output directory and dropped that on the SCC3.1 GA scanner. A stock box had 6 passes and 5 failures out of total of 388 items. After locking it down with SB I went to 5 passes and 6 failures (yep - wrong way) out of 388. Operator error on making the packages ?
Couple of interesting questions on the results (after scan):
Set default bash umask (ditto for csh and default umask) Examing the indicated files shows there are two places where the umask could be set, one for 002 and one for 022, with the UID of the caller determining which is used. The scanner is catching the first instance.
Configure Auditd for space_left and admin_space_left: In both cases I inspected the /etc/audit/auditd.conf file and verify that the required line is present according to the prose. I do notice that the list of appropriate actions appears to be a single 'word' set to be:
ignoresyslogemailexecsuspendsinglehalt
Not sure what is going on under the hood to know if these are being glommed together for the prose but kept separate for the OVAL checks or not.
I need to try and rerun with the SCC rc6 beta, but may not have time today...
-Rob
*From:* scap-security-guide-bounces@lists.fedorahosted.org [scap-security-guide-bounces@lists.fedorahosted.org] on behalf of Maura Dailey [maura@eclipse.ncsc.mil] *Sent:* Wednesday, August 28, 2013 1:05 PM *To:* scap-security-guide@lists.fedorahosted.org *Subject:* Re: Various False Positives?
On 08/28/2013 12:04 PM, leam hall wrote:
Hey all,
Just ran oscap with the xml files available on the website (Benchmark version 0.9). Here are the issues that seem to be false positives. Prefix everything with "RHEL-06-000". These are all marked as fail but the server meets the STIG.
Stupid question, but what are you running against exactly? The RPM or the latest git checkout? I want to make sure that if I run this, I'm seeing the same results, and I've made a lot of changes to OVAL checks in the git repository in the past few weeks. I'm going to run through your list, comparing it against the OVAL checks.
9 rhnsd can be on if configured to Satellite server or similar
Fix text definitely implies this. It's not the only service that implies it's allowed in certain environments, but then proceeds to only accept a value of disabled.
57 ucredit 58 ocredit 59 lcredit
For the previous 3, I'd like to see the pam_cracklib.so line so I can troubleshoot.
73 /etc/issue
Going back to my many many OVAL check updates, I'd like to see your exact /etc/issue so I can debug what went wrong. If it's an exact copy of the text from the STIG, I'll work off that.
98 No ipv6 installed
Do you mean it's disabled on your system, but the OVAL checks are saying it isn't?
99 "
?
165 adjtimex 167 settimeofday 169 stime // Also, the STIG is wrong. There is no x86_64 stime syscall
The STIG actually says that stime is not necessary, which is kind of a strange wording, but the suggested line in the fix text prose is correct, at least. So far as OVAL checks go, I haven't gotten to testing audit checks yet. Maybe this is broken. I'll check it out once I've deciphered the OVAL check.
171 clock_settime 184-196, 200 chmod, chown, etc...
Haven't tested audit checks yet...
206-211 No telnet installed or turned on
These are both automated checks. Unless the package name is wrong, I don't know why they'd give false positives.
240 /etc/ssh/sshd_config Banner
The OVAL check was definitely working on my system when I last tested it.
271 If there are no removable partitions this is not a finding.
Working on testing this one now...
278 If the file permissions are more restrictive then it is not a finding. 324 No X running
Agreed, the GNOME checks need to be rewritten to have extended definitions to exclude machines that don't have X installed.
326 "
?
346 Finding reported on umask 022
This is DEFINITELY a bug. The check section is actually pointing to a different check. The actual check for this rule was never written.
348 No vsftp installed, thus no file.
No OVAL check exists in SSG.
506 "hushlogin"
This one isn't in the SSG at all.
507 PrintLastLog
This one isn't in the SSG at all.
- Maura Dailey
Am I confused in thinking a system in run level 3 should net need to worry about X/Gnome findings?
Leam
-- Mind on a Mission http://leamhall.blogspot.com/
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
I think the RPM is just really out of date.
Hmmm, I'll look into the umask thing, but I was under the assumption that if one failed, the whole file should fail, so that's probably the reasoning behind never looking for a second umask value. Note that the prose guide section for each umask setting makes no attempt to distinguish between multiple places to change umask settings.
I checked and noticed that admin_space_left and admin_space_left_action don't show up at all in the STIG. I also noticed that the title for the prose section describing admin_space_left_action is wrong in the SSG. I wonder if the variable name is also wrong and the check is looking for the wrong thing? I will check this tomorrow.
I don't know where "ignoresyslogemailexecsuspendsinglehalt" is coming from. Grepping through the entire SSG reveals nothing. When I get in tomorrow, I'll try to track down what's happening (maybe regex gone wrong?).
If you open up the XCCDF in a text editor, you'll notice that Rules will sometimes contain <check> tags. These check tags have nearly unreadable ids, BUT you will find them in ssg-rhel6-oval.xml with the same names and can get a human readable ref_id that will point you to the correct file in RHEL6/input/checks in the git repo.
- Maura Dailey
On 08/28/2013 04:52 PM, Robert Sanders wrote:
Maura, I just pulled the latest git stuff down and made it all, zipped up all the 'ssg-' files from the output directory and dropped that on the SCC3.1 GA scanner. A stock box had 6 passes and 5 failures out of total of 388 items. After locking it down with SB I went to 5 passes and 6 failures (yep - wrong way) out of 388. Operator error on making the packages ?
Couple of interesting questions on the results (after scan):
Set default bash umask (ditto for csh and default umask) Examing the indicated files shows there are two places where the umask could be set, one for 002 and one for 022, with the UID of the caller determining which is used. The scanner is catching the first instance.
Configure Auditd for space_left and admin_space_left: In both cases I inspected the /etc/audit/auditd.conf file and verify that the required line is present according to the prose. I do notice that the list of appropriate actions appears to be a single 'word' set to be:
ignoresyslogemailexecsuspendsinglehalt
Not sure what is going on under the hood to know if these are being glommed together for the prose but kept separate for the OVAL checks or not.
I need to try and rerun with the SCC rc6 beta, but may not have time today...
-Rob
*From:* scap-security-guide-bounces@lists.fedorahosted.org [scap-security-guide-bounces@lists.fedorahosted.org] on behalf of Maura Dailey [maura@eclipse.ncsc.mil] *Sent:* Wednesday, August 28, 2013 1:05 PM *To:* scap-security-guide@lists.fedorahosted.org *Subject:* Re: Various False Positives?
On 08/28/2013 12:04 PM, leam hall wrote:
Hey all,
Just ran oscap with the xml files available on the website (Benchmark version 0.9). Here are the issues that seem to be false positives. Prefix everything with "RHEL-06-000". These are all marked as fail but the server meets the STIG.
Stupid question, but what are you running against exactly? The RPM or the latest git checkout? I want to make sure that if I run this, I'm seeing the same results, and I've made a lot of changes to OVAL checks in the git repository in the past few weeks. I'm going to run through your list, comparing it against the OVAL checks.
9 rhnsd can be on if configured to Satellite server or similar
Fix text definitely implies this. It's not the only service that implies it's allowed in certain environments, but then proceeds to only accept a value of disabled.
57 ucredit 58 ocredit 59 lcredit
For the previous 3, I'd like to see the pam_cracklib.so line so I can troubleshoot.
73 /etc/issue
Going back to my many many OVAL check updates, I'd like to see your exact /etc/issue so I can debug what went wrong. If it's an exact copy of the text from the STIG, I'll work off that.
98 No ipv6 installed
Do you mean it's disabled on your system, but the OVAL checks are saying it isn't?
99 "
?
165 adjtimex 167 settimeofday 169 stime // Also, the STIG is wrong. There is no x86_64 stime syscall
The STIG actually says that stime is not necessary, which is kind of a strange wording, but the suggested line in the fix text prose is correct, at least. So far as OVAL checks go, I haven't gotten to testing audit checks yet. Maybe this is broken. I'll check it out once I've deciphered the OVAL check.
171 clock_settime 184-196, 200 chmod, chown, etc...
Haven't tested audit checks yet...
206-211 No telnet installed or turned on
These are both automated checks. Unless the package name is wrong, I don't know why they'd give false positives.
240 /etc/ssh/sshd_config Banner
The OVAL check was definitely working on my system when I last tested it.
271 If there are no removable partitions this is not a finding.
Working on testing this one now...
278 If the file permissions are more restrictive then it is not a finding. 324 No X running
Agreed, the GNOME checks need to be rewritten to have extended definitions to exclude machines that don't have X installed.
326 "
?
346 Finding reported on umask 022
This is DEFINITELY a bug. The check section is actually pointing to a different check. The actual check for this rule was never written.
348 No vsftp installed, thus no file.
No OVAL check exists in SSG.
506 "hushlogin"
This one isn't in the SSG at all.
507 PrintLastLog
This one isn't in the SSG at all.
- Maura Dailey
Am I confused in thinking a system in run level 3 should net need to worry about X/Gnome findings?
Leam
-- Mind on a Mission http://leamhall.blogspot.com/
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 8/28/13 6:15 PM, Maura Dailey wrote:
I think the RPM is just really out of date.
It is! :( There's been 63 patches since the July release. I'll cut a new RPM once the patches I sent out today are reviewed (Dave Smith said he might be able to take a look).
$ git log --oneline --after={2013-07-05} --no-merges 1253b6e [bugfix] Updated selinux_bootloader_notdisabled per ticket 391 eb4d177 [bugfix] Updated regex+filepath for umask_for_daemons - Wrong filepath - Broke regex - Added signoff b034d93 Updated STIG refine values for ucredit, ocredit, lcredit 297ffb2 OVAL signoff for template_permissions 53faca6 [bugfix] oval/checks/templates/output/.gitignore updated to ignore .sh files ccd8c14 OVAL testing template_package_removed 92a6939 OVAL testing for template_kernel_module_disabled 285b70d template_OVAL_package_installed testing + bash remediations - Testing of OVAL for template_OVAL_package_installed - Adding of ass 6ebc93f Updated NIST profile ID 90f3331 added "checks" as a dependency for tables 4c76e49 Tiny patch to correct typo, it's -S stime, not -S time. 156d71a Prose changes and copy editing 8612b07 added interrogatory phrase to OCIL questions ee53c82 Another batch of tested checks. Includes some checks that had their comments expanded or were renamed from random values. cca02fb Check will return list of all partitions without nodev instead of a complete list of all partitions and the return value of true/fa 3c2ddb9 improved table to indicate when OVAL checks have been tested 92dc471 made CSS adjustments to make <pre> wrap b5c35b6 Existing check was screwed up (title was wrong, comments were wrong, etc.) and was easily replaced by a templated check 2f92bb8 Improbably, the input line for UDP is $UDPServerRun, not $InputUDPServerRun. Also, the check forgot to include the port number, so eeec622 Original check assumed that sha512 would always be the first option 95c8805 Guide refers to :omrelp: as a valid remote logging option, so I've updated the check to accept that format as well 6d40bcb Making SSH checks uniform and hopefully adding case insensitive matches properly 8d2b031 Adding reference tags to show which checks I've tested. Some very slight whitespace corrections were made as well. 04a0fb6 [bugfix] Updated XCCDF rule name of set_sysctl_ipv6_default_accept_redirects in profiles 477cf7d Check needs to be reversed. As is, if you specified 10 as the maximum number of concurrent logins, it would allow 20. 499d1ca Small patch to replace autogenerated test, state, and object ids with human readable ones (now with 80 character line breaks) 0bea4ab moved namespace assignment into shorthand2xccdf.xslt transform 464b876 added comment, added calls to insert Profiles 2a62395 removing calls to now-unnecessary transforms 61da0f5 Adding new OVAL check that will parse /etc/passwd, looking for system accounts with real login shells (not /sbin/nologin, /sbin/hal fc064ce renaming namespace addition file, as part of refactoring 9c366bb removing namespaces from no-namespace fragments, transforms 28630df refactoring of XCCDF shorthand expansion and namespace assignments b22713b Added rule for disabling interface use of IPv6 57464ba Additional option for number of max concurrent logins 19be81c Added rule regarding anonymous NFS connections 0986a65 modified transform to include new profile 65b0a84 added example of a custom profile 92dd7a3 DHCP section referred to the wrong file location for dhcpd.conf c351938 Last item in Avahi file feels like it's supposed to be a Rule, not a Group c929fc5 It IS always,exit NEVER exit,always! 996bf22 what? 0b1ad85 Correct telnet service disabled checks 53ae081 Audit test fix to match rest of checks, also fixed text doc 748b723 Corrected bash services template - Updated Makefile - Removed incorrectly generated service enable scripts 9ce1c3a Removing content of pattern match line, since it seems to break OVAL. Also, updated id names to be real words, not randomly generat 8f89e00 removal of invalid state child element in world-writable files test 6699d5a removal of invalid state child element in /var/log/audit ownership test ff9da0a new versions of unauth suid/sgid OVAL checks 789e0c1 Added line to indicate test output file, to OVAL testing script e24cf91 Created remediation template: create_services_enabled 52a2e0b Removing unreferenced OVAL file_ssh_host_keys_public_permissions.xml fd78bd7 Removing unreferenced file_ssh_host_keys_private_permissions.xml Removing unreferenced file_ssh_host_keys_private_permissions.xml a8b3a2b Updated selinux_all_devicefiles_labeled The check enumeration of 'none exist' was depricated for 'none satisfy' as of OVAL 5.3, re 32652f9 Added OVAL mapping to world_writeable_files Mapped OVAL file_permissions_unauthorized_world_writable to XCCDF world_writeable_file 2a027a4 Corrected naming of set_sysctl_ipv6_default_accept_redirects Updated naming of XCCDF rule "set_sysctl_ipv6_default_accept_redirec e2a0203 Added OVAL + remediation for sysctl_net_ipv6_conf_default_accept_ra Generated from templates a46ca9b Created OVAL + remediation for sysctl_net_ipv6_conf_default_accept_redirects Created using templates 73f5ddc removal of invalid state child element in world-writable files test pushing for jeff blank via https://lists.fedorahosted.org/piper fe7008e removal of invalid state child element in /var/log/audit ownership test pushing for jeff blank per https://lists.fedorahosted.org/p 76d18ba Changes to SSHD Ciphers 7bcca7b Removing '' from audit rule lines to prevent confusion. 3fd0b9f Updated RPM version to 0.1-12
scap-security-guide@lists.fedorahosted.org
-
Hopkins, Robert J CTR BXPP, BXPP -
Jeffrey Blank -
leam hall -
Maura Dailey -
Robert Sanders -
Shane Shaffer -
Shawn Wells