Learn more about these different git repos.
Other Git URLs
Based on the wiki page: https://fedorahosted.org/sssd/wiki/SecuritySensitiveOptions
We also need to provide the content itself, when the SCAP team provides some HOWTO.
This is driven by SCAP team, we can file to 1.14 and wait how long it takes them to produce the howto..we can always move this ticket to another milestone.
Fields changed
rhbz: => 0
milestone: NEEDS_TRIAGE => SSSD 1.14 alpha
Here is an outline of what needs to happen in order to bring sssd hardening/configuration guideline to SCAP-Security-Guide project in form of SCAP content.
1a) Understand the logical structure (tree) of existin SCAP-Security-Guide for RHEL7. - review http://static.open-scap.org/ssg-guides/ssg-rhel7-guide-ospp-rhel7-server.html 1b) Design structure for SSSD rules - Does it make sense to create new group SSSD in Services section? (Note rest of the tutorial assumes that this makes sense) - Does it make sense to spread out SSSD rules to other groups?
SSSD
- http://www.open-scap.org/security-policies/scap-security-guide/ - https://github.com/OpenSCAP/scap-security-guide/wiki/Contributing - https://github.com/OpenSCAP/scap-security-guide/wiki/Building-from-Source - Do not spend too much time here, get hands dirty early! - Full documentation on OVAL language can be found at http://oval.mitre.org/language/version5.11/index.html#new (click on html links there)
- if applicable - example: https://github.com/OpenSCAP/scap-security-guide/blob/master/RHEL/7/input/xccdf/services/ssh.xml - group will be empty at this point (no Values no Rules) just metadata - don't forgot to add the new file into https://github.com/OpenSCAP/scap-security-guide/blob/master/RHEL/7/input/guide.xslt - optionally add your new group to the profile selection like: https://github.com/OpenSCAP/scap-security-guide/blob/master/RHEL/7/input/profiles/pci-dss.xml -- you may want to include the group in mutiple profiles - first commit done
- for each on https://fedorahosted.org/sssd/wiki/SecuritySensitiveOptions you will need: - XCCDF part: Edit file that group file introduced by previous step. Include new Rule element with metadata - OVAL part: For most SSSD settings, I think you will need filecontent_test. There are many examples of such use in the repo. See for instance: https://github.com/OpenSCAP/scap-security-guide/blob/master/shared/oval/accounts_password_pam_pwquality.xml - (optional) Remediation instructions. These are simple shell scripts. Example https://github.com/OpenSCAP/scap-security-guide/blob/master/shared/remediations/bash/accounts_passwords_pam_faillock_unlock_time.sh - optionally add your new group to the profile selection like: https://github.com/OpenSCAP/scap-security-guide/blob/master/RHEL/7/input/profiles/pci-dss.xml -- you may want to include the group in mutiple profiles - There is good and simple example of whole contribution bundle: https://github.com/OpenSCAP/scap-security-guide/pull/855
make clean make make validate make dist make rpm
When it builds your new rule/group will be present in RHEL/7/dist/content/ssg-rhel7-ds.xml.
6a) If you have include rule&group in the profile above you can run whole scan as the end-user will do:
# oscap xccdf eval --profile PROFILE_YOU_EDITED --report ~/myreport.html --results-arf ~/detailed_results.arf.xml RHEL/7/dist/content/ssg-rhel7-ds.xml
6b) Test just the oval. - you need to find ID of your newly added OVAL check - this is quicker to 5a) and close to what end-user does - make sure you understand what true/false means in this scenario
# oscap oval eval --id OVAL-DEFINITION-ID-OF-THE-NEW-DEFINITION RHEL/7/dist/content/ssg-rhel7-ds.xml
6c) Run just the evaluation of the profile you have created - not sure how much used this is
./testcheck.py package_ntpdate_removed.xml
SSG upstream will review your patches. Just make sure that basic build tests pass. We are lurking on #openscap on Freenode and on https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
_comment0: Here is an outline of what needs to happen in order to bring sssd hardening/configuration guideline to SCAP-Security-Guide project in form of SCAP content.
1) Design logical structure 1a) Understand the logical structure (tree) of existin SCAP-Security-Guide for RHEL7. - review http://static.open-scap.org/ssg-guides/ssg-rhel7-guide-ospp-rhel7-server.html 1b) Design structure for SSSD rules - Does it make sense to create new group SSSD in Services section? (Note rest of the tutorial assumes that this makes sense) - Does it make sense to spread out SSSD rules to other groups?
2) Review the basics of contribution to SSG - http://www.open-scap.org/security-policies/scap-security-guide/ - https://github.com/OpenSCAP/scap-security-guide/wiki/Contributing - https://github.com/OpenSCAP/scap-security-guide/wiki/Building-from-Source - Do not spend too much time here, get hands dirty early! - Full documentation on OVAL language can be found at http://oval.mitre.org/language/version5.11/index.html#new (click on html links there)
3) Create the group within SSG. - if applicable - example: https://github.com/OpenSCAP/scap-security-guide/blob/master/RHEL/7/input/xccdf/services/ssh.xml - group will be empty at this point (no Values no Rules) just metadata - don't forgot to add the new file into https://github.com/OpenSCAP/scap-security-guide/blob/master/RHEL/7/input/guide.xslt - optionally add your new group to the profile selection like: https://github.com/OpenSCAP/scap-security-guide/blob/master/RHEL/7/input/profiles/pci-dss.xml -- you may want to include the group in mutiple profiles - first commit done
4) Create all the rules needed for SSSD configuration ( https://fedorahosted.org/sssd/wiki/SecuritySensitiveOptions ). For each one you will need: - XCCDF part: Edit file that group file introduced by previous step. Include new Rule element with metadata - OVAL part: For most SSSD settings, I think you will need filecontent_test. There are many examples of such use in the repo. See for instance: https://github.com/OpenSCAP/scap-security-guide/blob/master/shared/oval/accounts_password_pam_pwquality.xml - (optional) Remediation instructions. These are simple shell scripts. Example https://github.com/OpenSCAP/scap-security-guide/blob/master/shared/remediations/bash/accounts_passwords_pam_faillock_unlock_time.sh - optionally add your new group to the profile selection like: https://github.com/OpenSCAP/scap-security-guide/blob/master/RHEL/7/input/profiles/pci-dss.xml -- you may want to include the group in mutiple profiles - There is good and simple example of whole contribution bundle: https://github.com/OpenSCAP/scap-security-guide/pull/855
4) Commit your changes and test you do not break build {{{ make clean make make validate make dist make rpm }}} When it builds your new rule/group will be present in RHEL/7/dist/content/ssg-rhel7-ds.xml.
5) Test your own scenario. Three options 5a) If you have include rule&group in the profile above you can run whole scan as the end-user will do: {{{
}}} 5b) Test just the oval. - you need to find ID of your newly added OVAL check - this is quicker to 5a) and close to what end-user does - make sure you understand what true/false means in this scenario {{{
}}}
5c) Run just the evaluation of the profile you have created - not sure how much used this is {{{ ./testcheck.py package_ntpdate_removed.xml }}}
6) You can make this as iterative as you wish. SSG upstream will review your patches. Just make sure that basic build tests pass. We are lurking on #openscap on Freenode and on
=> 1447339612048294 _comment1: Here is an outline of what needs to happen in order to bring sssd hardening/configuration guideline to SCAP-Security-Guide project in form of SCAP content.
6) You can make this as iterative as you wish. SSG upstream will review your patches. Just make sure that basic build tests pass. We are lurking on #openscap on Freenode and on https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
=> 1447339949857202
owner: somebody => jhrozek
This has been on a backburner for some time, we need to get back to this work once we stabilize this release.
milestone: SSSD 1.14 alpha => SSSD 1.14 backlog
Since the 1.14 branch is transitioning into maintenance mode and new functionality is being developed in master which will become 1.15 eventually, I'm mass-moving tickets from the 1.14 backlog milestone to the "Future releases" milestone.
milestone: SSSD 1.14 backlog => SSSD Future releases (no date set yet)
Metadata Update from @jhrozek: - Issue assigned to jhrozek - Issue set to the milestone: SSSD Future releases (no date set yet)
Metadata Update from @jhrozek: - Assignee reset
Metadata Update from @thalman: - Custom field design_review reset (from 0) - Custom field mark reset (from 0) - Custom field patch reset (from 0) - Custom field review reset (from 0) - Custom field sensitive reset (from 0) - Custom field testsupdated reset (from 0) - Issue close_status updated to: None - Issue tagged with: Canditate to close
Thank you for taking time to submit this request for SSSD. Unfortunately this issue was not given priority and the team lacks the capacity to work on it at this time.
Given that we are unable to fulfill this request I am closing the issue as wontfix.
If the issue still persist on recent SSSD you can request re-consideration of this decision by reopening this issue. Please provide additional technical details about its importance to you.
Thank you for understanding.
Metadata Update from @pbrezina: - Issue close_status updated to: wontfix - Issue status updated to: Closed (was: Open)
SSSD is moving from Pagure to Github. This means that new issues and pull requests will be accepted only in SSSD's github repository.
This issue has been cloned to Github and is available here: - https://github.com/SSSD/sssd/issues/3888
If you want to receive further updates on the issue, please navigate to the github issue and click on subscribe button.
subscribe
Thank you for understanding. We apologize for all inconvenience.
Login to comment on this ticket.