It's time to branch & tag
by Shawn Wells
As we're now at a point where the project is about to submit "Informal
Draft" content to DISA, it may be a good time to clean up our git
branching/tagging model (err.. create one).
My thoughts:
(1) For every project within SSG, create a unique branch. Currently this
would set us up as:
MASTER
|--- JBossEAP5
|--- RHEL6
(2) Each project is responsible for their own release tags.
MASTER
|--- JBossEAP5
|--- RHEL6
| |--- InformalDraft
Comments?
10 years, 5 months
[PATCH] Do not select the Group but the Rule.
by Šimon Lukašík
---
RHEL6/input/profiles/STIG-server.xml | 2 +-
RHEL6/input/profiles/test.xml | 3 +--
2 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/RHEL6/input/profiles/STIG-server.xml b/RHEL6/input/profiles/STIG-server.xml
index 5f67335..3fa5add 100644
--- a/RHEL6/input/profiles/STIG-server.xml
+++ b/RHEL6/input/profiles/STIG-server.xml
@@ -66,7 +66,7 @@
<refine-value idref="user_umask_value" selector="077"/>
-<select idref="daemon_umask" selected="true" />
+<select idref="set_daemon_umask" selected="true" />
<refine-value idref="var_umask_for_daemons" selector="027"/>
diff --git a/RHEL6/input/profiles/test.xml b/RHEL6/input/profiles/test.xml
index 9f0bd50..7742b31 100644
--- a/RHEL6/input/profiles/test.xml
+++ b/RHEL6/input/profiles/test.xml
@@ -9,7 +9,6 @@
<select idref="package_rsyslog_installed" selected="true"/>
<select idref="service_rsyslog_enabled" selected="true"/>
<select idref="disable_vsftpd" selected="true"/>
-<select idref="set_daemon_umask" selected="true"/>
<select idref="set_selinux_state" selected="true"/>
<select idref="password_require_digits" selected="true"/>
<select idref="tftpd_uses_secure_mode" selected="true"/>
@@ -52,7 +51,7 @@
<refine-value idref="user_umask_value" selector="077"/>
-<select idref="daemon_umask" selected="true" />
+<select idref="set_daemon_umask" selected="true"/>
<refine-value idref="var_umask_for_daemons" selector="027"/>
--
1.7.7.6
10 years, 5 months
Fixed RPM repo as of 1700 EST
by Shawn Wells
A few people reported a problem downloading packages from the EPEL repo,
specifically error 404 messages. They've now been fixed. Please let us
know -- via the public mailing list -- if problems continue.
You may have to do a `yum clean all` if repository metadata is cached on
your system. Here is the exact error that was reported:
# yum install scap-security-guide
........
Downloading Packages:
(1/3): openscap-0.9.2-1.el6.x86_64.rpm | 2.8 MB 00:01
(2/3): openscap-utils-0.9.2-1.el6.x86_64.rpm | 41 kB 00:00
http://repos.fedorapeople.org/repos/scap-security-guide/epel-6/noarch/sca...:
[Errno 14] PYCURL ERROR 22 - "The requested URL returned error: 404"
Trying other mirror.
Error Downloading Packages:
scap-security-guide-0.1-9.noarch: failure:
scap-security-guide-0.1-9.noarch.rpm from epel-scap-security-guide:
[Errno 256] No more mirrors to try.
10 years, 6 months
Definition of 'files/directories'' with regard to permissions
by Robert Sanders
Got a quick question for folks regarding whether a directory should be considered a 'file' when it comes down to setting permissions. I'd asked this question in an email to the FSO and hadn't heard anything. A good poster child for this is GEN001800 ["All skeleton files (typically those in /etc/skel) must have mode 0644 or less permissive" ]. If KDE is installed on this system then /etc/skel will hold a directory '.kde'. If permissions on this directory are set to 0644 or less, and a new user is created, they will not be able to log in graphically using KDE. The routine that created the users directory from the /etc/skel files copied the permissions exactly, just changed file ownership. So the user if prevented from accessing their own $HOME/.kde directory.
Another example would be GEN001280 ["Manual page files must have mode 0644 or less permissive"]. The U_Redhat_5-V1R1_STIG_Manual-xccdf.xml file (August 2012) references this, but I don't see it in the benchmark file.
For GEN001800 the permissions for subdirectories needs to be at least 0744, and for GEN001280 subdirectories need 0755.
If I'm being overly picky that is OK, I just would to know how others are interpreting these line items.
Thanks...
-Rob
10 years, 6 months
Alternate way to to graphical login banner, with logging of acceptence
by Robert Sanders
Greetings all,
As I mentioned in the conference call, we have a slightly different way of doing the login banner that also gets the user's acknowledgement sent to /var/log/secure (or the equivalent). I should note that our tool helps with remediating a box against several different guidelines. Hence we tried to find as 'simple' a way to do this as possible, without large banners looking seriously cramped (IE - cram the full DoD login banner into the default authentication dialog on a small screen). We also tried to support both pure Gnome (GDM) and KDE (kdm). I'll handwave through the details (ping me if you'd like more info).
Basically we add wording to the main login with text along the lines of:
All users will be required to read and accept a 'Consent to Monitor' statement before being allowed to login.
The response will be logged.
This text fits nicely on most of the OS's we support, and is shown on every graphical login attempt on the main authentication display. Currently for GDM on Fedora/RHEL6 we make these changes to /apps/gdm/simple-greeter/*, most of the other Linux boxes we'll change the /etc/X11/gdm/gdm.conf or /etc/gdm/custom.conf file instead. For KDM it all goes to /usr/share/config/kdm/kdmrc.
To display the actual required login banner we tweak the /etc/X11/gdm/PreSession/Default (Solaris), /etc/X11/xdm/Xsession (RH4), or /etc/X11/xinit/Xsession (everyone else) file to call a script that uses zenity or kdialog (use first one found) to display the text of the banner. Since we do support other guidelines that may just require notification, we have our dialog may just have an acknowledgement button or an explicit accept/deny button. The user's response is logged using the first of /usr/sbin/logger, /sbin/logger, /usr/bin/logger, or /bin/logger with authpriv.notice. Obviously if the user hits deny we fail out back to the authentication screen.
Disadvantages : change to expected login procedure/alternate login mananger, extra script on login
Advantages : acknowledgement tied that the login banner was accepted/read to a particular user, better framing of potentially large banner text
Sincerely,
Rob Sanders
===========================
Rob Sanders
Sr. Secure Systems Engineer
Raytheon Trusted Computer Solutions
12950 Worldgate Drive, Suite 600
Herndon, Virginia 20170
Security Blanket Support: 1-866-230-1317
Security Blanket Email: SecurityBlanket(a)TrustedCS.com
Office: 703-896-4762
Fax: 703-318-5041
Email: RSanders(a)TrustedCS.com
10 years, 6 months
[PATCH 01/11] Added per ticket #122.
by Michele Newman
---
RHEL6/input/auxiliary/alt-titles-stig.xml | 3 +++
1 file changed, 3 insertions(+)
diff --git a/RHEL6/input/auxiliary/alt-titles-stig.xml b/RHEL6/input/auxiliary/alt-titles-stig.xml
index b7f36d5..0576b1b 100644
--- a/RHEL6/input/auxiliary/alt-titles-stig.xml
+++ b/RHEL6/input/auxiliary/alt-titles-stig.xml
@@ -38,6 +38,9 @@ A file integrity tool must be installed.
<title rule="aide_periodic_cron_checking" shorttitle="Configure Periodic Execution of AIDE">
A file integrity tool must be used at least weekly to check for unauthorized file changes, particularly the addition of unauthorized system libraries or binaries, or for unauthorized modification to authorized system libraries or binaries.
</title>
+<title rule="rpm_verify_hashes" shorttitle="Verify File Hashes with RPM">
+The system package management tool must verify contents of all files associated with packages.
+</title>
<title rule="rpm_verify_permissions" shorttitle="Verify File Permissions with RPM">
The system package management tool must verify permissions on all file and directories associated with packages.
</title>
--
1.8.0
10 years, 6 months
rpm_verify_hashes breaks build
by Shawn Wells
$ make all
cd RHEL6 && make
make[1]: Entering directory `/var/www/html/scap-security-guide/RHEL6'
xsltproc -o output/rhel6-shorthand.xml input/guide.xslt input/guide.xml
input/system/software/integrity.xml:184: parser error :
xmlParseEntityRef: no name
<pre># rpm -Va | grep '$1 ~ /..5/ && $2 != "c"'</pre>
^
input/system/software/integrity.xml:184: parser error :
xmlParseEntityRef: no name
<pre># rpm -Va | grep '$1 ~ /..5/ && $2 != "c"'</pre>
Entered this as https://fedorahosted.org/scap-security-guide/ticket/164,
assigned to Michele Newman per git blame ;)
10 years, 6 months