Re: The Machine Platform Great Controversy
Le 04/05/2020 à 17:35, Matej Tyc a écrit : > > Is there any other way how to satisfy everybody than to have a profile > for unprivileged containers, and specialized profiles for privileged > containers? Hello everybody, I find this discussion very intersting and I think because of the new raising ecosystem due to the massive use of containers, the way we are hardening system may be rethought (Or at least discussed) Recently, I read that article https://lwn.net/Articles/796700/ quoting Stéphane Graber from Ubuntu/LXC project and I think he told something very very intersting : "LXC and LXD are used to create "system containers", which run unmodified Linux distributions, not "application containers" like those created using Docker. The idea is that LXD users will use the same primitives as they would if they were running the distribution in a virtual machine (VM); that they are actually running them on a container is not meant to be visible to them." After reading that, for me the first question to ask about hardening is not if the container is privileged or unprivileged but how it is built and how it is executed. The article says (and I agree with it) that there are two categories of containers : - The application containers (Micro-service architecture) where the container is very minimalistic : Just the application,the dependencies, and nothing more (For example alpine based containers) - The system containers : If I sum up quickly, I would say it's a complete distribution with userland only (No kernel, no bootloader) For me, if we must think about SCAP profiles for containers, it's easier with system containers because create such a profile could be "just" tailoring a current profile removing everything not applicable (I mean rules about kernel and bootloader). I would say it's a "userland SCAP profile". For application containers, the approach is very diffent and with some of my colleagues we started to ask ourselves that question : Is it relevant to have an hardening profile on application containers which are very minimalistic ? As I told before, a well built application container is very minimalistic with normaly only the application running. So generally, this is no authentication layer, no network configuration, no sysctl to configure (generally done at the host level). My point of view, is that when you try to reduce/tailor a SCAP profile for such a container, there is only very few rules to apply. Example: Why hardening a PAM stack which is never used or even not installed ? Of course, it's just a first analysis with additional questions to answer : What about if you add privilege/unprivileged status and what about container who are between these two worlds ? (But for me the answer can be simple : The container is not well built). So maybe a first approach would be to focus on these "system containers" and maybe try to define some guidelines for the "application containers" ? My two cents ! Regards, Olivier Bonhomme -- L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel antivirus Avast. https://www.avast.com/antivirus ___ scap-security-guide mailing list -- scap-security-guide@lists.fedorahosted.org To unsubscribe send an email to scap-security-guide-le...@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.fedorahosted.org
Jenkins out of order
Hello everybody, There is a 502 Error on the Jenkins. Is that normal ? Regards, Olivier Bonhomme ___ scap-security-guide mailing list -- scap-security-guide@lists.fedorahosted.org To unsubscribe send an email to scap-security-guide-le...@lists.fedorahosted.org
Re: Ansible vs bash fixup scripts
Le 12/12/2017 à 19:09, Marek Haicman a écrit : > Hi Chuck, > it's definitely not like we are moving away from bash remediations > towards Ansible. As the remediation during scan is still bash-only, bash > is still important part of SSG. It's true that in upstream SSG we tried > to get Ansible to parity with bash, and it's even true that in some > cases Ansible remediation is easier to make, thus is implemented first. > > Basically - it's more about resources available, and not much about our > agenda. And with Ansible remediations on par with bash, we should be > able to fix both. > > Regards, > Marek > Hello Marek, As a newbie into the SSG community, there are things about fixes that are not very clear to me. You said that remediations are bash-only. However, when I look at the DS/XCCDF+OVAL files generated, I can see that for some rules, there are only ansible fixes and no bash fixes. And when I did some tests on my side, I realized that some remediations were in error because ansible wasn't installed or because I had an old version of ansible. SSG guys seems to say there is always a bash fallback as it has been discussed here : https://github.com/OpenSCAP/scap-security-guide/issues/2467. But when I see the generated file, I wonder how it can be possible. So is it possible to clarify the following questions : - Is ansible mandatory for some remediations ? - If yes, is it possible to provide the minimum version needed for applying the remediations into a correct way. - Does oscap really fallback to bash when ansible fails ? If yes, how does it work ? Thanks again for the answers. Regards, Olivier Bonhomme ___ scap-security-guide mailing list -- scap-security-guide@lists.fedorahosted.org To unsubscribe send an email to scap-security-guide-le...@lists.fedorahosted.org
Re: Issues for writing a remediation
Le 02/01/2018 à 20:39, Shawn Wells a écrit : > > > On 1/2/18 6:58 AM, Marek Haicman wrote: >> Hello Olivier, >> great to hear that you were able to solve the issue! Response times >> are slower here over the holidays... >> >> For the cpe problem, I suggest to use datastreams. It has CPE bundled >> within, so it works out-of-the-box so to say. It wasn't so important >> in the past, where we used only standard CPEs, as these are also >> shipped as part of oscap. But now, as we included support for >> containerized environments (using SSG-based cpe:/a:machine and >> cpe:/a:container), using default will show lots of stuff not applicable. >> >> And I have checked the patch and merged it, thank you! >> Marek > > Thanks Oliver for sending your notes to the mailing list even if you > felt if you were just talking to yourself over the holidays :) > > As a community we haven't focused much on developing a good > FAQ/knowledge base/something that archives commonly asked questions. > There's been some talk about potentially using stack overflow for this. > Would that be better than keeping a GitHub wiki page? > > IMHO it would, because of the amount of developers that try stack > overflow first. > > On the other side, most people are subscribed to the mailing list and > may not actively monitor stack overflow... Hello Shawn, Marek and the community, First of all, thanks for having accept my first patch into the scap-security-guide master branch. I will try to provide other OVAL checks and associated remediations for missing STIG rules in the next day/weeks. In order to answer your questions, as a total newbie into the SSG community so I guess with a complete external point of view, I think the Github wiki page is the good place to add the developer rules. When I tried to write my first check, the documentation I read was the developer guide. In my opinion, I think it would be nice to add things into that documentation. Considering my small experience, I would add for example the advices provided by Marek like using the DS file in stead of the XCCDF. In a more general way, what about adding a chapter telling the commands to use for validating our new checks and remediations. For me, there is already interesting stuff in the developper guide. For me, it was a good starting point for doing my first contributions. Maybe I am old school but compared to SO, I prefer the documentation on the Github pages because it's a centralized place where we can find interesting information. And added to that, the mailing list is also a good channel for additional support because it's also centralized with an easy way to search for data using the archives. Here are my 2 cents. Regards, Olivier ___ scap-security-guide mailing list -- scap-security-guide@lists.fedorahosted.org To unsubscribe send an email to scap-security-guide-le...@lists.fedorahosted.org
Re: Issues for writing a remediation
Le 26/12/2017 à 17:53, Olivier BONHOMME a écrit : > > Important precision : I use CentOS and not RHEL. Hello again, After more investigation, I think I found the problem. I didn't include the CPE dictionnary when executing the remdiation so most of the remediations were considered as not applicable ! When using --cpe ssg-rhel7-cpe-dictionary.xml, the remediations including the one I just wrote, is selected and applied. Regards, Olivier Bonhomme ___ scap-security-guide mailing list -- scap-security-guide@lists.fedorahosted.org To unsubscribe send an email to scap-security-guide-le...@lists.fedorahosted.org
Re: Issues for writing a remediation
Le 26/12/2017 à 17:15, Olivier BONHOMME a écrit : > Hello everybody, > > I'm trying to write my first OVAL check and the associated remediation > script. For my first try, I decided to test with a simple check > https://github.com/OpenSCAP/scap-security-guide/issues/1861. > > I think, I succedeed writing the OVAL check but I have big issues with > the remediation : When I execute the remediate command using the results > file from the eval command, my remediation is never selected. > > After some investigations, I realized that the fix wasn't generated into > the results file. Hello again, I have to make a quick update. I realized that I wasn't using the correct results file :(. Sorry for the noise about that terrible mistake ! So there is some progress but now I have now an issue that I really don't understand. When using the (correct) results file with the command oscap remediate, it seems that the remediation I wrote is never selected nor even analyzed : I enabled vebose mode with the DEVEL level and I can't see anything about the remediation i wrote in the stacktrace. Does anybody have an idea why my remediation is not selected ? I updated the GIST with the correct results file. Important precision : I use CentOS and not RHEL. Thanks again for your help Regards, Olivier Bonhomme ___ scap-security-guide mailing list -- scap-security-guide@lists.fedorahosted.org To unsubscribe send an email to scap-security-guide-le...@lists.fedorahosted.org
Issues for writing a remediation
Hello everybody, I'm trying to write my first OVAL check and the associated remediation script. For my first try, I decided to test with a simple check https://github.com/OpenSCAP/scap-security-guide/issues/1861. I think, I succedeed writing the OVAL check but I have big issues with the remediation : When I execute the remediate command using the results file from the eval command, my remediation is never selected. After some investigations, I realized that the fix wasn't generated into the results file. I must admit I'm a little bit lost and I don't understand why my remediation fix is not generated into the results file. That's why i'm looking for some help in order to understand how to investigate for resolving that issue (Which i'm sure is a newbie thing) I put my files on the following GIST : https://gist.github.com/ptitoliv/fe10d4d37049801b60c98b255c7a6d66 Thanks for your help. Regards, Olivier Bonhomme ___ scap-security-guide mailing list -- scap-security-guide@lists.fedorahosted.org To unsubscribe send an email to scap-security-guide-le...@lists.fedorahosted.org
Re: Question about missing OVAL checks
Le 21/11/2017 à 23:46, Gabe Alford a écrit : > So I have several questions about these kind of checks : > - Is it possible to implement them using OVAL with an oval rule which > can do result command checks ? > > > Yes it is. Hello Gabe, That's great to read.Honestly, I am a little bit lost with the OVAL format but I try to learn and I wasn't sure such a thing was possible. When looking into OVAL spec, I found textfilecontent rule but nothing for parsing a command result. If you have an entry point for doing such a check into the OVAL language spec, I would be happy to try to write the check :) > - Is it possible to implement these checks using another language. I > heard about SCE but it seems to be only for OpenSCAP. > > > You can definitely do that, but it won't be taken advantage of by Nessus > and other scanners that use SCAP Ok. It's what I understood but it can be a good workaround in some cases. > The plan is that these checks will have OVAL and remediation scripts in > the future. > It is really a matter of time, effort, and resources. There are tickets > already open for each of them already. > You can see them at > https://github.com/OpenSCAP/scap-security-guide/projects/7 > Getting the XCCDF into SSG is the easy part. The rest takes time. > So if you or anyone is willing and able to help get us there, PRs are > welcome. :) It would be a pleasure to help the project but before submitting PR, it's important for me to know if it is possible to do things or not :) Thanks Regards, Olivier Bonhomme ___ scap-security-guide mailing list -- scap-security-guide@lists.fedorahosted.org To unsubscribe send an email to scap-security-guide-le...@lists.fedorahosted.org
Question about missing OVAL checks
Hello everybody, I'm still working in checking how many STIG rules have implemented checks in OpenSCAP profiles. When executing oscap eval command, I identified that there are several checks in status notchecked. After some investigation, I identified that there was no oval checks availables for these rules. After reading some documentation about OVAL language, I was wondering if it will be possible to implement a check for these rules. For example, for the rule "homedirs must exist", the check consists in doing a "pwchk -r" in order to identify if the homedirs exists or not. With a shell script I know how to do that but in OVAL, i'm not sure if it is possible. So I have several questions about these kind of checks : - Is it possible to implement them using OVAL with an oval rule which can do result command checks ? - Is it possible to implement these checks using another language. I heard about SCE but it seems to be only for OpenSCAP. - Will these checks stay manual checks with notchecked status on SSG ? Thanks for your answers. Regards, Olivier Bonhomme ___ scap-security-guide mailing list -- scap-security-guide@lists.fedorahosted.org To unsubscribe send an email to scap-security-guide-le...@lists.fedorahosted.org
Re: stig-overlays.xml usage
On Thu, Nov 16, 2017 at 09:59:02AM -0700, Gabe Alford wrote: Hello Gabe, > This is expected behaviour. A separate CentOS STIG has to be created and > exist for a > stig_overlay.xml to be created and exist.CentOS *does not* meet STIG > compliance > equirements nor do Red Hat certificationstransfer or follow down to the > derivatives. The > CentOS project also echos this statement at > https://wiki.centos.org/FAQ/General#head-4b2dd1ea6dcc1243d6e3886dc3e5d1ebb252c194 > For this reason, all RHEL identifiers have been stripped out of the > derivative profiles. > > You should not have to check coverage of the CentOS profile as the CentOS > profile > is almost an exact copy of the RHEL profile just with some changes to work > on CentOS. I understand your point and the fact that CentOS profile is a copy of the RHEL profile but with a different CPE. But actually, for now I'm not looking for a certification and I'm fully aware that CentOS goal is not to provide certified things. In my mind actually, it sounds more like applying the RHEL profile on a CentOS just for having a status against STIG but not a certification at all. It's just in order to have a general idea of how my CentOS is secured (or not) against a known guide. I know for example that FIPS rule will always fail and I'm okay with that but for most of others rules, I expect the same behaviour between an RHEL and a CentOS. For example, rules about paritionning are applicable in the same way on CentOS or RHEL. That's why my action plan was, how is the CentOS guide against STIG in order to see if I have rules to write by myself in order to have a relevant OpenSCAP profile (and of course contribute to the SSG project :)). Correct me if i'm wrong but i don't think it's in the project roadmap to have a dedicated SSG profile for CentOS which is standalone and not a derivative from the RHEL one. > > Also, some RHEL checks/rules in the STIG are duplicates of others, or they > are no longer valid for > the latest release. Any of duplicated/outdated checks/rules have been > remove/updated (as much > as feasibly possible) for the latest release. So if there are missing RHEL > identifiers, it is usually > because of duplication or new content that has yet to be added. Does that mean that actually, the SSG team considers there is a full coverage against RHEL STIG V1.2 ? Regards, Olivier Bonhomme > ___ > scap-security-guide mailing list -- scap-security-guide@lists.fedorahosted.org > To unsubscribe send an email to > scap-security-guide-le...@lists.fedorahosted.org ___ scap-security-guide mailing list -- scap-security-guide@lists.fedorahosted.org To unsubscribe send an email to scap-security-guide-le...@lists.fedorahosted.org
Re: stig-overlays.xml usage
On Wed, Nov 15, 2017 at 05:52:35PM +0100, Watson Yuuma Sato wrote: > On 15/11/17 13:15, Olivier BONHOMME wrote: > > Dear OpenScap community, > > > > I'm currently working for my company on checking the RHEL 7 SSG profile > > (0.1.36 version) coverage against STIG 1.3 release. > > > > While browsing the 0.1.36 release, I discovered the stig-overlays.xml which > > shows the matching between SSG rule and STIG rule. > > > > Can anybody confirm that I can use that file in order to check the coverage > > rate of the SSG profile ? > Hello, Olivier. > > I'd say yes, as the stig_overlay maps Rules in STIG to Rules in SSG. > Rules that don't map to any Rule in SSG will have ruleid="". > > Last time stig_overlay.xml was updated in upstream was around 8 months > ago, so the version there probably isn't STIG 1.3. And unfortunately I > couldn't find to witch version it corresponds. > > To generate an updated stig_overlays.xml file, please refer to our > Developer Guide [1]. > > [1] > https://github.com/OpenSCAP/scap-security-guide/blob/master/docs/manual/developer_guide.adoc#stig-overlay-content Hello Watson, Thanks for that clear answer. I followed the documentation from the dev guide and the result is that there is only two rules which are not matched against the STIG v1.3. So congrats to the team for such a good job ! I also have a more "senstive" question. It's about the same task but with CentOS profile but when I used the create-stig-overlay.py script, all the rules were tagged . After some investigations, I identified that when the derivative distribution generation is enabled, the matching with STIG is removed which is bad for doing a coverage check for the CentOS profile. I fully understand the reason provided in the commit message when it has been enabled but I would be curious if it would be possible to let the RHEL stigid rules in a very unofficial way adding a CMake option ? Regards, Olivier Bonhomme ___ scap-security-guide mailing list -- scap-security-guide@lists.fedorahosted.org To unsubscribe send an email to scap-security-guide-le...@lists.fedorahosted.org
stig-overlays.xml usage
Dear OpenScap community, I'm currently working for my company on checking the RHEL 7 SSG profile (0.1.36 version) coverage against STIG 1.3 release. While browsing the 0.1.36 release, I discovered the stig-overlays.xml which shows the matching between SSG rule and STIG rule. Can anybody confirm that I can use that file in order to check the coverage rate of the SSG profile ? Thanks for your answers. Regards, Olivier Bonhomme ___ scap-security-guide mailing list -- scap-security-guide@lists.fedorahosted.org To unsubscribe send an email to scap-security-guide-le...@lists.fedorahosted.org
Re: screen vs vlock
On Tue, Nov 14, 2017 at 10:27:04AM -0500, Trevor Vaughan wrote: > Steve, > > So, would tmux be a valid alternative? It can do the same as screen in that > respect. Hello, I agree with that. For me screen is almost dead and buggy. Tmux would be an appreciable and modern alternative. Regards, Olivier Bonhomme ___ scap-security-guide mailing list -- scap-security-guide@lists.fedorahosted.org To unsubscribe send an email to scap-security-guide-le...@lists.fedorahosted.org
Re: DISA Coverage Rate for RHEL7
On Tue, Oct 04, 2016 at 10:15:04PM -0400, Shawn Wells wrote: > > > On 10/4/16 4:51 PM, Olivier BONHOMME wrote: > > Le 04/10/2016 à 16:26, Gabe Alford a écrit : > >> > Hello, > >> > > >> > Both the DISA SRGs and STIGIDs are added to the applicable RHEL/7 > >> > content. > >> > You can verify this by either `grep -rni 'stigid\|srg' > >> > RHEL/7/input/xccdf`, or `grep 'SRG\|RHEL-07' ssg-rhel7-xccdf.xml` > >> > Also, when a report is generated with the oscap --report option, the SRG > >> > and STIGID identifiers can be viewed in the report. > >> > > >> > Gabe > > Hello Gabe, > > > > Thanks for your answer. So I tried to write a little script which takes > > the XCCDF file downloaded from DISA site and try to find the matching > > rules into the RHEL/7/input/xccdf/*.xml files. > > > > For now, I justed focused on the stigid identifiers not on the SGR ones. > > Actually the result is that I have 97 rules matching with the DISA XCCDF > > upstream file ? > > > > Do you think it is a relevant number ? > > > > Browsing the OPENSCAP XCCDF files I realised that there were some DISA > > rules that maybe already covered but there is not actually a stigid > > attributed attached to these rules. > > > > Do you think it can be relevant if I try to complete OPENSCAP XCCDF > > files with missing stigid if matches can be found against the DISA XCCDF > > upstream file ? Or is it definitely not the process ? > > > Since you appear to be working from source: `make tables` is your > friend :) > > It'll generate HTML mapping tables, such as these: > > "What rules map to a given OS SRG?" > http://people.redhat.com/swells/scap-security-guide/RHEL/7/output/table-rhel7-srgmap.html > > "What NIST 800-53 controls are satisfied, and how?" > http://people.redhat.com/swells/scap-security-guide/RHEL/7/output/table-rhel7-nistrefs.html Hello Shawn, Thanks for these two links but to be honest I'm a little bit confused about the available informations. That's why I have several questions in order to improve my understanding: - On the srgmap table, does the "rules mapped" column refer to the OpenSCAP profile ? - On the srgmap table, are all the SRG rules from the DISA listed even the one without a matching test ? Actually, as I told on my first mail, I try to have a status about the DISA STIG rules who are covered by OpenSCAP profile and above all the rules who are not covered. Referring to my last question, I have another question : I thought that in stead of considering the general SRG rules, it should be more relevant considering the derivated RHEL-07-XX which are product specific rules. I found this table on the output directory : http://people.redhat.com/swells/scap-security-guide/RHEL/7/output/table-rhel7-stig-manual.html. Could it be relevant to put the OpenSCAP test in front of each RHEL-07-XX in order to have a coverage rate against the DISA product specific rules ?. I thought that mapping was done with the stig_auxiliary file but actually the RHEL rules specified into that XML files are for RHEL6 and not for RHEL7. Is it normal that there are RHEL-06-X rules on that file for the RHEL7 input ? It seems a little bit strange for me. I also looked the disa-os-srg-v1r1.xml file but the rule are not named like on the last file provided on the DISA site : rules are in the format V-XX in stead of RHEL-07-XX. Is it normal ? Thanks for your answers Regards, Olivier Bonhomme ___ scap-security-guide mailing list -- scap-security-guide@lists.fedorahosted.org To unsubscribe send an email to scap-security-guide-le...@lists.fedorahosted.org
Re: DISA Coverage Rate for RHEL7
Le 04/10/2016 à 16:26, Gabe Alford a écrit : > Hello, > > Both the DISA SRGs and STIGIDs are added to the applicable RHEL/7 content. > You can verify this by either `grep -rni 'stigid\|srg' > RHEL/7/input/xccdf`, or `grep 'SRG\|RHEL-07' ssg-rhel7-xccdf.xml` > Also, when a report is generated with the oscap --report option, the SRG > and STIGID identifiers can be viewed in the report. > > Gabe Hello Gabe, Thanks for your answer. So I tried to write a little script which takes the XCCDF file downloaded from DISA site and try to find the matching rules into the RHEL/7/input/xccdf/*.xml files. For now, I justed focused on the stigid identifiers not on the SGR ones. Actually the result is that I have 97 rules matching with the DISA XCCDF upstream file ? Do you think it is a relevant number ? Browsing the OPENSCAP XCCDF files I realised that there were some DISA rules that maybe already covered but there is not actually a stigid attributed attached to these rules. Do you think it can be relevant if I try to complete OPENSCAP XCCDF files with missing stigid if matches can be found against the DISA XCCDF upstream file ? Or is it definitely not the process ? Thanks for your answer. Regards, Olivier Bonhomme ___ scap-security-guide mailing list -- scap-security-guide@lists.fedorahosted.org To unsubscribe send an email to scap-security-guide-le...@lists.fedorahosted.org
