WIP: Implement CIS Level 1 for Ubuntu 20.04 #6416
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
Can one of the admins verify this patch? |
openshift-ci-robot
added
the
do-not-merge/work-in-progress
|
Can one of the admins verify this patch? |
|
Hi @Caligatio. Thanks for your PR. I'm waiting for a ComplianceAsCode member to verify that this patch is reasonable to test. If it is, they should reply with Once the patch is verified, the new status will be reflected by the I understand the commands that are listed here. Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
Caligatio
changed the title
|
@Caligatio I took the liberty to update the conflicts and to change the code so it now builds correctly. Overall the pull request looks good. Please take a look at the individual commits to understad the changes that were required. |
|
Looks good to me. I stalled a bit on porting more rules but hope to get back into it later this month. More of a note to myself, I'll have to fiddle a bit with |
|
@openscap-ci test this please |
|
Changes identified: Show detailsProfile cis_level1_server on ubuntu2004: Recommended tests to execute: |
yuumasato
reviewed
Dec 15, 2020
| cis@rhel8: 1.1.2 | ||
| cis@ubuntu1804: 1.1.2 | ||
| cis@ubuntu2004: 1.1.2 | ||
| cis: 1.1.2 |
There was a problem hiding this comment.
Tempting as it may be to unify these references, I lean towards not merging them.
There is no guarantee that CIS profiles added in the future will match these reference numbers.
There was a problem hiding this comment.
Wouldn't it make sense to unify the references and then just have the outliers be overrides? This is done is many, many places with references defaulting to RHEL and then @ubuntu-whatever being overrides.
There was a problem hiding this comment.
Yes, it does make sense to unify references until there are deviations, and they should always be unified unless it deviates. Deviations are exceptions not the rule.
There was a problem hiding this comment.
I mainly would like to avoid inconsistencies.
If the reference is not product specific it will show up in every product, even for products that don't have a CIS profile implemented.
Another point is that when adding a new CIS profile to a product, one will have to process every rule with a cis reference in it, either to accept the reference or remove it.
There was a problem hiding this comment.
This is done is many, many places with references defaulting to RHEL and then @ubuntu-whatever being overrides.
Well, yes, maybe it would not be a problem to unify them.
Deviations are exceptions not the rule.
When it comes to sharing descriptions, checks and fixes, it makes sense. A lot of code and practices is shared among distros.
The CIS references are just numbers. But I know that CIS benchmarks have some kind of hierarchy and relationship between them, So unifying them may not be a big problem, and my concerns are not relevant.
There was a problem hiding this comment.
I'm fine with either, but the draft is a living specification and it often depends on what version of a particular OS spec you're looking at (e.g., v1.1.0 of the Ubuntu 20.04 spec changes a number of section numbers than v1.0.0).
My concern is someone going ahead and changing the cis reference because, e.g., RHEL changed, but e.g., Ubuntu didn't, without looking at all products the rule currently applies to.
If we make deviations the exception, not the rule, we need to make sure updating the default involves more cross-checking. :-)
My 2c.
There was a problem hiding this comment.
@cipherboy So you are slightly in favor of defaulting to specific cis references then?
There was a problem hiding this comment.
Yeah, on the other side as an intern back in '18 I definitely would've preferred a single cis reference with OS-specific overrides when necessary.
But now having seen more of the CIS process, I don't think that is correct, as helpful as it would be ;-)
Each OS needs to go through the CIS process and have a spec published before a CIS reference technically becomes valid for it. So having no default cis reference makes it explicit and obvious that this has been done for a given OS/rule combination.
cipherboy
approved these changes
Mar 19, 2021
There was a problem hiding this comment.
I think this is a good start. Obviously needs to be rebased on top of latest HEAD. I think I agree with @yuumasato's original assessment that its better to leave CIS references alone (and separated out per target). This way too, CIS references don't appear on an OS that lacks a CIS benchmark.
Other than that, there's more rules that could be added into later sections (that already exist in CaC), but this is mergeable as-is and later PRs can always add more rules incrementally.
Looks great, thanks!
| @@ -16,8 +16,7 @@ identifiers: | |||
| cce@rhel8: CCE-83475-4 | |||
|
|
|||
| references: | |||
| cis@rhel7: 6.1.8 | |||
| cis@rhel8: 6.1.8 | |||
| cis: 6.1.8 | |||
There was a problem hiding this comment.
Since other section 6.1.x rules differ between RHEL and Ubuntu, I might suggest we keep these two separate for the time being.
| @@ -16,8 +16,7 @@ identifiers: | |||
| cce@rhel8: CCE-83324-4 | |||
|
|
|||
| references: | |||
| cis@rhel7: 6.1.6 | |||
| cis@rhel8: 6.1.6 | |||
| cis: 6.1.6 | |||
| @@ -22,8 +22,7 @@ identifiers: | |||
| cce@rhel8: CCE-83415-0 | |||
|
|
|||
| references: | |||
| cis@rhel7: 6.1.7 | |||
| cis@rhel8: 6.1.7 | |||
| cis: 6.1.7 | |||
| @@ -16,8 +16,7 @@ identifiers: | |||
| cce@rhel8: CCE-83473-9 | |||
|
|
|||
| references: | |||
| cis@rhel7: 6.1.8 | |||
| cis@rhel8: 6.1.8 | |||
| cis: 6.1.8 | |||
| cis@rhel8: 1.1.1.1 | ||
| cis@sle15: 1.1.1.1 | ||
| cis@ubuntu1804: 1.1.1.1 | ||
| cis: 1.1.1.1 |
There was a problem hiding this comment.
cramfs remains the same, but 1.1.1.x change between 18.04 and 20.04, so I'm inclined to leave these separate.
| - mount_option_tmp_noexec | ||
|
|
||
| ### 1.1.6 Ensure /dev/shm is configured (Automated) | ||
| # Skip due to being handled by systemd and ensured by follow-on tests |
There was a problem hiding this comment.
Yeah, it'd be nice to have an entry here for /dev/shm (and also /tmp) to have it configured in systemd correctly, rather than adding /etc/fstab changes.
| # Skip due to being Level 2 | ||
|
|
||
| ### 1.1.11 Ensure separate partition exists for /var/tmp (Automated) | ||
| # This is a Level 2 test but is needed for 1.1.12-14 |
There was a problem hiding this comment.
I filed ticket#12460 at CIS for tracking this.
| ### 1.3.3 Ensure sudo log file exists (Automated) | ||
|
|
||
| ## 1.4 Filesystem Integrity Checking ## | ||
| ### 1.4.1 Ensure AIDE is installed (Automated) |
There was a problem hiding this comment.
Just in case you're interested, I think package_aide_installed together with aide_build_database would work here.
Though, perhaps aide_build_database should be updated to what's in the current guidance:
# aideinit # mv /var/lib/aide/aide.db.new /var/lib/aide/aide.db
| ## 1.4 Filesystem Integrity Checking ## | ||
| ### 1.4.1 Ensure AIDE is installed (Automated) | ||
|
|
||
| ### 1.4.2 Ensure filesystem integrity is regularly checked (Automated) |
There was a problem hiding this comment.
Same as above; perhaps best to leave as CIS benchmark allows either cron or systemd timers, but we do have aide_periodic_cron_checking.
| ### 1.4.2 Ensure filesystem integrity is regularly checked (Automated) | ||
|
|
||
| ## 1.5 Secure Boot Settings ## | ||
| ### 1.5.1 Ensure bootloader password is set (Automated) |
There was a problem hiding this comment.
For future reference, there are some bootloader-grub2 tests available as well.
|
@Caligatio: PR needs rebase. Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
cipherboy
added a commit
to cipherboy/scap-security-guide
that referenced
this pull request
Apr 21, 2021
Per discussion on ComplianceAsCode#6416, I don't think it is generally valid to have a unqualified (by product) CIS reference identifier. While there is a hierarchy to the CIS benchmarks (from General Linux to e.g., Debian Family to e.g., Ubuntu), references aren't necessarily the same across families (e.g., Ubuntu to RHEL) and order of the sections can differ significantly. The same holds for STIG: unless a product undergoes STIG certification (thus assigning rules a specific STIG ID for the product), we shouldn't reuse one product's STIG IDs for other, unrelated products. In the future, we might want to offer a "hybrid" form (e.g., cis@ubuntu) applying to all versions of a product, but otherwise I think this is the best route to go. Start enforcing this at build time, to ensure we (and other contributors) don't accidentally undo this work in the future. Signed-off-by: Alexander Scheel <alex.scheel@canonical.com>
cipherboy
added a commit
to cipherboy/scap-security-guide
that referenced
this pull request
Apr 21, 2021
Per discussion on ComplianceAsCode#6416, I don't think it is generally valid to have a unqualified (by product) CIS reference identifier. While there is a hierarchy to the CIS benchmarks (from General Linux to e.g., Debian Family to e.g., Ubuntu), references aren't necessarily the same across families (e.g., Ubuntu to RHEL) and order of the sections can differ significantly. The same holds for STIG: unless a product undergoes STIG certification (thus assigning rules a specific STIG ID for the product), we shouldn't reuse one product's STIG IDs for other, unrelated products. In the future, we might want to offer a "hybrid" form (e.g., cis@ubuntu) applying to all versions of a product, but otherwise I think this is the best route to go. Start enforcing this at build time, to ensure we (and other contributors) don't accidentally undo this work in the future. Signed-off-by: Alexander Scheel <alex.scheel@canonical.com>
cipherboy
added a commit
to cipherboy/scap-security-guide
that referenced
this pull request
Apr 22, 2021
Per discussion on ComplianceAsCode#6416, I don't think it is generally valid to have a unqualified (by product) CIS reference identifier. While there is a hierarchy to the CIS benchmarks (from General Linux to e.g., Debian Family to e.g., Ubuntu), references aren't necessarily the same across families (e.g., Ubuntu to RHEL) and order of the sections can differ significantly. The same holds for STIG: unless a product undergoes STIG certification (thus assigning rules a specific STIG ID for the product), we shouldn't reuse one product's STIG IDs for other, unrelated products. In the future, we might want to offer a "hybrid" form (e.g., cis@ubuntu) applying to all versions of a product, but otherwise I think this is the best route to go. Start enforcing this at build time, to ensure we (and other contributors) don't accidentally undo this work in the future. Signed-off-by: Alexander Scheel <alex.scheel@canonical.com>
This was referenced Jun 3, 2021
anivan-suse
pushed a commit
to anivan-suse/content
that referenced
this pull request
Jun 24, 2021
* remove added new line
* Add recommended chrony config
This adds the recommended chrony config as a remediation for rhcos4
profiles.
Note that we won't enforce the relevant servers folks should use, as
they might be in a disconnected installation; thus, we enable them to
use /etc/chrony.d/ to drop their configurations.
Signed-off-by: Juan Antonio Osorio Robles <jaosorior@redhat.com>
* rhcos4/e8: Use individual kernel module load audit rules
These actually have remediations.
Signed-off-by: Juan Antonio Osorio Robles <jaosorior@redhat.com>
* Allow product-version-agnostic checks/remediations
This allows product-version-agnostic checks/remediations to be added to
CaC and used ahead of shared content, while still allowing
version-specific content to be favored ahead of both.
That is, given the following:
- ovals/shared.xml
- ovals/ubuntu.xml
- ovals/ubuntu2004.xml
The priority order returned from:
get_rule_dir_ovals(..., product="ubuntu")
would be:
ubuntu2004.xml
ubuntu.xml
shared.xml
This is useful when OVAL/... content differs between products (e.g.,
RHEL, Ubuntu, ...) but still applies to other versions of the same
product (e.g., 18.04 and 20.04). Duplication thus occurs only at a
product level (if say, Debian chose to reuse Ubuntu content or
visa-versa).
Signed-off-by: Alexander Scheel <alex.scheel@canonical.com>
* Add Ubuntu as a known platform for ssg_test_suite
In order to run on Ubuntu (as a host and a guest) I ended up needing two
things:
1. Add Ubuntu to the package installation capabilities,
2. Fix libvirt<->xml interactions: tostring rendered as bytes not as a
str object but the libvirt API expected a str.
I also needed to add CPE_NAME to the Ubuntu guest VM as our
/etc/os-release doesn't contain it by default.
Signed-off-by: Alexander Scheel <alex.scheel@canonical.com>
* Update Ubuntu CPEs to match published CPEs
From both official-cpe-dictionary_v2.3.xml and
official-cpe-dictionary_v2.2.xml, Ubuntu's CPEs include the LTS suffix.
Update CaC/content's copies to match.
Note: this only applies for LTS releases. If non-LTS releases were to
be included later, they wouldn't include this suffix.
Signed-off-by: Alexander Scheel <alex.scheel@canonical.com>
* SLES-15-030390 add rule, remediation and test
* Abort the build if an OVAL is not included due to extend_definition.
If an extending definition is missing, then the OVAL won't be there as well.
This indicates an incorrect setup of applicability - either extending definitions
are not applicable as they should, or the compound definition should not be applicable.
* Dont tolerate missing extending definitions.
* Altered prodtypes to prevent OVAL inconsistencies.
Definitions used by other definitions need to have at least the same applicability
as definitions that require them.
* Fixed the Example product.
- The product name is specified more than once in the project, and all occurences have to be consistent.
* remove service_nfs_disabled sle15/profiles/cis.profile
service_nfs_disabled was added in initial creation,
but has not been validated for SLES.
* SLES-15 add checks and remediations.
The following are all limitted to adding @sles15
info to existing rules and where needed adding
multi_platform_sle to ansible/shared.yml
- SLES-15-020210 'Set Existing Passwords Minimum Age'
- SLES-15-030290 'Record Events that Modify the System'
- SLES-15-030450 'Record Any Attempts to Run chcon'
- SLES-15-030530 'Ensure auditd Collects Information on Kernel Module Loading and Unloading - finit_module'
- SLES-15-030540 'Ensure auditd Collects Information on Kernel Module Loading - init_module'
- SLES-15-030360 'Ensure auditd Collects Information on the Use of Privileged Commands - umount'
- SLES-15-030030 'Record Events that Modify User/Group Information - /etc/security/opasswd'
- SLES-15-010370 'Verify firewalld Enabled'
- SLES-15-040381 'Disable Kernel Parameter for IPv6 Forwarding'
- SLES-15-040321 'Disable Kernel Parameter for Accepting Source-Routed Packets on IPv6 Interfaces by Default'
- SLES-15-010359 'Verify that System Executables Have Root Ownership'
- SLES-15-010358 'Verify that System Executables Have Restrictive Permissions'
- SLES-15-010330 'Encrypt Partitions'
- SLES-15-020102 'Ensure Users Re-Authenticate for Privilege Escalation - sudo'
fix SLE-15 STIG in sysctl_net_ipv6_conf_default_accept_source_route,
should have been SLES-15-040321.
* Add CPE OVAL check for SLES for SAP 12 and 15.
* Add rules for SLES-12-010060
- SLES-12-010060 'Enable GNOME3 Screensaver Lock After Idle Period'
* rhcos4: Add better instructions for `disable_ctrlaltdel_reboot`
This makes it easier for folks to remediate themselves.
Signed-off-by: Juan Antonio Osorio Robles <jaosorior@redhat.com>
* rhcos4: Add better instructions for `disable_ctrlaltdel_burstaction`
This makes it easier for folks to remediate themselves.
Signed-off-by: Juan Antonio Osorio Robles <jaosorior@redhat.com>
* rhcos4: Add better instructions for `package_usbguard_installed`
This makes it easier for folks to remediate themselves.
Signed-off-by: Juan Antonio Osorio Robles <jaosorior@redhat.com>
* rhcos4: Replace repetitive MachineConfig footer with macro
This reduces the duplication in the content.
Signed-off-by: Juan Antonio Osorio Robles <jaosorior@redhat.com>
* Modify `describe_service_enabled` template for RHCOS4
This adds an alternative description for this macro in case of rhcos4 to
better reflect what an admin would actually need to do.
Signed-off-by: Juan Antonio Osorio Robles <jaosorior@redhat.com>
* Modify `describe_service_disabled` template for RHCOS4
This adds an alternative description for this macro in case of rhcos4 to
better reflect what an admin would actually need to do.
Signed-off-by: Juan Antonio Osorio Robles <jaosorior@redhat.com>
* Add rhcos4-specific instructions in the ocil_service_(enabled|disabled) macros
This ensures admins have a better notion of what to do.
Signed-off-by: Juan Antonio Osorio Robles <jaosorior@redhat.com>
* Revert "make build system handle inherited platforms also for groups"
* Add the RHEL9 product.
RHEL9 will come one day, so better to be prepared.
The product has been created using RHEL8 as a basis, and making sure that the build works.
No profiles or STIG overlay for the time being.
* Enabled rules for RHEL9 to get consistent product build.
* increase /usr partition size in testing kicstart
* Update linux_os/guide/system/accounts/accounts-restrictions/password_expiration/accounts_password_set_min_life_existing/rule.yml
Co-authored-by: vojtapolasek <krecoun@gmail.com>
* Update linux_os/guide/system/auditing/auditd_configure_rules/audit_execution_selinux_commands/audit_rules_execution_chcon/rule.yml
Co-authored-by: vojtapolasek <krecoun@gmail.com>
* Update linux_os/guide/system/auditing/auditd_configure_rules/audit_kernel_module_loading/audit_rules_kernel_module_loading_finit/rule.yml
Co-authored-by: vojtapolasek <krecoun@gmail.com>
* Update linux_os/guide/system/auditing/auditd_configure_rules/audit_kernel_module_loading/audit_rules_kernel_module_loading_init/rule.yml
Co-authored-by: vojtapolasek <krecoun@gmail.com>
* Update linux_os/guide/system/auditing/auditd_configure_rules/audit_rules_usergroup_modification_opasswd/rule.yml
Co-authored-by: vojtapolasek <krecoun@gmail.com>
* Update linux_os/guide/system/software/disk_partitioning/encrypt_partitions/rule.yml
Co-authored-by: vojtapolasek <krecoun@gmail.com>
* Update linux_os/guide/system/network/network-firewalld/firewalld_activation/service_firewalld_enabled/rule.yml
Co-authored-by: vojtapolasek <krecoun@gmail.com>
* Update linux_os/guide/system/network/network-firewalld/firewalld_activation/service_firewalld_enabled/rule.yml
Co-authored-by: vojtapolasek <krecoun@gmail.com>
* remove extra newline
* remove extra newline
* remove extra newline
* remove extra new line
* remove xtra newline
* rhcos4: Add relevant instructions to configure_crypto_policy rule
Signed-off-by: Juan Antonio Osorio Robles <jaosorior@redhat.com>
* change shell to command
* use when not jinja if to match other code
* Add Rule for SLES-15-040382
- SLES-15-040382 'Disable Kernel Parameter for IPv6 Forwarding by default'
* Use v1beta1 for api_server_api_priority_flowschema_catch_all object
v1alpha1 for FlowSchemas is deprecated and removed in kube 1.21.
* Create CPE per OCP4 version to handle deprecations
Since OCP4 uses the same datastream for multiple version, the time has
come for us to start differentiating between what's supported in each
version. Thus, we have now specific CPEs for different versions that can
be used to delimit what's supported.
A first instance of this kind of problem is the flowschema check:
It had been in v1alpha1 for a while, when it was promoted to v1beta1 in
OpenShift 4.8 (Kubernetes version 1.21). Thus, we promoted the rule that
was previously checking this to use the newer version, and created a new
rule for the old version.
The each of these rules now has the appropriate supported versions
marked on the `platforms` key.
Signed-off-by: Juan Antonio Osorio Robles <jaosorior@redhat.com>
* Update OVAL checks docs section
Most of the OVAL checks have moved closer to the rule and the doc didn't
reflect this very well.
* Add OVAL Limitations and pitfalls sections
Including the first issue, check_existence="all_exist" is a lie.
* Fix typos and make language more clear
Co-authored-by: Gabriel Becker <ggasparb@redhat.com>
* Add ignore option to auditd and audispd variables
* Add rotate option to var_auditd_disk_full_action variable
* Updates to support ansible_playbook_to_role utility
Numerous updates were made to enhance the functionality
and to fix bugs:
* Updated GH actions to run on PR's. Also added new tag skip.
* Updated galaxy meta template. Includes additions of variables
to be used as substitutions to support automating the creation
of that file, and to prevent manual additions as was handled in
the past.
* Added the anssi profiles to the whitelist (have not done any testing
on these roles yet)
* Updates/bug fixes to support meta templating. Fixed issue with
meta and readme files being overwritten with the wrong output.
* Updated syntax for python3 support. No need to use python2 for
this IMO.
* Enable dir_perms_world_writable_sticky_bits ansible remediation in RHEL.
* Disable OCP4 building on older OpenSCAP releases
Note: this will need to be updated once OpenSCAP 1.3.x is released with
OCP4 content.
Resolves: ComplianceAsCode#6798
Signed-off-by: Alexander Scheel <alex.scheel@canonical.com>
* add suse specific info to description
* build-scripts/profile_tool.py - add option to not show overall statistics of benchmark
* SLES-15-030390 update. Tests added
* SLES-15-030390 update. Tests added
* command should not include the output
* restore dropped file
* Add OL anssi profiles
Signed-off-by: Federico Ramirez <federico.r.ramirez@oracle.com>
* Update OL cui profiles
Signed-off-by: Federico Ramirez <federico.r.ramirez@oracle.com>
* Add OL7 hipaa profile
Signed-off-by: Federico Ramirez <federico.r.ramirez@oracle.com>
* Update OL8 hipaa profile
Signed-off-by: Federico Ramirez <federico.r.ramirez@oracle.com>
* Add rule file_ownership_library_dirs for SLES-15-010353
Map SLES-15-010353 references and ids to file_ownership_library_dirs rule
* Add rule for SLES-15-010030
Map package_vsftpd_removed rule to STIG ID SLES-15-010030
* ocp4/e2e tests: Add ability to do per-version tests
This enables the framework to do tests based on the version the cluster
is running. This enables us to add different expectations based on the
cluster's version.
The flowschema tests were enhanced with this capability.
Signed-off-by: Juan Antonio Osorio Robles <jaosorior@redhat.com>
* OCP4: Add applicability warnings
These will show up as part of the results and guide users to why a check
is marked as NOT-APPLICABLE.
Signed-off-by: Juan Antonio Osorio Robles <jaosorior@redhat.com>
* Change nfs service name to nfs-server in service_nfs_disabled rule
* Remove sle15 prodtype from service_nfs_disabled rule
* Add service_nfs_disabled test scenarios
* Add dconf_gnome_lock_screen_on_smartcard_removal to cover RHEL-08-020050.
* use version 5.11
* Extract the functionality for rendering compiled resources.
* Render rules related to a component.
* Address upstream comments
Fix CCE'id
Add ocil_clause
* Remove extra new line
* SLES-15-030730 'Record Unsuccessul Delete Attempts to Files - renameat2'
* Fix NIST id format
Thanks to @brett060102
* Select dconf_gnome_lock_screen_on_smartcard_removal in STIG profile.
* fix service_sshd_enabled for SLE-15
Initial coding failed to set:
packagename@sle15: openssh
This is needed for this rule to work in SLE 15.
* SLES-15-010220 updates for firewalld
SuSEfirewall2 was retired in SLE-12 in favor of firewalld
So, we need to remove SuSEfirewall2 references from SL15
and fix up the SLES-15-010220 rule. This includes change SLES-15-010370
to SLES-15-010220. SLES-15-010370 was specific to the firewall panic switch
enablement.
* Add CCEs for RHEL9 rsyslog rules
* Checking OSPP missing references in ssg/build_profile.py
* Extend profile_tool.py with option to check for missing OSPP references
* RHCOS4: Add relevant instructions and e2e test for banner_etc_issue
It was missing.
Signed-off-by: Juan Antonio Osorio Robles <jaosorior@redhat.com>
* CIS: Add OCIL to kubelet_configure_tls_cipher_suites
The rule contained just a placeholder text
* Add OCIL to sshd_limit_user_access
OCP4 uses OCIL as instructions for manual checks, so it's prudent to
have OCIL clauses for all rules.
* Fix CIS-CSC URI
CIS-CSC: Center for Internet Security Critical Security Controls
for Effective Cyber Defense -- appears to have been renamed to
just CIS Controls and is now present at a new URL:
https://www.cisecurity.org/controls/
Update ours to match rather than linking to a (now dated) poster.
Resolves: ComplianceAsCode#6791
Signed-off-by: Alexander Scheel <alex.scheel@canonical.com>
* restore package_vsftpd_removed in sle15 stig.profile
* update tests to test also for files in /etc/profile.d directory
* RHCOS/OCP: Add more detailed instructions for more OCIL instances
This covers better instructions in RHCOS4 and OCP4 content.
The following macros were modified:
* ocil_file_permissions
* ocil_file_group_owner
* ocil_file_owner
Signed-off-by: Juan Antonio Osorio Robles <jaosorior@redhat.com>
* Checking CUI missing references in ssg/build_profile.py
* Extend profile_tool.py with option to check for missing CUI references
* Add OL7 e8 profile
Signed-off-by: Federico Ramirez <federico.r.ramirez@oracle.com>
* Update OL8 e8 profile
Signed-off-by: Federico Ramirez <federico.r.ramirez@oracle.com>
* Fix pep8 lint issues in OSPP profile parts in build-scripts/profile_tool.py and in ssg/build_profile.py
* update to use watch_rule macro
* Fix ansible lint issue in ensure_rtc_utc_configuration.
* Improved the rendering functionality.
- Removed problematic sub elements used together with XCCDF value substitution.
- Removed the component argument that wasn't useful.
- Added a title argument.
- Split the HTML template into the boilerplate part and the specific part.
- Introduced a template loader that is able to load from selected relative paths.
* Remove sshd_allow_only_protocol2 from RHEL8 STIG.
This item is to be removed from next STIG revision since it's not
applicable anymore.
* Add CCI reference to package_gssproxy_removed.
* Add CIS URI to SLE products.
* update rule description
* update bash remediation
* update ansible remediation
* Add ol7 cjis profile
Signed-off-by: Federico Ramirez <federico.r.ramirez@oracle.com>
* Update ol8 cjis profile
Signed-off-by: Federico Ramirez <federico.r.ramirez@oracle.com>
* Check gdm database for OL on dconf_db_up_to_date
Signed-off-by: Federico Ramirez <federico.r.ramirez@oracle.com>
* Add HIPAA references to dconf_db_up_to_date
* Add HIPAA references to configure_crypto_policy
* Add HIPAA references to configure_ssh_crypto_policy
* Updating RHEL8 STIG profile for readability changes
* Remove harden_sshd_crypto_policy from RHEL8 STIG profile.
* Fix ansible remediation applicability.
When clauses for applicability must come first in the list. Otherwise it
can produce unexpected results when multiple tasks have to interact with
each other but they have different or none additional when clauses.
Fixes ComplianceAsCode#6857
* add rule
* add check
* add remediations
* add tests
* add rule into stig profiles
* remove cces from references
* update profile stability test
* rename rule
* rewrite ansible loop to list of packages
* Update ssg/build_remediations.py
Co-authored-by: Milan Lysonek <milan.lysonek@gmail.com>
* Rename file_permissions_var_log_messages to file_permissions_local_var_log_messages.
* Add new rules to cover file/dir permissions for /var/log/messages.
* Select file permissions rules for /var/log into RHEL8 STIG profile.
* Creating new RHEL 8 STIG GUI profile
* Update 30-ospp-v42-4-delete-failed.rules
Removed renmeat2 changes
* Update 30-ospp-v42-4-delete-success.rules
Removed renmeat2 changes
* Delete e2e.yml
Test only applied for Red Hat not for SLE. Removed e2e.yml
* Update rule.yml
Fixed cce id CCE-85726-8
* Creating new RHEL 7 STIG GUI profile
* Added STIG ID comment to be inline with main profile
* Added test scritp
* Rename OVAL ids from file_permissions_local_var_log_messages rule.
* Updated fail script syntax error
* Added versioning info to title/description
* Updated metadata version to V3R2
* Code improvements.
- Clarified the intention behind the regex and the sub element substitution.
- Replaced a for loop by a list comprehension.
* Introduce RHV4 PCI-DSS profile based on RHEL8
* Adjust the profile to RHVH
Libreswan is not available in RHVH.
* Updated metadata version to V3R2 on stig_gui profile
* Add anaconda remediation for xwindows_remove_packages.
* Fix RHEL8 STIG with GUI stable profile data.
* SLES-15-030520 add to existing rule, audit_rules_kernel_module_loading_delete
* Introduce @ form in all template fields
As noted by @ggbecker in ComplianceAsCode#6659, templates apparently lack the ability to
process @-formed variables in the extra_ovals.yml format. Because of the
way a Rule's yaml gets processed in build_yaml.py, we do not have that
issue due to its preprocessing, though this fix does get applied in both
places.
This allows us to avoid the need to use Jinja processing on
extra_ovals.yml for determining package name, making it look nicer and
be a little more friendly for contributors.
Resolves: ComplianceAsCode#6659
Signed-off-by: Alexander Scheel <alex.scheel@canonical.com>
* Add test that checks missing rule references for specific profiles.
* Add missing rule references check to ctest
* Show which rule failed during template builds
Previously, when a rule failed to build when applying the template
(e.g., using a glob in a package removal template), we wouldn't
necessarily know which rule failed to build. Print an error message
showing which rule this was and then re-throw the error so that the
builder can see which rule caused the build failure.
Signed-off-by: Alexander Scheel <alex.scheel@canonical.com>
* Prevent unqualified CIS and STIGID references
Per discussion on ComplianceAsCode#6416, I don't think it is generally valid to have a
unqualified (by product) CIS reference identifier. While there is a
hierarchy to the CIS benchmarks (from General Linux to e.g., Debian
Family to e.g., Ubuntu), references aren't necessarily the same across
families (e.g., Ubuntu to RHEL) and order of the sections can differ
significantly. The same holds for STIG: unless a product undergoes STIG
certification (thus assigning rules a specific STIG ID for the product),
we shouldn't reuse one product's STIG IDs for other, unrelated products.
In the future, we might want to offer a "hybrid" form (e.g., cis@ubuntu)
applying to all versions of a product, but otherwise I think this is the
best route to go.
Start enforcing this at build time, to ensure we (and other
contributors) don't accidentally undo this work in the future.
Signed-off-by: Alexander Scheel <alex.scheel@canonical.com>
* Replace unqualified CIS references with qualified
Mostly this has been replaced with rhel7/rhel8 references (my apologies
to the SUSE and Oracle contributors), but one Fedora-specific and one
OL-specific rule was caught and fixed appropriately.
Signed-off-by: Alexander Scheel <alex.scheel@canonical.com>
* Apply suggestions from wsato's code review
These fix up various CIS identifiers in RHEL 7 and RHEL 8 content.
Co-authored-by: Watson Yuuma Sato <wsato@redhat.com>
Signed-off-by: Alexander Scheel <alex.scheel@canonical.com>
* Add Rule,Test for SLES-15-020103
Rule has no remediation.
* Update linux_os/guide/system/software/updating/ensure_fedora_gpgkey_installed/rule.yml
Co-authored-by: Watson Yuuma Sato <wsato@redhat.com>
* Simplify the policy renderer.
It can now take advantage of the boilerplate provided by other renderers.
* Remove rules related to gnome/dconf
* Update ssg/templates.py
Co-authored-by: Watson Yuuma Sato <wsato@redhat.com>
* Update linux_os/guide/system/software/sudo/sudoers_validate_passwd/rule.yml
Co-authored-by: vojtapolasek <krecoun@gmail.com>
* Apply suggestions from code review
Co-authored-by: vojtapolasek <krecoun@gmail.com>
* Updated review comments:
- Fixed disa record and removed blank line.
- Renamed test case file name according the to the format
- Removed susefirewall2_only_required_services stig from sle15 profile
* Apply suggestions from code review
Co-authored-by: vojtapolasek <krecoun@gmail.com>
* Fixed ocil record
* fix ocil and add correct rhel8 stigid
* make rule and tests applicable to more products
add stigids for rhel7 and rhel8
* add rule to rhel7 and rhel8 stig profiles
* OCP: Fix description of kubelet TLS cipher suites
The trailing comma would have produced an invalid kubelet config:
"TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,"
],
note the comma in the string
Co-authored-by: Juan Antonio Osorio Robles <jaosorior@redhat.com>
Co-authored-by: vojtapolasek <vpolasek@redhat.com>
Co-authored-by: Matt Rogers <mrogers@redhat.com>
Co-authored-by: Alexander Scheel <alex.scheel@canonical.com>
Co-authored-by: Matus Marhefka <mmarhefk@redhat.com>
Co-authored-by: Gabriel Becker <ggasparb@redhat.com>
Co-authored-by: Jan Černý <jcerny@redhat.com>
Co-authored-by: Watson Yuuma Sato <wsato@redhat.com>
Co-authored-by: Matěj Týč <matyc@redhat.com>
Co-authored-by: vojtapolasek <krecoun@gmail.com>
Co-authored-by: yarunachalam <yarunachalam@suse.com>
Co-authored-by: Milan Lysonek <mlysonek@redhat.com>
Co-authored-by: Carlos Matos <cmatos@redhat.com>
Co-authored-by: rchikov <rumen.chikov@suse.com>
Co-authored-by: Federico Ramirez <federico.r.ramirez@oracle.com>
Co-authored-by: teacup-on-rockingchair <strandjata@gmail.com>
Co-authored-by: Jakub Hrozek <jhrozek@redhat.com>
Co-authored-by: Milan Lysonek <milan.lysonek@gmail.com>
Co-authored-by: yarunachalam <40246855+yarunachalam@users.noreply.github.com>
Co-authored-by: Alexander Scheel <alexander.m.scheel@gmail.com>
cipherboy
added a commit
to cipherboy/scap-security-guide
that referenced
this pull request
Jun 30, 2021
This takes inspiration from ComplianceAsCode#6416 and Canonical's present internal branch; rules which don't yet exist in upstream were dropped from these profiles. Over time more rules will be added and these will align better with our internal profiles. Co-Authored-By: Brian Turek <brian.turek@gmail.com> Co-Authored-By: Gabriel Becker <ggasparb@redhat.com> Co-Authored-By: Richard Maciel Costa <richard.maciel.costa@canonical.com> Signed-off-by: Alexander Scheel <alex.scheel@canonical.com>
|
Closing this in favor of #7181 as that is a completed set of CIS profiles. @Caligatio You have been credited as co-author on several commits both internally (during development and rebases) and on that pull request. Thanks for all your help getting the initial profiles started! Feel free to contribute to discussion on that pull request and/or upstream in subsequent pull requests once it merges. |
cipherboy
added a commit
to cipherboy/scap-security-guide
that referenced
this pull request
Jun 30, 2021
This takes inspiration from ComplianceAsCode#6416 and Canonical's present internal branch; rules which don't yet exist in upstream were dropped from these profiles. Over time more rules will be added and these will align better with our internal profiles. Co-Authored-By: Brian Turek <brian.turek@gmail.com> Co-Authored-By: Gabriel Becker <ggasparb@redhat.com> Co-Authored-By: Richard Maciel Costa <richard.maciel.costa@canonical.com> Signed-off-by: Alexander Scheel <alex.scheel@canonical.com>
cipherboy
added a commit
to cipherboy/scap-security-guide
that referenced
this pull request
Jun 30, 2021
This takes inspiration from ComplianceAsCode#6416 and Canonical's present internal branch; rules which don't yet exist in upstream were dropped from these profiles. Over time more rules will be added and these will align better with our internal profiles. Co-Authored-By: Brian Turek <brian.turek@gmail.com> Co-Authored-By: Gabriel Becker <ggasparb@redhat.com> Co-Authored-By: Richard Maciel Costa <richard.maciel.costa@canonical.com> Signed-off-by: Alexander Scheel <alex.scheel@canonical.com>
cipherboy
added a commit
to cipherboy/scap-security-guide
that referenced
this pull request
Jul 2, 2021
This takes inspiration from ComplianceAsCode#6416 and Canonical's present internal branch; rules which don't yet exist in upstream were dropped from these profiles. Over time more rules will be added and these will align better with our internal profiles. Co-Authored-By: Brian Turek <brian.turek@gmail.com> Co-Authored-By: Gabriel Becker <ggasparb@redhat.com> Co-Authored-By: Richard Maciel Costa <richard.maciel.costa@canonical.com> Signed-off-by: Alexander Scheel <alex.scheel@canonical.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description:
This is a work in progress PR to add the CIS Level 1 profile for Ubuntu 20.04
Rationale:
I initially implemented the "Standard" profile for Ubuntu 20.04 by copying over the existing profile for Ubuntu 18.04 Unfortunately there were only a few tests so this PR should bring Ubuntu 20.04 up to par with the other supported distributions.