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).
(1) For every project within SSG, create a unique branch. Currently this
would set us up as:
(2) Each project is responsible for their own release tags.
| |--- InformalDraft
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
(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
[Errno 14] PYCURL ERROR 22 - "The requested URL returned error: 404"
Trying other mirror.
Error Downloading Packages:
scap-security-guide-0.1-9.noarch.rpm from epel-scap-security-guide:
[Errno 256] No more mirrors to try.
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.
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
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
I've created an SCAP Security Guide RPM yum repository off
fedorahosted.org. Moving forward official RPMs will be housed here.
To enable the repository:
$ wget -O /etc/yum.repos.d/epel-6-scap-security-guide.repo
To download the latest content:
$ sudo sh -c "yum install scap-security-guide"
v0.1-8 is now available in the repository. This minor update reflects
copy editing patches, and does not contain any OVAL updates.
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
@@ -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 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 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.