Fwd: CONFIRMATION: Developer Days 2013
by Shawn Wells
Will anyone else be at the MITRE Dev Days conference next week? There's
going to be a session on the SCAP Security Guide project, and
<shameless_plug>Red Hat willl be sponsoring some of the 'social event'
at Gordon Biersch</shameless_plug>.
Would be great to meet catch up with members of the SSG community!
-------- Original Message --------
Subject: CONFIRMATION: Developer Days 2013
Date: Thu, 18 Jul 2013 16:40:43 +0000
From: Hansbury, Matt <mhansbury(a)mitre.org>
To: Hansbury, Matt <mhansbury(a)mitre.org>
You have officially registered as an attendee of MITRE's Developer Days
2013 workshop, held at MITRE's McLean site. This email serves as a
reminder and confirmation for the event, beginning this upcoming Monday
(July 22, 2013) at 10AM EST. The event runs for 3 days, ending on
Wednesday (July 24, 2013), at around 6PM. The official agenda can be
found at the event web site.
To ensure your stay during the event is enjoyable, we have a few
reminders for you:
1.There is no cost or fee to attend the workshop, but you will be on
your own for all meals. Note that the MITRE cafeteria is on the same
floor as the event, so easy access to food and drink will be available.
2.Please join us for our Social Event at Gordon Biersch at the Tyson's
Corner Mall location. The cost for this will not exceed $20 (the exact
cost will vary on the number of attendees that join us, so the exact
figure won't be available until the event, but we can commit to holding
it to $20 or under).
If you know that you will (or will not) be able to attend the Social
Event, and have not already responded, please notify *oval(a)mitre.org
<mailto:oval@mitre.org>*so an accurate head count can be determined.
3.If you are not a US citizen, we remind that you that you will **not**
be able to bring electronic devices into any of the MITRE buildings and
will need to be escorted by a MITRE employee at all times. Please leave
your devices in your hotel room or car.
4.Lastly, if you are **no longer** able to attend the event for any
reason, I would request that you let us know so that folks on our
waiting list can be accommodated.
The event will be held in the MITRE 1 building (also known a 'H'
building) at the MITRE McLean, VA campus (the room number is 1H300).
For more information and directions, please review the following:
http://info.mitre.org/site_admin/locations/mitre1-map.html
Additional workshop details can be found at:
https://register.mitre.org/devdays/
We look forward to sharing with you some detailed technical
conversations that will help drive OVAL and the other related efforts
forward. See you in a few days!
Thanks
The OVAL Team
10 years, 9 months
[PATCH] Fix Ciphers check of sshd config
by Andrew Gilmore
The text in the guide suggests that AES and 3DES ciphers are allowed in CBC
and CTR versions.
"Limit the ciphers to those algorithms which are FIPS-approved. Counter
(CTR) mode is also preferred over cipher-block chaining (CBC) mode. The
following line in /etc/ssh/sshd_config demonstrates use of FIPS-approved
ciphers:
Ciphers
aes128-ctr,aes192-ctr,aes256-ctr,aes128-cbc,3des-cbc,aes192-cbc,aes256-cbc"
However, the test has the old CTR only list.
Patch below.
This fixes one of the annoying false-positives that occur when I run the
SSG against my systems which have been hardened according to the guide.
Andrew Gilmore
Signed-off-by: Andrew Gilmore <agilmore2(a)gmail.com>
---
diff --git a/RHEL6/input/checks/sshd_use_approved_ciphers.xml
b/RHEL6/input/checks/sshd_use_approved_ciphers.xml
index 267fe93..1807d56 100644
--- a/RHEL6/input/checks/sshd_use_approved_ciphers.xml
+++ b/RHEL6/input/checks/sshd_use_approved_ciphers.xml
@@ -21,7 +21,7 @@
<ind:textfilecontent54_object id="obj_20251" version="1">
<ind:path>/etc/ssh</ind:path>
<ind:filename>sshd_config</ind:filename>
- <ind:pattern operation="pattern
match">^\s*Ciphers\s*aes128-ctr,aes192-ctr,aes256-ctr\s*$</ind:pattern>
+ <ind:pattern operation="pattern
match">^\s*Ciphers\s*aes128-ctr,aes192-ctr,aes256-ctr,aes128-cbc,3des-cbc,aes192-cbc,aes256-cbc\s*$</ind:pattern>
<ind:instance datatype="int">1</ind:instance>
</ind:textfilecontent54_object>
</def-group>
10 years, 9 months
Roadmap for next official DISA RHEL6 STIG release?
by Robert Sanders
Is there a tentative date for the next release by DISA of the RHEL6 STIG, both the manual and the benchmark? I'm writing code right now looking at what is on the IASE web site (because that is what is 'official'), but I know there are just a few differences between that and what is in the SSG 'upstream' code base (kernel module /bin/true vice /bin/false for example). Just wondering when the next iteration will become official....
-Rob
10 years, 9 months
How to evaluate server against final DISA STIG?
by Andrew Gilmore
I appreciate all the great work folks have done, and somehow missed
the big announcement that DISA had put a final out there.
Now, I'd like to evaluate against the final STIG, from
http://iase.disa.mil/stigs/os/unix/red_hat.html.
It appears that the profiles listed are fairly different than the SSG
version, but I can get behind that. I can try MAC-3_Public to start.
What I don't see is the CPE dictionary, etc. Where do I get evaluation
content to match the DISA STIG?
Thanks,
Andrew
10 years, 9 months
Questions about rpm verification
by Robert Sanders
Greeting everyone,
Just had some questions related to the rpm verification items in the RHEL6 STIG.
1) How are people handling 3rd party software that isn't installed from a yum repo?
2) On my RHEL6.4 VM I ran an 'rpm -Va' right after I installed the system, and received the following output:
S.5....T. c /etc/maven/maven2-depmap.xml
..5....T. /usr/share/ibus-table/tables/compose.db
..5....T. /usr/share/ibus-table/tables/latex.db
SM5....T. c /etc/sysconfig/rhn/up2date
.M....G.. /var/log/gdm
.M....... /var/run/gdm
missing /var/run/gdm/greeter
..5....T. c /usr/lib/security/classpath.security
..5....T. c /etc/inittab
S.5....T. /usr/share/texmf/web2c/updmap.cfg
....L.... c /etc/pam.d/fingerprint-auth
....L.... c /etc/pam.d/password-auth
....L.... c /etc/pam.d/smartcard-auth
....L.... c /etc/pam.d/system-auth
S.5....T. c /etc/rsyslog.conf
So this shows there are 6 'issues' to be dealt with since we can ignore the config issues (c). Most of these are non-issues so far as I can see, due to files being rebuilt/tweaked during install or known transient files, and could be avoided if the owning rpms labeled the files as configuration files perhaps.
-Rob
10 years, 9 months
[PATCH] Removing OVAL check that would attempt to parse root's PATH and inspect permissions on those directories
by Maura Dailey
This check and rule only seem to appear in the USGCB profile. Jeff has requested that I remove it.
- Maura Dailey
Signed-off-by: Maura Dailey <maura(a)eclipse.ncsc.mil>
---
.../checks/accounts_root_path_dirs_no_write.xml | 60 --------------------
RHEL6/input/system/accounts/session.xml | 1 -
2 files changed, 0 insertions(+), 61 deletions(-)
delete mode 100644 RHEL6/input/checks/accounts_root_path_dirs_no_write.xml
diff --git a/RHEL6/input/checks/accounts_root_path_dirs_no_write.xml b/RHEL6/input/checks/accounts_root_path_dirs_no_write.xml
deleted file mode 100644
index 36a02cf..0000000
--- a/RHEL6/input/checks/accounts_root_path_dirs_no_write.xml
+++ /dev/null
@@ -1,60 +0,0 @@
-<def-group>
- <definition class="compliance"
- id="accounts_root_path_dirs_no_write" version="1">
- <metadata>
- <title>Write permissions are disabled for group and other in
- all directories in Root's Path</title>
- <affected family="unix">
- <platform>Red Hat Enterprise Linux 6</platform>
- </affected>
- <description>Check each directory in root's path and make use
- it does not grant write permission to group and
- other</description>
- </metadata>
- <criteria comment="Check that write permission to group and other in root's path is denied"
- negate="true" operator="OR">
- <criterion comment="Check for write permission to group in root's path"
- test_ref="test_2008551" />
- <criterion comment="Check for write permission to other in root's path"
- test_ref="test_2008552" />
- </criteria>
- </definition>
- <unix:file_test check="all" check_existence="any_exist"
- comment="Check that write permission to group and other in root's path is denied"
- id="test_2008551" version="1">
- <unix:object object_ref="obj_200855" />
- <unix:state state_ref="state_2008551" />
- </unix:file_test>
- <unix:file_state comment="Group has write privilege"
- id="state_2008551" version="1">
- <unix:gwrite datatype="boolean">1</unix:gwrite>
- </unix:file_state>
- <unix:file_object xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
- comment="root's PATH" id="obj_200855"
- version="1">
- <unix:path var_ref="var_200855" />
- <unix:filename xsi:nil="true" />
- </unix:file_object>
- <local_variable comment="Split the PATH on the : delimiter"
- datatype="string" id="var_200855"
- version="1">
- <split delimiter=":">
- <object_component item_field="value"
- object_ref="obj_20085" />
- </split>
- </local_variable>
- <ind:environmentvariable_object id="obj_20085"
- version="1">
- <ind:name>PATH</ind:name>
- </ind:environmentvariable_object>
- <unix:file_test check="all" check_existence="any_exist"
- comment="Check that write permission to group and other in root's path is denied"
- id="test_2008552" version="1">
- <unix:object object_ref="obj_200855" />
- <unix:state state_ref="state_2008552" />
- </unix:file_test>
- <unix:file_state comment="Other has write privilege"
- id="state_2008552" version="1">
- <unix:owrite datatype="boolean">1</unix:owrite>
- </unix:file_state>
-</def-group>
diff --git a/RHEL6/input/system/accounts/session.xml b/RHEL6/input/system/accounts/session.xml
index 7f6d287..69d9e3a 100644
--- a/RHEL6/input/system/accounts/session.xml
+++ b/RHEL6/input/system/accounts/session.xml
@@ -111,7 +111,6 @@ execute code provided by unprivileged users,
and potentially malicious code.
</rationale>
<ident cce="26768-2" />
-<oval id="accounts_root_path_dirs_no_write" />
<ref nist=""/>
</Rule>
</Group>
--
1.7.1
10 years, 9 months
[PATCH] Removing content of pattern match line, since it seems to break OVAL. Also, updated id names to be real words, not randomly generated values.
by Maura Dailey
At Jeff's request, I tested the following changes. It appears that the contents of the pattern check are not required and break
OVAL validation.
- Maura Dailey
Signed-off-by: Maura Dailey <maura(a)eclipse.ncsc.mil>
---
RHEL6/input/checks/banner_etc_issue.xml | 10 +++++-----
1 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/RHEL6/input/checks/banner_etc_issue.xml b/RHEL6/input/checks/banner_etc_issue.xml
index 346bfab..e13bd3a 100644
--- a/RHEL6/input/checks/banner_etc_issue.xml
+++ b/RHEL6/input/checks/banner_etc_issue.xml
@@ -8,15 +8,15 @@
<description>The system login banner text should be set correctly.</description>
</metadata>
<criteria>
- <criterion comment="/etc/issue is set appropriately" test_ref="test_20102" />
+ <criterion comment="/etc/issue is set appropriately" test_ref="test_banner_etc_issue" />
</criteria>
</definition>
- <ind:textfilecontent54_test check="all" check_existence="all_exist" comment="correct banner in /etc/issue" id="test_20102" version="1">
- <ind:object object_ref="obj_20102" />
+ <ind:textfilecontent54_test check="all" check_existence="all_exist" comment="correct banner in /etc/issue" id="test_banner_etc_issue" version="1">
+ <ind:object object_ref="object_banner_etc_issue" />
</ind:textfilecontent54_test>
- <ind:textfilecontent54_object id="obj_20102" version="1">
+ <ind:textfilecontent54_object id="object_banner_etc_issue" version="1">
<ind:filepath>/etc/issue</ind:filepath>
- <ind:pattern var_ref="login_banner_text" operation="pattern match">^.*(.+).*$</ind:pattern>
+ <ind:pattern var_ref="login_banner_text" operation="pattern match" />
<ind:instance datatype="int" operation="greater than or equal">1</ind:instance>
</ind:textfilecontent54_object>
<external_variable comment="warning banner text variable" datatype="string" id="login_banner_text" version="1" />
--
1.7.1
10 years, 9 months
