[RFC cip-dev][isar-cip-core][PATCH 14/14] Add doc/README.cis-hardening.md
Quirin Gylstorff <[email protected]> Mon, 27 Jul 2026 15:13:08 +0200
| Newsgroups | org.cip-project.lists.cip-dev |
|---|---|
| Message-ID | <[email protected]> |
Co-Authored-by: Clara Kowalsky <[email protected]> Co-Authored-by: Felix Moessbauer <[email protected]> Co-Authored-by: Christoph Steiger <[email protected]> Signed-off-by: Quirin Gylstorff <[email protected]> --- README.md | 1 + doc/README.cis-hardening.md | 183 ++++++++++++++++++++++++++++++++++++ 2 files changed, 184 insertions(+) create mode 100644 doc/README.cis-hardening.md diff --git a/README.md b/README.md index 435d037..f9f4f01 100644 --- a/README.md +++ b/README.md @@ -60,6 +60,7 @@ The following topics are in separate READMEs: - [Update and Secure boot signing](./doc/README.signing.md) - [Encryption with TPM2](./doc/README.tpm2.encryption.md) - [Factory-reset](./doc/README.factory-reset.md) + - [CIS hardening](./doc/README.cis-hardening.md) - [Release policy](./doc/README_version-release-policy.md) =20 ## Community Resources diff --git a/doc/README.cis-hardening.md b/doc/README.cis-hardening.md new file mode 100644 index 0000000..104818a --- /dev/null +++ b/doc/README.cis-hardening.md @@ -0,0 +1,183 @@ +# CIS Hardening + +CIP Core can generate and apply a selected set of CIS hardening rules duri= ng +the image build. The rule catalogue is derived from OVH `debian-cis` and = is +exposed as a Kconfig menu. The selected rules are exported as JSON, conve= rted +into Debian package content, and reused for kernel configuration and optio= nal +runtime validation. + +## Key design decisions + +- CIS hardening is optional. +- Hardening is enabled by a single image configuration option, + `CIP_CIS_HARDENING`, plus the selected rule configuration. +- Hardening and validation are independent. An image may apply hardening, + include validation support, or do both depending on the product workflow= . +- Hardening and validation configuration must be overridable from a + third-party layer, for example through a `cip-cis-rules-config_%.bbappen= d` that + provides a checked-in configuration. +- The default level `2` configuration must harden all generic settings. + A conformity level below `100%` is acceptable for this default because t= he + remaining rules are product specific and must be completed downstream. +- CIS `99.x` rules are ignored. + +## Enabling CIS hardening + +Enable hardening for an image by setting `CIP_CIS_HARDENING`: + +``` +CIP_CIS_HARDENING =3D "1" +``` + +When this option is enabled, `cip-core-image`: + +- inherits the CIS hardening image class +- installs the `cip-cis-rules` and `cip-cis-rules-config` package +- applies the generated hardening package to the root file system, +- adds the generated kernel hardening fragment to the CIP kernel build. + +## Configuring rules + +Rules can be selected with the recipe menuconfig task: + +``` +./kas-container shell <kas files> +bitbake cip-cis-rules-config -c menuconfig +bitbake cip-core-image +``` + +The menu contains: + +- a hardening level choice, currently levels `1` to `5`, +- one boolean option per CIS rule, +- justification strings for rules disabled even though the selected level + requires them. + +Changing the hardening level in the menu resets rule selections to the def= aults +for the new level. Existing justification strings are kept. + +The menu writes `.config.json` in the `cip-cis-rules` work directory. To = use +this configuration for hardening it must be copied into `cip-cis-rules-con= fig` +and added there in the `SRC_URI` and `HARDENING_CFG`. + +For product builds, copy the generated `.config.json` into a local layer, = add +it to `SRC_URI` from a `cip-cis-rules-config_%.bbappend`, and check both f= iles into +version control. You can have multiple configurations checked in this way= , and +select which one should be applied with `HARDENING_CFG`. + +The JSON format is validated against +`recipes-security/cip-cis-rules/files/cip-cis-rules/generator/config.schem= a.json`, +whereby `apply` controls whether the rule is enabled. `justification` doc= uments +why a required rule is disabled. + +## What the hardening package installs + +The `cip-cis-rules` package is a configuration package. It installs only = the +files for rules with `apply: true`; rules without implemented snippets are +kept in the JSON selection but do not add files to the root file system. + +Implemented snippets currently cover: + +- `/etc/modprobe.d/` files for disabled filesystems and USB storage, +- `/etc/sysctl.d/` files for kernel and network sysctl settings, +- `/etc/ssh/sshd_config.d/` files for SSH daemon hardening, +- `/etc/sudoers.d/` files for sudo hardening, +- `/etc/security/limits.d/` and `/etc/security/pwquality.d/`, +- PAM snippets under `/usr/share/pam-configs` and `/etc/pam.d`, +- chrony configuration under `/etc/chrony/conf.d`, +- helper scripts under `/usr/share/cip-cis-rules/configuration` for settin= gs + that require an install-time action, such as file permissions, + `pam-auth-update`, and `/etc/login.defs` edits. + +The `cip-cis-rules-config` package installs the generated data artifacts u= nder +`/usr/share/cip-cis-rules/`: + +- `.config.json`, the selected rule set, +- `hardening.cfg`, the kernel config fragment generated from enabled + kernel-relevant rules. + +The same artifacts are also deployed to `DEPLOY_DIR_IMAGE` as: + +- `${CIP_CIS_HARDENING_CONFIG}`, +- `${CIP_CIS_HARDENING_KCONFIG}`. + +## Kernel hardening + +When `CIP_CIS_HARDENING` is enabled, the CIP kernel includes +`${DISTRO}-hardening.kernel.cfg` as `hardening.kernel.cfg` through +`KERNEL_CONFIG_FRAGMENTS`. + +The fragment is generated from enabled rules only. Disabled rules are omi= tted +from the kernel fragment and should carry a justification in `.config.json= ` if +they are required by the selected level. + +## Validation + +Set `CIP_CIS_HARDENING_VALIDATION` to enable validation support in the ima= ge: + +``` +CIP_CIS_HARDENING_VALIDATION =3D "1" +``` + +With validation enabled, `cip-core-image` installs `cip-cis-validation` an= d +inherits the kernel hardening validation class. Validation uses the selec= ted +CIS rule configuration and can be enabled independently from hardening. + +Runtime validation uses the OVH `cis-hardening` audit tooling. During the +image build, disabled rules from `${CIP_CIS_HARDENING_CONFIG}` are convert= ed +into override files with `status=3Ddisabled`, so the audit run checks the = selected +policy instead of the complete upstream rule set. + +The validation command runs the audit in a temporary CIS configuration tre= e and +succeeds only when the reported `CONFORMITY_PERCENTAGE` is `100.00`. + +Kernel validation runs during the image build. It compares the generated +hardening kernel fragment with the kernel config installed under `/boot`. = A +JSON report is written to `DEPLOY_DIR_IMAGE` as: + +- `${CIP_CIS_HARDENING_REPORT}` + +If a kernel option that should be disabled by CIS hardening is still enabl= ed as +`y` or `m`, the build fails and the report lists the non-compliant rules. + +## Notes and limitations + +Some CIS rules are inherently use case specific. Examples are partition la= yout +rules, firewall policy, SSH access lists, password ageing, and rules that +inspect existing users or files. Configure or justify those rules accordi= ng +to the target product requirements before relying on validation results. + +The hardening package will **not** install additional packages to fulfill +a rule, for example iptables or ssh. These use case specific packages need= to +be installed by the user. + +### Comparison to security-customizations + +The recipe `security-customizations` sets some hardening options similar t= o the recipe `cip-cis-rules`. +Because `security-customizations` is part of the certification efforts, it= is not modified. The following sections +list the touch points. + +#### SSH hardening + +The recipe `security-customizations` contains hardening rules for ssh. Thi= s table summarizes the differences from +the cip-cis-rules: +| security-customizations | cis-rules |Comment| +| ------ | ------ |------| +|ssh-remote-session-term.conf|cis-5.2.16-sshd-idle-timeout.conf| adapt cis= hardening to lower values of cip security| +|ssh-pam-remote.conf | - | no rule implemented in cip-cis-rul= es | +|ssh-hardening.conf |cis-5.2.7-sshd-maxauthtries.conf | 3 vs= 4 | +|ssh-hardening.conf |cis-5.2.23-limit-ssh-max-sessions.conf = |2 vs 10| +|ssh-hardening.conf |cis-5.2.21-disable-ssh-allow-tcp-forwarding.co= nf || +|ssh-hardening.conf |cis-5.2.6-disable-x11-forwarding.conf |= | +|ssh-hardening.conf | - | AllowAgentForwarding is allowed acc= ording to cis rules| + +#### Other hardening + +The script `postinst` of the recipe `security-customizations` contains the= following changes: +|security-customizations|cis-rules|Comment| +| ------ | ------ |------| +| set password creation parameters with pam.cracklib| | parameter differ b= etween the implementations| +|lock user account after unsuccessful attempts| - | no rule implemented in= cip-cis-rules| +| Concurrent session control| - |no rule implemented in cip-cis-rules| +| Audit storage capacity| - |no rule implemented in cip-cis-rules| +| Enable Multi Factor Authentication for Local and Remote Session| - |no r= ule implemented in cip-cis-rules| --=20 2.53.0