scap-security-guide April 2016

scap-security-guide@lists.fedorahosted.org

7 participants
4 discussions

Potential SELinux inclusion in RHEL7 STIG
by Mackanick, Jason W CIV DISA RE (US) 11 May '16

11 May '16

I am here with Shawn Wells today and we would like your help in developing the requirements for a possible inclusion of SELinux requirements to be included in the RHEL7 STIG. As we move away from legacy file permissions to type enforcement, we would like to work with the community to understand security relevant configuration options such as SELinux Booleans used in operational environments. To calm any fears associated with SELinux, we are only considering targeted policy and not the MLS enablement. Shawn will be working to gather your input. Any of your input would be appreciated if we could get it by Tuesday March 22, 2016 at the end of business.

10 17

SCAP Security Guide 0.1.29 is out
by Jan Lieskovsky 25 Apr '16

25 Apr '16

Hello folks, after more than three months of intensive work we are thrilled to announce the SCAP Security Guide v0.1.29 has been released: * [1] https://github.com/OpenSCAP/scap-security-guide/releases/tag/v0.1.29 The highlights of this release are as follows: * Numerous STIG profile enhancements for Red Hat Enterprise Linux 7 product, * The produced benchmark for Red Hat Enterprise Linux 6 product now passes NIST SCAP Content Validation Tool 1.2.1.14 requirements, * A plenty of new OVAL checks have been implemented for the Red Hat Enterprise Linux 7 product, * A substantial effort has been contributed the existing SCAP content for JBoss EAP v5 and JBoss Fuse v6 products to follow the format as expected by regular SCAP Security Guide product, * Other numerous XCCDF, OVAL, and remediation scripts enhancements and bug fixes See [1] for a more complete overview of the changes implemented (my notes indicate there have been ~420 changes since 0.1.28 release). The pre-built Zip archives with DataStream files are available at usual places: * https://github.com/OpenSCAP/scap-security-guide/releases/download/v0.1.29/s… (using OVAL 5.10 language version) * https://github.com/OpenSCAP/scap-security-guide/releases/download/v0.1.29/s… (using OVAL 5.11 language version) I would like to use this opportunity to issue thanks to all contributors (developers, testers, issue reporters) who have helped this release to become a reality. Happy hardening Regards, Jan -- Jan iankko Lieskovsky (on behalf of the SCAP Security Guide upstream team) P.S.: As always should you encounter issues with the provided policies, kindly report them at: https://github.com/OpenSCAP/scap-security-guide/issues/new

1 0

Re: Potential SELinux inclusion in RHEL7 STIG
by Trevor Vaughan 08 Apr '16

08 Apr '16

I'm going to go with 'it depends'. I've had very different results with permissive domain vs permissive global vs enforcing when trying to figure out what's actually killing my application. Also, I'm doing all of this in a test environment and determining if it's SELinux, FIPS, or something else, quickly is important so some heavy handed approaches are low risk and high reward. In production, I would absolutely recommend the approach that you linked. But you should know that the service you're deploying already works with SELinux enabled far before production. Trevor On Apr 8, 2016 9:52 AM, "Steve Grubb" <sgrubb(a)redhat.com> wrote: On Friday, April 08, 2016 09:42:52 AM Trevor Vaughan wrote: > I'm 100% on board with requiring SELinux to be enabled in targeted mode > moving forward. > > The SIMP (https://github.com/NationalSecurityAgency/SIMP) stack runs with > both SELinux targetd mode enabled and FIPS mode enabled in all of our tests > and in our default installation. We identify where there are issues and we > write custom policies as necessary to make our applications function > properly. > > I don't know that I would restrict network connections by default (we > don't....yet) but it's certainly something to strive toward. As is all > outbound connections blocked by IPTables by default. (If my phone can do > it, it shouldn't be a giant hurdle) > > The SELinux ecosystem has improved to the point where it is usable and > maintainable by most administrators. That said, there does need to be the > understanding that the process for moving forward if SELinux does not work > should be: > > 1) Set SELinux to permissive on that system (never disable it or your > contexts will be a mess when you try to enable it later) Shouldn't the recipe be to put the application that is not working into a permissive domain? https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/ht… RHEL7 also supports permissive domains. Then if you still have problems, put the whole machine into permissive mode. -Steve > 2) Create an action plan to create the proper policy for your application > 3) Create the application policy > 4) Implement the application policy > 5) Re-enable SELinux in targeted mode > > Any broken policy, shipped by a vendor, should be seen as a high priority > incident for that vendor and a patch should be shipped publicly as quickly > as feasible. > > The SELinux community seems to have also gotten to the point where there is > some realization that some policy is better than no policy. So that's a big > win overall. You may end up with a weaker policy surrounding your > application than you would like but that's 100% better than disabling > SELinux across the system for one application. > > Thanks, > > Trevor > > On Mon, Mar 21, 2016 at 12:12 PM, Shawn Wells <shawn(a)redhat.com> wrote: > > On 3/21/16 10:44 AM, Šimon Lukašík wrote: > > > > On 03/16/2016 07:26 PM, Mackanick, Jason W CIV DISA RE (US) wrote: > > > > I am here with Shawn Wells today and we would like your help in developing > > the requirements for a possible inclusion of SELinux requirements to be > > included in the RHEL7 STIG. As we move away from legacy file permissions > > to type enforcement, we would like to work with the community to > > understand security relevant configuration options such as SELinux > > Booleans used in operational environments. To calm any fears associated > > with SELinux, we are only considering targeted policy and not the MLS > > enablement. Shawn will be working to gather your input. Any of your > > input would be appreciated if we could get it by Tuesday March 22, 2016 > > at the end of business. > > > > > > Hello Jason, > > > > After talking with selinux crew here in Red Hat, I have learned that > > defaults for selinux booleans are set rather defensively. The default is > > always the more secure unless too generic use-case would be restricted. > > > > There is over 300 houndred selinux booleans in Red Hat Enterprise Linux > > 7. I wonder where we can start. Or do you have some specific booleans in > > mind? > > > > Perhaps it makes sense to go through these 300 hundreds and put them > > into some kind of buckets? Something like > > > > booleans that should absolutely always be true > > booleans that should always be false > > > > booleans that default to true, but operators may often need to turn > > > > them false > > > > ... > > > > booleans that default to true, but stig advices to keep them false > > ... > > > > Thoughts? > > > > > > To ensure everyone is on the same page of booleans, here's a list of the > > ~300 RHEL7 booleans (output of 'semanage boolean -l'): > > http://people.redhat.com/swells/boolean_list.txt > > > > One of the things discussed with DISA was proper scoping of what a RHEL7 > > STIG looks like. In the past, the RHEL STIGs have been a catch-all and > > included configuration settings for things like OpenLDAP Server, HTTPD, > > and > > other 3rd party software (defined as non Operation System functionality). > > > > An example is the "all software library files must be {owned grouped > > chmod'd}" rules. In such a case, the RHEL STIG *should* cover > > RHEL-provided > > library files under /usr/lib/{kernel systemd} directories, but not > > /usr/lib/3rd_party_app. > > > > Part of this descoping is the reflection that DISA's Application SRG > > [0][1] has been maturing. 3rd party software deployments, such as java > > middleware servers, should be covered by the Application SRG requirements. > > Not lumped into the Operating System STIG. > > > > RHEL7 may ship SELinux booleans for 3rd party software (e.g. > > httpd_can_connect_mythtv, or ftpd_connect_db) however their existence > > doesn't correlate to inclusion in the *operating system* STIG. The above > > booleans would appropriately placed in the Apache STIG or FTP Server STIG, > > while the RHEL STIG should ensure SELinux is enforcing and should have > > system-level booleans set (e.g. selinuxuser_execmod, > > use_ecryptfs_home_dirs, staff_exec_content). > > > > Your buckets idea is really great. Through the above lens, perhaps we can > > modify the groupings to something like below: > > > > - Operating System booleans that should be true > > - Operating System booleans that should be false > > - Non-OS booleans to include in 3rd party STIGs (helping DISA identify > > these will expedite their inclusion in things like Apache and JBoss > > STIGs). > > > > When writing XCCDF rules, their description tag will included cases where > > modification of setting may be called for. The OVAL side can use > > selinuxboolean_test to automate everything. Thankfully remediation is a > > bash 1-liner. > > > > [0] > > http://iasecontent.disa.mil/stigs/zip/Oct2015/U_Application_Server_V2R2_SR > > G.zip [1] > > http://iase.disa.mil/stigs/Documents/u_application_server_srg_v2_release_m > > emo.pdf > > > > -- > > SCAP Security Guide mailing list > > scap-security-guide(a)lists.fedorahosted.org > > > > https://lists.fedorahosted.org/admin/lists/scap-security-guide@lists.fedor > > ahosted.org https://github.com/OpenSCAP/scap-security-guide/

1 0

Re: [Open-scap] Template for file pattern match
by Jan Lieskovsky 05 Apr '16

05 Apr '16

Hello Pravin, thank you for checking with us (I have merged former Gautam's reply here too to have all the facts together). ----- Original Message ----- > From: "S, Gautam" <gautams(a)hpe.com> > To: open-scap-list(a)redhat.com > Sent: Monday, April 4, 2016 11:00:10 AM > Subject: Re: [Open-scap] Template for file pattern match > > Hi Pravin, > FWIW regarding the question of OVAL template for regex match - we track it under: [1] https://github.com/OpenSCAP/scap-security-guide/issues/1083 > This was something I also wondered about. However, there are some subtle > aspects that might affect this which I learned once I gave it a shot. > > 1) Not all pattern matches are same. Some search whether a pattern exists in > a file, some check for the absence, some check for the first match only, > some for all matches, some checks will involve external variables passed in > as well. At the very least, you will need </path/to/file>,<regex to > find>,<check_existence>,<instance> for basic ones. > > 2) You will have to keep the title, description and comments extremely > generic or else update them individually and they are generated. I found > this to be a huge deterrent to making everything into a template. There's this count_oval_objects.py utility: https://github.com/OpenSCAP/scap-security-guide/blob/master/shared/utils/co… from which output, when run, is clear the <textfilecontent54_object> is clearly the most used OVAL template e.g. for RHEL/6 content (I would assume the result will be the same for different products too). But like Gautam already clarified above, from the SSG experience there would be very small count of cases where the basic <ind:filepath> regex OVAL template would be sufficient. IOW if you would have a look at those existing OVAL checks already using <ind:textfilecontent54_object> often the final form of the OVAL ends up in the state where: * it's necessary to reference some external_variable, * it's necessary to have more rules (more objects), * it's necessary to have more states, * it's necessary to reference some OVAL rule dependency, * it's necessary for the regex to search the last occurrence of somestring in file etc etc. This is not to say the OVAL <ind:textfilecontent54_object> template wouldn't be useful for SSG. But there are these corner cases / additional requirements listed above, often leading to state when new <ind:textfilecontent54_object> OVAL check is written from scratch, rather than from template. The current state being in [1] we are discussing the possible form of such a template -- facing the need quickly to write dozen of simple OVAL checks checking some regex in some file, OVAL template might seem handy. But the expectation is to have the templated OVAL checks stable / unmodified across the SSG releases (so one day we could replace all those checks currently present in the repository with their dynamic [re]generation during the SSG package build). On the other hand, any corner case (external_variable, dependency on another OVAL etc) is diverging from common template (assuming very basic simple template). And therefore diverging from above approach (since in the moment the developer would end up writing such OVAL check from scratch just because the template is too simple and could not help them to speed up the OVAL checks development, I am not completely convinced it's worthy to investing the time into the design of such a template and MAINLY into investing the time into keeping such a template in working state). So I would say / IMHO the next step WRT to [1] would be to use the already included "count_oval_objects.py" utility and determine how many (in % compared to the whole count of <ind:textfilecontent54_object> OVAL checks already implemented for that product) of the <ind:textfilecontent54_object> OVAL checks have the simplest form, and how many (again in % compared to already having <ind:txtfilecontent54_object> OVAL checks for that product) is derived from the basic form due some reason (some corner case). Once we know this information, we can proceed further (if just to implement basic OVAL template, or have more templates for each of the subtle different cases [depending on another OVAL, using external variable etc.]). Hope this helps. Thank you && Regards, Jan -- Jan iankko Lieskovsky / Red Hat Security Technologies Team P.S.: There's SCAP Security Guide (SCAP content) dedicated mailing list too --> Cc'ed it too (so people can react to the topic). > > Thank you. > > Regards, > Gautam. > > > _______________________________________________ > Open-scap-list mailing list > Open-scap-list(a)redhat.com > https://www.redhat.com/mailman/listinfo/open-scap-list > --- > > Hi All, > > I tried searching the ssg project for a template that could find a pattern in a given file. I feel this would be one of > the most used templates where we need to find if a file contains an expression. This would be used for audit rules, sshd > configuration, password complexity configuration, password aging configuration, login configuration and probably many > others. We could create a CSV as below: > > > </path/to/file>,<regex to find> > > > Is someone working on it or have it or any idea how to do it? > > > Thanks and regards, > > Pravin Goyal > > > _______________________________________________ > Open-scap-list mailing list > Open-scap-list(a)redhat.com > https://www.redhat.com/mailman/listinfo/open-scap-list >

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

scap-security-guide April 2016