2015 Red Hat Summit: Discounted passes for SSG & OpenSCAP community members
by Shawn Wells
Hey Guys,
The 2015 Red Hat Summit (http://www.redhat.com/summit) will take
place June 23-26 in Boston. The event may seem far away, but we all know
how long it takes for integrators and govies to allocate training and
travel budgets... :)
This year we've ensured that _*any*_ member of the SSG & broader
OpenSCAP community is eligible for discounted Summit passes at $950/pass
(or $895/pass for groups of 4+). Doesn't matter if you're a code
contributor, occasional voice on the mailing lists, or silent partner.
For reference, the full conference pass is generally $1,975 (ref
http://www.redhat.com/summit/rates/).
In 2012 the SCAP session was standing room only, and in 2013 it was
rated the #3 session (out of 196 sessions) by attendees. We hope to see
you there this year!
In full transparency: I don't get any RHT kickback or commissions
off this. I received a special registration code that allows me to
empirically show various managers/event staff how much interest there is
in SCAP and Security Automation. For every 10 registrants that use the
code, I get to send a RHT engineer to Red Hat Summit.
Contact me _*off-list*_ if interested!
-sdw
8 years, 8 months
sshd banner warning
by Jeremiah Jahn
We used to have to keep out banners under /etc/issue for the console,
and /etc/issue.net for remote access.
Would it be okay to make this rule deal with either one?
diff --git a/shared/oval/sshd_enable_warning_banner.xml
b/shared/oval/sshd_enable_warning_banner.xml
index 0bd8d32..ace8b75 100644
--- a/shared/oval/sshd_enable_warning_banner.xml
+++ b/shared/oval/sshd_enable_warning_banner.xml
@@ -25,7 +25,7 @@
</ind:textfilecontent54_test>
<ind:textfilecontent54_object id="obj_sshd_banner_set" version="2">
<ind:filepath>/etc/ssh/sshd_config</ind:filepath>
- <ind:pattern operation="pattern
match">^[\s]*(?i)Banner(?-i)[\s]+/etc/issue[\s]*(?:|(?:#.*))?$</ind:pattern>
+ <ind:pattern operation="pattern
match">^[\s]*(?i)Banner(?-i)[\s]+/etc/issue(.net){0,1}[\s]*(?:|(?:#.*))?$</ind:pattern>
<ind:instance datatype="int">1</ind:instance>
</ind:textfilecontent54_object>
</def-group>
8 years, 10 months
Configuration testing vs Forensic testing
by Steve Grubb
Hello,
I think there is a problem in the SSG content. I think that the current
content is intended to check the system configuration. This would be done by
examining the files on disk to warn about changes or thing that are
misconfigured. There is also another category of testing that is forensics
which checks the ephemeral / current values being enforced. Both are necessary
and useful, but they should not be mixed.
Some examples to illustrate the point:
Forensic Configuration
-----------------------------------------------------------------
auditctl -l vs cat /etc/audit/audit.rules
mount vs cat /etc/fstab
sysctl -a vs cat/etc/sysctl.conf
service ip6tables status vs chkconfig ip6tables --list
All these need to be changed in the prose to better express what the SCAP tool
is actually checking. IOW, you can get different results by hand than the tool
itself would report.
This really needs to be addressed before anyone else uses SSG as the basis of
their own recommendations. Again, forensic checking is useful and I would say
content should be specifically designed with that in mind. But it is not what
should be in a baseline.
Thanks,
-Steve
8 years, 11 months
FYI: scap-security-guide v0.1.20 to arrive in the second week of the New Year (preliminary 2015-01-09)
by Jan Lieskovsky
Hello folks,
given:
* there are more than 10 PRs currently opened (still in progress)
against 0.1.20 version,
* and the holiday break ahead us,
I have decided to postpone the planned pre-Christmas 0.1.20 release
by two weeks (the new release date for 0.1.20 version to be Friday,
9-th January 2015) yet.
Therefore there should be more time to finalize existing requests
and / or submit new features into 0.1.20 release yet.
Merry Christmas & a Happy New Year.
Jan
--
Jan iankko Lieskovsky / Red Hat Security Technologies Team
8 years, 11 months
GRUB2
by Nick Crawford
*
Overview
Grub2 has a number of differences with the original Grub. This is
especially relevant for RHEL 7 content.
Grub2’s grub.cfgis now more script than config file. There are 2
possible config files; /etc/grub2.cfglinked to /boot/grub2/grub.cfgfor
BIOS mode and /etc/grub2-efi.cfglinked to
/boot/efi/EFI/redhat/grub.cfgfor EFI mode. Changes to the source files
/etc/default/gruband /etc/grub.d/*are compiled into your grub.cfgby
grub2-mkconfig –o </path/to/relevant/grub.cfg>.
What used to be simple kernel appends in grub.confare now controlled by
/etc/default/grubin the variable GRUB_CMDLINE_LINUXfor persistent changes.
SSG inconsistency
Much of the work for grub2 has already been done in BIOS mode. Much of
the completed stuff from SSG RHEL/7/distfor Grub2 seems good and
supports both BIOS and EFI. SSG RHEL/7/inputlacks consistency with
RHEL/7/distas inputis all BIOS mode only. There are still references to
grub.confto be addressed.
EFI Grub2 is also unaddressed in the Fedora content.
EFI systems could potentially boot from either EFI or Emulated BIOS,
complicating matters when both Grub2 configs are discovered. I'm
unaware of a current requirement to boot from one or the other, or to
implement Secure Boot (requires EFI). EFI systems could potentially be
evaluated by the presence of the efivarfs mount. I don’t have a
hardware EFI system supporting Emulated BIOS boot to verify this.
# mount | grep efivarfs
efivarfs on /sys/firmware/efi/efivars type efivarfs
(rw,nosuid,nodev,noexec,relatime)
# if [ -d /sys/firmware/efi/efivars ]; then echo do EFI stuff; else echo
do BIOS stuff; fi
Previously checks were against /etc/grub.conf,now checks have to use
either /etc/grub2.cfgor /etc/grub2-efi.cfg. Additionally checks should
reference GRUB_CMDLINE_LINUXto ensure persistent changes exist (or don't).
Further, there appears to be a default reference from grub.cfgto a
custom.cfgthat can hold additional settings. Potentially
custom.cfgshould be checked as well if it exists. The custom.cfglives
along-side grub.cfgin either /boot/grub2or /boot/efi/EFI/redhatand is
sourced into the main grub.cfg.
Questions for SSG
*
When should the symbolic links /boot/grub2.cfgand
/boot/grub2-efi.cfgbe used? Config checks, REGEX?
*
When should the real files /boot/grub2/grub.cfgand
/boot/efi/EFI/redhat/grub.cfgbe used? Permission/SE Context checks?
*
When should /etc/default/grub: GRUB_CMDLINE_LINUXbe referenced?
Append operations?
*
Should /etc/grub.d/*be checked for anything, or just the resulting
grub.cfg?
*
Should custom.cfgbe checked for “hidden” settings?
*
In systems that may support both BIOS Grub2 and EFI Grub2 do we need
to check both when both exist, or attempt to discover which boot
mode we're using?
Affected SSG sections that I can locate:
1.
(bootloader_password) Bootloader password section is BIOS only.
2.
(bootloader_audit_argument) Sections adding audit=1still point to
grub.conf, it should be GRUB_CMDLINE_LINUXin /etc/default/grubfor
persistence.
3.
(enable_selinux_bootloader) Sections checking for selinux=0still
point to grub.conf, it should be relevant grub2.cfgor grub2-efi.cfg,
and GRUB_CMDLINE_LINUX.selinux=0could potentially be hidden in
custom.cfgor grub.d/*. Perhaps replace this with a check against
/proc/cmdlineto check if the running kernel was booted selinux=0?
4.
(bootloader_nousb_argument) Sections adding nousbstill point to
grub.conf, it should be GRUB_CMDLINE_LINUXfor persistence.
5.
RHEL/7/inputs/fixes/bash/*grub2_cfg.share BIOS only.
6.
RHEL/7/inputs/system/accounts/physical.xmlgrub2 sections are BIOS only.
7.
PAE-kernel section still lists grub.conf, it's now
grub2-set-default/ grub2-editenv, further RHEL 7 currently is x86_64
only so there is no PAE-kernel.
Documentation Error
If you tried to secure grub2 with a password earlier there were a couple
of typos in the docs from Fedora/Red Hat, this has been corrected.
Fixed https://bugzilla.redhat.com/show_bug.cgi?id=1157161
grub2-mkconfig vs patched kernel
Running grub2-mkconfig as required by these Grub2 sections will cause
the system to boot the unpatched release kernel. Running the following
will fix the issue;
CKERN=$(grub2-editenv list | grep saved_entry | cut -d '=' -f2)
DKERN=$(cat /etc/grub2.cfg | grep ^menuentry | grep "${CKERN}" | awk
-F"'" '{print $4}')
grub2-set-default "${DKERN}"
Reported https://bugzilla.redhat.com/show_bug.cgi?id=1154430
*
8 years, 11 months
SCAP Content Submission ...
by Trey Henefield
Greetings,
I have some content I would like to contribute to the SSG community.
The content is attached in a zip file and should be extracted directly into the repo.
The summary of these changes are as follows:
- New content has been included to address DISA STIGs for:
o Firefox
o Java
o Red Hat 5 (This content addresses the Red Hat 5 STIG requirements for Red Hat 5, Red Hat 4, CentOS 5, and CentOS 4)
o Webmin
- Modified shared/transforms/combinechecks.py to include an actual timestamp in the oval content when it gets created.
- Added shared/transforms/stats.sh to display statistics when building content. The statistics identify the total number of requirements, as indicated in the stig_overlay.xml document for each STIG, the number of checks addressed by STIG requirements, and the number of fixes addressed by each STIG requirement. In addition, it also pulls in the DISA STIG information from the references folder (e.g. RHEL/5/references) and compares it with the STIG requirements in the stig_overlay.xml to support identifying differences (i.e. STIG requirements removed or added).
- Added shared/transforms/stig_refs.sh to support pulling information (CCI, CCE, Severity, SVkey, SVrelease, IA controls, and title) from the DISA STIG and automatically populating that information into the SCAP content for consistency. There could probably be a better way to script this capability, but given the large number a requirements in the RHEL5 STIG, it was a great help. This capability is not called at build time, but on an as needed basis. When executed, it should be called from within the SCAP content directory (e.g. RHEL/5) and also requires the DISA STIG XCCDF file to be available in the references folder of the SCAP content directory (e.g. RHEL/5/references). Example: `cd RHEL/5; ../../shared/transforms/stig_refs.sh`
Happy SCAPing!
Best regards,
Trey Henefield, CISSP
Senior IAVA Engineer
Ultra Electronics
Advanced Tactical Systems, Inc.
4101 Smith School Road
Building IV, Suite 100
Austin, TX 78744 USA
Trey.Henefield(a)ultra-ats.com
Tel: +1 512 327 6795 ext. 647
Fax: +1 512 327 8043
Mobile: +1 512 541 6450
www.ultra-ats.com
Disclaimer
The information contained in this communication from trey.henefield(a)ultra-ats.com sent at 2014-12-04 12:46:15 is confidential and may be legally privileged.
It is intended solely for use by scap-security-guide(a)lists.fedorahosted.org and others authorized to receive it. If you are not scap-security-guide(a)lists.fedorahosted.org you are hereby notified that
any disclosure, copying, distribution or taking action in reliance of the contents of this information is strictly prohibited and may be unlawful.
8 years, 11 months
RE: SCAP Content ...
by Trey Henefield
I have one more minor contribution.
In the past, there has only been one SCAP content per OS. With the introduction of multiple SCAP contents that could be applicable to a single system, I have had a desire to create a way to facilitate performing a scan with all applicable content in a simplified manner. I really liked the concept of the /etc/init.d/oscap-scan and /etc/sysconfig/oscap-scan setup. I contributed a minor change to these files in openscap, which are available in v1.2.0. I have also attached the init file for older versions (1.0.8). So with the init file change in place, it creates a means of walking through multiple scan configurations and applying each.
So the attached zip includes oscap-scan configuration files for the new content I included. I also updated the spec file to package them in the rpm. The only further enhancement I could foresee is including a detection of the running OS in the spec file and only installing oscap-scan configuration files applicable to the OS (e.g. don't install the RHEL5 oscap-scan configuration file on RHEL6 or RHEL7).
So with these changes in place, you can simply run 'service oscap-scan start' to scan and remediate your RHEL5 system, in addition to firefox, java, and webmin packages. All in one sweep.
Best regards,
Trey Henefield, CISSP
Senior IAVA Engineer
Ultra Electronics
Advanced Tactical Systems, Inc.
4101 Smith School Road
Building IV, Suite 100
Austin, TX 78744 USA
Trey.Henefield(a)ultra-ats.com
Tel: +1 512 327 6795 ext. 647
Fax: +1 512 327 8043
Mobile: +1 512 541 6450
www.ultra-ats.com
-----Original Message-----
From: Jan Lieskovsky [mailto:jlieskov@redhat.com]
Sent: Friday, December 05, 2014 6:07 AM
To: Trey Henefield; Shawn Wells
Subject: Re: SCAP Content ...
Hey Trey, Shawn,
----- Original Message -----
> From: "Shawn Wells" <shawn(a)redhat.com>
> To: "Trey Henefield" <trey.henefield(a)ultra-ats.com>
> Cc: "Jan Lieskovsky" <jlieskov(a)redhat.com>
> Sent: Thursday, December 4, 2014 7:33:37 PM
> Subject: Re: SCAP Content ...
Trey,
I second to Shawn. From a brief look this is a really brilliant contribution.
Thanks a lot for it!
>
> This is fantastic! Skimmed the approval text, will definitely review
> when I get time later today. Will approve the patch email when I see
> the request come through (there's often a delay between posting and
> when list moderators get the notice).
Shawn, the email has now reached the queue (Date: December 4, 2014 6:46 PM,
Subject: scap-security-guide post from trey.henefield(a)ultra-ats.com requires approval).
Please approve it.
Regarding the inclusion - if you make a PR, I can review it. Or should you be busy today, just make the ticket & attach the zip to it. I can make a PR during weekend & you can review. Either way works for me [*].
Thank you && Regards, Jan.
--
Jan iankko Lieskovsky / Red Hat Security Technologies Team
[*] I could make a ticket & attach the zip Trey sent in different email as attachment to it.
But to make the inclusion process more transparent & for proper contribution attribution,
IMHO it will be better to wait till the email + the attachment reaches the SSG mailing list.
>
> Shawn
>
> --
> Shawn Wells
> Director, Innovation Programs
> shawn(a)redhat.com | 443.534.0130
> @shawndwells
>
> > On Dec 4, 2014, at 1:28 PM, Trey Henefield
> > <trey.henefield(a)ultra-ats.com>
> > wrote:
> >
> >
> >
> > Finally got export approval.
> >
> > For your reference, here was the outcome of that:
> >
> > “Per our conversation, the SCAP content you are proposing below is
> > not subject to the EAR in accordance with 15 CFR 734.3(b)(3). It
> > may be released online without restriction.
> >
> > The above-referenced section of the EAR states that the following
> > items are not subject to the EAR:
> >
> > (3) Publicly available technology and software, except software
> > classified under ECCN 5D002 on the Commerce Control List, that:
> > (i) Are already published or will be published as described in §
> > 734.7 of this part;
> > (ii) Arise during, or result from, fundamental research, as
> > described in §
> > 734.8 of this part;
> > (iii) Are educational, as described in § 734.9 of this part;
> > (iv) Are included in certain patent applications, as described in §
> > 734.10 of this part.
> >
> > The SCAP content is based on two publicly available technology sources:
> > DISA’s STIGs and NIST’s SCAP formatting requirements. Both are publicly
> > available online without restriction. There has been no addition of
> > controlled, US technology involved in creating this content – from
> > an export standpoint, it is merely a translation from one format to another.
> >
> > There is no encryption involved in either the original content or
> > the end-product.
> >
> > DISA has posted equivalent SCAP content publicly on their website.
> > The only difference between that content and the content proposed
> > here is that this is based on more current (but still publicly
> > releasable) STIG content.”
> >
> > I have just posted my content to the group. But I believe it will
> > require moderator approval as it exceeds the 200KB limit.
> >
> >
> > Best regards,
> >
> > Trey Henefield, CISSP
> > Senior IAVA Engineer
> >
> > Ultra Electronics
> > Advanced Tactical Systems, Inc.
> > 4101 Smith School Road
> > Building IV, Suite 100
> > Austin, TX 78744 USA
> >
> > Trey.Henefield(a)ultra-ats.com
> > Tel: +1 512 327 6795 ext. 647
> > Fax: +1 512 327 8043
> > Mobile: +1 512 541 6450
> >
> > www.ultra-ats.com
> >
> > From: Shawn Wells [mailto:shawn@redhat.com]
> > Sent: Tuesday, November 18, 2014 11:54 AM
> > To: Trey Henefield; Jan Lieskovsky
> > Subject: Re: SCAP Content ...
> >
> > On 11/18/14, 12:17 PM, Trey Henefield wrote:
> > Hi Shawn,
> > I finally got approval to submit my content changes upstream. I
> > just wanted to give you a heads up that there will be allot of
> > wonderful changes coming your way soon.
> > In addition to changes to existing content for RHEL6, I have created
> > content for RHEL5, Firefox, Java, and Webmin. The RHEL5 content
> > currently supports RHEL4 and RHEL5, as well as CentOS4 and CentOS5.
> > I hope that’s ok, given the debate going on about CentOS.
> > I am currently getting my content in sync will all the current
> > changes in the repo. I branched off about a year ago.
> > So as soon as I am done with that, I will send it your way. Because
> > there are so many changes, I would prefer to send them to you zipped
> > up via email and allow you to upload them as you approve them. I hope that’s ok.
> >
> > That's awesome Trey! I've looped in Jan to keep him fully informed.
> >
> > Content for extra applications would be most interesting, especially
> > around Firefox and Java. Are these OS-specific configs (e.g. Firefox
> > on RHEL6) or applicable to Firefox on any version of RHEL? If
> > agnostic we'll want to create a new top-level directory, else place
> > the content within input/services (or somewhere appropriate).
> >
> > RHEL4 is EOL, so I don't particularly see a need to create a new
> > top-level directory for it. RHEL5 makes perfect sense, though. As
> > for CentOS vs RHEL... perhaps leaving off CPE tags for the rules
> > will suffice, vs creating a CentOS top-level directory.
> >
> > Note in the last year we moved the code to GitHub. You should be
> > able to set an "upstream" remote target to rebase against, e.g.:
> >
> > $ git remote add upstream
> > https://github.com/OpenSCAP/scap-security-guide.git
> >
> > Then once added:
> > $ git checkout master
> > $ git fetch upstream
> > $ git merge upstream/master
> > (this will likely cause a series of merge conflicts. send a note to
> > the list if you need some help merging!)
> >
> > In terms of patch review, if you're not comfortable with GitHub pull
> > requests (which is a bit convoluted, especially the required
> > branching), would you be willing to post them to the mailing list?
> > This would allow many more eyes during the review.
> >
> > Out of curiosity, how did you get your management approval to commit
> > back upstream? Any lessons learned we could reuse?
> >
> >
> > Disclaimer
> > The information contained in this communication from
> > trey.henefield(a)ultra-ats.com sent at 2014-12-04 13:12:26 is private
> > and may be legally privileged or export controlled. It is intended
> > solely for use by shawn(a)redhat.com and others authorized to receive
> > it. If you are not shawn(a)redhat.com you are hereby notified that any
> > disclosure, copying, distribution or taking action in reliance of
> > the contents of this information is strictly prohibited and may be unlawful.
> >
>
Disclaimer
The information contained in this communication from trey.henefield(a)ultra-ats.com sent at 2014-12-08 13:22:52 is confidential and may be legally privileged.
It is intended solely for use by scap-security-guide(a)lists.fedorahosted.org and others authorized to receive it. If you are not scap-security-guide(a)lists.fedorahosted.org you are hereby notified that
any disclosure, copying, distribution or taking action in reliance of the contents of this information is strictly prohibited and may be unlawful.
8 years, 12 months