Getting Started
by Tim Burress
Hello!
I'm still learning my way around the directory tree and the build system and have a couple of questions. For historical reasons, we typically use CentOS on our servers, and I see that, instead of having its own product tree, CentOS is considered a derivative of RHEL. I suppose the reasons for that are pretty obvious, though it does create a bit of a problem when trying to do something specific to CentOS. One question I have about the way things are set up now, though, is that, although the XCCDF for RHEL7 defines 12 profiles, the XCCDF for CentOS only defines 2. I've grep'ed my way around the build system trying to figure out where the logic for that is, but haven't had any luck. Could someone point me to the right place?
What we want to do, ultimately, is define several new profiles that would be applied to CentOS within our organization, depending on the risk level of the system. The baseline for this would be close to the RHEL7 CUI profile, with a few obvious exceptions. Given the special status of CentOS as a derivative of RHEL, do you have any suggestions for a good way to do that? I'm guessing we'd have to define the profiles in rhel7/profiles, but then use some logic somewhere (nice and vague...) to apply them to CentOS so they end up in the CentOS XCCDF and DS, but rather than trial-and-error I thought I would just ask.
Along the way we'll probably write some OVAL content and rules to handle local situations and would be happy to contribute those if they would be useful.
Thanks!
4 years, 6 months
Scan-workbench - modifying customizations, and comparing profiles
by Sanders, Robert
Hello all,
Is there any way to load a set of customizations into scap-workbench, make some additional tweaks, and then output *only* the customizations themselves (old + new changes)? Everytime I’ve tried to do this I wind up with effectively the entire profile with my customizations overriding the original profile settings. To get around this I have my ‘gold’ customization file, and then for anything other than a trivial modification I create a branch new customization and manualy cut/paste my customization back into my gold file. Painful.
And next - I’d posted a year or so ago in the ‘open-scap’ mailing list asking if there was a reliable/good way to compare baselines (example - C2S vs stig-rhel7-disa, or a tailoring file against the reference). Seems to be to be a glaring missing feature. I started to write a comparison tool for my own use and have a very clunky python script to do it. I’d planned (and received permission from management) to release that back to the community (under the BSD 3-clause to match scap-security-guide) but got very side-tracked at work. Had to revisit it and realized just how clunky it is. Unless there is an accepted way to do this I’ll try to find time to clean it up and post i.
-Rob
--
ROBERT SANDERS
Sr. Secure Systems Engineer
FORCEPOINT
T +1.703.896.4762
F +1.703.318.5041
www.forcepoint.com
FORWARD WITHOUT FEAR
4 years, 6 months
--stig-viewer
by Albert Roberson
Hello all,
I am having some trouble generating content for the DISA stig-viewer.
Stig-viewer version = 2.9
ComplianceAsCode version = 1.46
Openscap version = 1.2.17
RHEL OS 7.7
I am running the scan with the following command:
oscap xccdf eval --profile xccdf_org.ssgproject.content_profile_stig --oval-results --results /tmp/`hostname`-`date +%F%H%M`-stig-scan-oval-results.xml --report /tmp/`hostname`-`date +%F%H%M`oval-xccdf-report.html --stig-viewer /tmp/`hostname`-`date +%F%H%M`-stig-viewer-oval-results.xml --fetch-remote-resources --remediate ssg-rhel7-ds.xml
The file resulting from the ‘--results’ option causes a pop window to show when attempting to import into the stig-viewer:
Result Reference ID(s) Not Found in the Checklist STIG(s)
The file resulting from the ‘--stig-verwer’ option produces no pop window, but all fo the rules show as not reviewed.
Am I missing something with the options chosen? Are the resulting files and the current version of the DISA stig-viewer not compatible?
Any help is appreciated.
Thank you.
4 years, 6 months
Re: [Open-scap] affecting the sysconfig ifcfg network scripts
by Watson Sato
Hello Nick,
On Tue, Sep 10, 2019 at 4:32 PM Nick Jensen <nick(a)alienonesecurity.com>
wrote:
> Hello! Came across this issue… is this the right place to report it?
>
This is probably more fit to the Content list <
scap-security-guide(a)lists.fedorahosted.org>. I have added it to CC.
>
> Following provisioning a system and running some hardening processes my
> team noticed a “bad file” at `/etc/sysconfig/network-scripts/
> ifcfg-eno49?eno1?eno2?eno50?eno3?eno4`.
>
> The only reference I’ve found is in the ssg-centos7-ds.xml file:
>
I'm curious what version of Content or SSG you are using.
I recognize this snippet, and it it is not maintained in upstream.
See https://github.com/ComplianceAsCode/content/pull/2328
Main reason being that the script assumes a lot of things about network
configuration and interfaces, and it will not configure the appropriate
interface into appropriate zone.
That being said, I'd like to understand your use case on this rule and
remediation.
Except for the bug you just reported, would it set the an interface as
expected?
Can the script be made generic enough and still be useful?
> ```
>
> if [ $nic_bound = false ];then # Add first NIC to SSH enabled zone if ! firewall-cmd --state -q; then<ns10:sub idref="xccdf_org.ssgproject.content_value_function_replace_or_append" use="legacy" /> replace_or_append "/etc/sysconfig/network-scripts/ifcfg-${eth_interface_list[0]}" '^ZONE=' "$firewalld_sshd_zone" 'CCE-80447-6' '%s=%s' else # If firewalld service is running, we need to do this step with firewall-cmd # Otherwise firewalld will comunicate with NetworkManage and will revert assigned zone # of NetworkManager managed interfaces upon reload firewall-cmd --zone=$firewalld_sshd_zone --add-interface=${eth_interface_list[0]} firewall-cmd --reload fifi
>
> ```
>
> It appears that `eth_interface_list` is defined via following in same
> file:
>
> ```
> eth_interface_list=$(ip link show up | cut-d' '-f2| cut-d':'-s-f1| grep-E
> '^(en|eth)')
> ```
>
> and then used as `${eth_interface_list[0]}`, which gets all active
> interfaces separated by newlines versus the intended… just the first active
> interface.
>
> This should be accomplished by adding another set of parentheses:
>
> ```
> eth_interface_list=($(ip link show up | cut-d' '-f2| cut-d':'-s-f1| grep-E
> '^(en|eth)’))
> ```
>
> then it should work as intended.
>
>
>
> Sincerely,
>
> Nick
> _______________________________________________
> Open-scap-list mailing list
> Open-scap-list(a)redhat.com
> https://www.redhat.com/mailman/listinfo/open-scap-list
--
Watson Sato
Security Technologies | Red Hat, Inc
4 years, 7 months
Re: Short lived branches for stabilization before release
by Gabe Alford
The project discussed this several years ago as well as adding LTS brances
but ultimately decided against it due to the maintenance costs and burdens
placed on owners.
Not sure what has changed since security is always changing and evolving.
> I have so many commits I have yet to get commited because I am constantly
playing catchup with the new releases.
I would recommend to any and all contributors to submit commits regardless
of where in the release cycle things are.
Breaking commits up into small manageable PRs means that over time there
won't be a need to catchup. Otherwise, the time between catching up and
release will ultimately become unmanageable.
On Wed, Sep 4, 2019 at 10:11 AM Trey Henefield <trey.henefield(a)ultra-ats.com>
wrote:
>
>
> I second that idea. Along with a release schedule.
>
>
>
> I have so many commits I have yet to get commited because I am constantly
> playing catchup with the new releases.
>
>
>
> 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
>
>
>
> *From:* Watson Sato <wsato(a)redhat.com>
> *Sent:* Wednesday, September 4, 2019 10:53 AM
> *To:* SCAP Security Guide <scap-security-guide(a)lists.fedorahosted.org>
> *Subject:* Short lived branches for stabilization before release
>
>
>
> Hello,
>
>
>
> I'd like to prose and ask for feedback on $subject idea.
>
> The main objective is to have a place and period of time to fix bugs
> before a release happens.
>
> This would give interested parties space and time to work on fixes, and it
> would be more transparent and evident that a release is around the corner.
>
>
>
> How would this work?
>
> Around two weeks before the release date, a branch is created for the next
> version and only fixes can be merged to this branch.
>
> When release date comes, release happens from the branch. And then it is
> merged back into master, so that fixes are there too.
>
>
>
> --
>
> Watson Sato
> Security Technologies | Red Hat, Inc
>
>
> *Disclaimer*
> The information contained in this communication from *
> trey.henefield(a)ultra-ats.com <trey.henefield(a)ultra-ats.com> * sent at
> 2019-09-04 12:10:35 is private and may be legally privileged or export
> controlled. It is intended solely for use by *
> scap-security-guide(a)lists.fedorahosted.org
> <scap-security-guide(a)lists.fedorahosted.org> * and others authorized to
> receive it. If you are not * scap-security-guide(a)lists.fedorahosted.org
> <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.
>
> _______________________________________________
> scap-security-guide mailing list --
> scap-security-guide(a)lists.fedorahosted.org
> To unsubscribe send an email to
> scap-security-guide-leave(a)lists.fedorahosted.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedorahosted.org/archives/list/scap-security-guide@lists.fe...
>
4 years, 7 months
Short lived branches for stabilization before release
by Watson Sato
Hello,
I'd like to prose and ask for feedback on $subject idea.
The main objective is to have a place and period of time to fix bugs before
a release happens.
This would give interested parties space and time to work on fixes, and it
would be more transparent and evident that a release is around the corner.
How would this work?
Around two weeks before the release date, a branch is created for the next
version and only fixes can be merged to this branch.
When release date comes, release happens from the branch. And then it is
merged back into master, so that fixes are there too.
--
Watson Sato
Security Technologies | Red Hat, Inc
4 years, 7 months
