Introduce ability to generate kickstarts #2136

jan-cerny · 2024-07-10T13:43:54Z

This PR introduces ability to generate kickstarts from SCAP content using:

oscap xccdf generate fix --fix-type kickstart ds.xml

The kickstart will be generated from kickstart snippets in XCCDF rules in the input SCAP content.
The kickstart snippets need to be stored in <fix> elements with system attribute set to urn:xccdf:fix:script:kickstart.

For more details, please read commit messages of each commit.

Rationale:

We'd like to provide a lightweight system hardening for Anaconda, that is not dependent on UI and does not require user intervention. This should be pretty much similar to Image Builder's experience for users that can not use it for some reason.

How to test:

Build RHEL 9 data stream from the ComplianceAsCode pull request master as of 2024-07-29 or newer.
Generate the kickstart ks.cfg:

./oscap_wrapper xccdf generate fix --profile stig --output ks.cfg --fix-type kickstart ~/work/git/scap-security-guide/build/ssg-rhel9-ds.xml

Add AppStream repository to the generated kickstart by adding this line (edit the URL)

repo --name=extra-repository --baseurl=http://DOWNLOAD_HOSTNAME/released/RHEL-9/9.4.0/AppStream/x86_64/os/

Serve the kickstart on a HTTP server

python3 -m http.server

Run virt-manager, click on Create a new virtual machine. Choose Network Install.
Provide installation URL for RHEL 9.4: http://DOWNLOAD_HOSTNAME/released/RHEL-9/9.4.0/BaseOS/x86_64/os/
Under the installation URL field, click on URL options and insert there inst.ks=http://192.168.124.1:8000/ks.cfg. Complete next steps in the wizard.
VM will launch. Configure partitioning, continue with installation. Watch Anaconda progress.
After installation and reboot, log in to the installed VM and observe state of the system. Read Anaconda logs. Also, you can perform a oscap scan of the installed system.

Review hints:

Start by reading the proposed user manual text in the PR.

This fix type will be used to generate RHEL kickstarts to support unattended installation of hardened RHEL systems.

If a like starts with packages, services or post, it will be added to the respective Kickstart section.

You can't scan the machine that you will install using the generated kickstart (to scan it it would already have to be installed). Therefore it doesn't make sense to generate kickstarts for results. For simplicity we will disable this feature.

This header will put some common options that are sensible for every RHEL kickstart. The purpose to make the installation easier and set sensible defaults. The code has been taken from ComplianceAsCode/content RHEL 9 CIS Kickstart.

We will run an oscap scan in the post phase, therefore we need to install openscap and scap-security-guide to be able to run the oscap scan.

Instead of hard-coded "xccdf-file.xml" we will show the real input SCAP file name in the kenerated remediations.

This will give us the correct file name for most situations.

comps · 2024-07-10T15:24:36Z

I don't see it currently in the code, but note that an Anaconda kickstart can have multiple %packages sections, so we could have our own, independent of whatever the user wants to add in their own %packages.

This would allow us to use further options to %packages documented on https://pykickstart.readthedocs.io/en/latest/kickstart-docs.html#chapter-9-package-selection , like %packages --exclude-weakdeps (or --excludeWeakdeps to preserve RHEL-8 compatibility) to install the specified packages with minimum dependencies. Maybe something to consider.

Similarly, %post also has

%post [--erroronfail] [--interpreter /usr/bin/python] [--log LOG] [--nochroot]

and I imagine we'd definitely want --erroronfail, and perhaps --nochroot to use the Anaconda environment's tooling rather that the installed system tooling.
https://pykickstart.readthedocs.io/en/latest/kickstart-docs.html#chapter-6-post-installation-script

Also, what about the bootloader command? .. Presumably we don't want it just hardcoded in common_kickstart_header, but rather dynamic, so stuff like fips=1 can be added there (alongside other kernel command line options).

comps · 2024-07-10T15:25:54Z

src/XCCDF_POLICY/xccdf_policy_remediate.c

+"# --device	device to be activated and / or configured with the network command\n"
+"# --bootproto	method to obtain networking configuration for device (default dhcp)\n"
+"# --noipv6	disable IPv6 on this device\n"
+"network --onboot yes --device eth0 --bootproto dhcp --noipv6\n"


Just

network --onboot yes --bootproto dhcp

should be enough. The rest is autodetected by Anaconda.

comps · 2024-07-10T15:27:18Z

src/XCCDF_POLICY/xccdf_policy_remediate.c

+"# Configure firewall settings for the system (optional)\n"
+"# --enabled	reject incoming connections that are not in response to outbound requests\n"
+"# --ssh		allow sshd service through the firewall\n"
+"firewall --enabled --ssh\n"


I'm pretty sure we can remove this - our testing runs without the firewall command as Anaconda by default installs firewalld, and installing the openssh-server package adds port 22 to it seamlessly.

comps · 2024-07-10T15:35:45Z

Do we really want a very verbose kickstart file as an output, giving the user many options to customize it (url/cdrom/harddrive), explaining every option?

Why not just point to https://pykickstart.readthedocs.io/en/latest/kickstart-docs.html (or the RHEL version of it, ie. https://docs.redhat.com/en-us/documentation/red_hat_enterprise_linux/8/pdf/system_design_guide/Red_Hat_Enterprise_Linux-8-System_Design_Guide-en-US.pdf - APPENDIX J ) and let the user figure out what they need for their specific setup ?

jan-cerny · 2024-07-11T07:26:45Z

@comps great ideas! thanks a lot!

jan-cerny · 2024-07-11T07:30:57Z

src/XCCDF_POLICY/xccdf_policy_remediate.c

+	char *basename = oscap_basename(dup);
+	free(dup);
+	char *oscap_command = oscap_sprintf(
+		"oscap xccdf eval --remediate --profile '%s' /usr/share/xml/scap/ssg/content/%s\n",


This will work sometimes, but sometimes it won't work. How do we ensure that the file is the same as the file that the user provided to oscap when generating the kickstart? And even a bigger problem, what if the user used a tailoring when generating the kickstart?

This is why we need to at least fix this: #771.

Amazing! I didn't know that we have issue for that. Great news is that the issue is already "accidentally" fixed in this PR! The headers now contain actual file path of the file used as input to the oscap xccdf generate fix command.

The knowledge of the actual input file path is also reused in this place. Here, I take its base name and concatenate it with the well-known scap-security-guide directory path. This way I achieved that it will work sometimes. The sometimes specifically means that 1. user uses a data stream from the scap-security-guide package to generate the KS and 2. the version of the scap-security-guide package used to generate the KS is the same that will be installed on the installed system and 3. user doesn't use tailoring when generating the KS. If any of the three conditions isn't true then it won't work or will give surprising results. I think that's insufficient therefore I opened this comment.

I have this proposal how to solve this problem. We will document that the recommended workflow is to serve the SCAP source data stream and the optional XCCDF tailoring file on a web server. Then, the generated kickstart will contain a command to download these files from the server. We will not install scap-security-guide package during the installation. This way it will make sure that the same files are used for both kickstart generation before installation and remediation during installation. The generated kickstart can contain placeholders for the content URI and comments highlighting it. Also, we can have a CLI option that would get propagated to the generated kickstart. The key thing would be to have the workflow well documented.

Another proposal has been suggested by @dahaic : The kickstart would explicitly request the specific version of scap-security-guide RPM package to be installed. The package would be fetch from CDN. This way we would ensure that the same data stream is used for the remediation as is used for the kickstart generation. The tailoring file could be inserted in a form of base64 blob or in a form of autotailor command.

It'd be nice to actually have just a full path here for the content. We don't care much about non-packaged DSes. It's up to the advanced customer to figure out how they want to fetch, store and use it (we can give an example in the docs, though).

If we can somehow embed tailoring (when --tailoring option is provided along with generate fix) and generate proper KS that would use it without requiring the user to serve it separately — it would be very nice, but let's not concentrate on it before everything else is complete.

If we could be able to bring tailoring into the remediation generator context it will help us to also generate self-contained tailored Blueprints.

The generator will consume `logvol` commands and put them into the output kickstart files. This will be used in rules for partitions, for example in the `partition_for_var` rule.

comps · 2024-07-15T12:00:13Z

src/XCCDF_POLICY/xccdf_policy_remediate.c

+"# Initialize (format) all disks (optional)\n"
+"zerombr\n"
+"\n"
+"# The following partition layout scheme assumes disk of size 20GB or larger\n"
+"# Modify size of partitions appropriately to reflect actual machine's hardware\n"
+"#\n"
+"# Remove Linux partitions from the system prior to creating new ones (optional)\n"
+"# --linux	erase all Linux partitions\n"
+"# --initlabel	initialize the disk label to the default based on the underlying architecture\n"
+"clearpart --linux --initlabel\n"


I would replace this with

zerombr clearpart --all --initlabel reqpart

since zerombr + clearpart --linux doesn't make sense, ... and since we definitely want reqpart which adds EFI partition(s) on x86_64, and PReP boot partition on IBM POWER.

Note that reqpart also has --add-boot, which would nicely add /boot for us, but then we couldn't specify --fsoptions for it, so we can't really use it.

great idea ! thanks

So far, these large blobs have been only copy-pasted from the kickstarts that we have in upstream without any thinking. It's definitely something that we should investigate and change.

Default options for /boot are OK, oscap will remediate them in post section.

- network device should be autodetected by Anaconda - firewalld is added seamlessly to the port 22 - combination zerombr + clearpart --linux doesn't make sense

We will have a dedicated post section for compliance hardening. This section will fail if oscap command fails. It helps us prevent partially or wrongly hardened systems.

The intention is to be able to perform the installation fully automatically without manual intervention during the installation process. We will add sensible default values to the kickstart so that Anaconda won't ask for setting these options.

We will add a fallback partition layout for profiles that don't specify partitioning layout, for example RHEL 9 PCI-DSS profile. We need to specify at least some layout in the kickstart to make the installation fully automated.

jan-cerny · 2024-07-25T09:13:50Z

I have changed the %post section to fail if the oscap remediation fails. I have added default values that ensure fully automated installation. The default values include also partition defaults which will be added to the kickstart if the SCAP profile doesn't specify any partition requirement, which means automated installation for these profiles as well.

comps · 2024-07-25T10:48:32Z

I have changed the %post section to fail if the oscap remediation fails. I have added default values that ensure fully automated installation. The default values include also partition defaults which will be added to the kickstart if the SCAP profile doesn't specify any partition requirement, which means automated installation for these profiles as well.

You might want to read my post more carefully - I mentioned that lang and others are "required" by documentation, but not actually required, and I provided a full example kickstart that works and doesn't need lang or keyboard or timezone, but you added them anyway -- was that intentional?

Also, for profiles without partitions, maybe autopart (default) would be better, ie.

const char *fallback_partition = (
	"# Create partition layout scheme\n"
	"zerombr\n"
	"clearpart --all --initlabel\n"
	"autopart --type=lvm\n"
);

mildas · 2024-07-25T11:43:56Z

%post --erroronfail
oscap xccdf eval --remediate ...
[ $? -eq 0 -o $? -eq 2 ]
%end

If I got --erroronfail correctly, it will terminate right at the failed command. Thus, if oscap returns 2 (something failed to be remediated or missing remediation), it will terminate installation at that oscap line and won't [ $? -eq 0 -o $? -eq 2 ].
Shouldn't it be rather something like

%post --erroronfail
oscap xccdf eval --remediate ... || [ $? -eq 2 ]
%end

@comps ?

jan-cerny · 2024-07-25T11:46:34Z

You might want to read my post more carefully - I mentioned that lang and others are "required" by documentation, but not actually required, and I provided a full example kickstart that works and doesn't need lang or keyboard or timezone, but you added them anyway -- was that intentional?

The important thing here is to distinguish between a kickstart that works and kickstart that enables a fully automated installation. Without the options I added today, the kickstart works (it worked even yesterday), but the installation isn't fully automated, because the user needs to configure the options in the Anaconda during installation.

For example, if you remove the "lang" keyword from the kickstart, the Anaconda will ask you which language you want to use during the installation and you have to click and choose one to proceed. But if there are all the options I added, the installation doesn't require any user interaction in the whole process and goes fully automatically.

To simplify the code, we can use the "autopart" command.

jan-cerny · 2024-07-25T12:34:07Z

I have used the autopart

comps · 2024-07-25T12:53:46Z

If I got --erroronfail correctly, it will terminate right at the failed command. Thus, if oscap returns 2 (something failed to be remediated or missing remediation), it will terminate installation at that oscap line and won't [ $? -eq 0 -o $? -eq 2 ].

Right, but that doesn't do set -e in the shell. And the shell will ignore the first failure, and exit with whatever exit code the last command returned.

$ bash -c 'ls /nonexistent'; echo $?
ls: cannot access '/nonexistent': No such file or directory
2

--erroronfail simply means "if the shell returned non-0, abort the installation"".

So my version should still work. Yours works too, but I don't think it would gain us anything.

For example, if you remove the "lang" keyword from the kickstart, the Anaconda will ask you which language you want to use during the installation and you have to click and choose one to proceed. But if there are all the options I added, the installation doesn't require any user interaction in the whole process and goes fully automatically.

Hmm, interesting, because for me, it works fully automatically even without them.

I guess it doesn't ultimately matter, but you could replace the options with

text --non-interactive

to force automated install, but either way works.

mildas · 2024-07-25T13:26:36Z

--erroronfail simply means "if the shell returned non-0, abort the installation"".

Okay, in that case your solution is fine. But then there's assumption that

oscap xccdf eval --remediate ...
[ $? -eq 0 -o $? -eq 2 ]

will be the last 2 commands in %post. Are we sure it will be like that? Will post command remediation add commands BEFORE oscap xccdf eval? And what about customers adding more stuff to %post? Because for that I miss exit 1 there.

comps · 2024-07-25T13:31:43Z

will be the last 2 commands in %post. Are we sure it will be like that? Will post command remediation add commands BEFORE oscap xccdf eval? And what about customers adding more stuff to %post? Because for that I miss exit 1 there.

A kickstart will typically have more %post sections, all of them run independently in separately executed shells (or --interpreters).

I guess we can change it to

[ $? -eq 0 -o $? -eq 2 ] || exit 1

for extra safety in case someone adds more code to our %post section.

Options for bootloader sometimes aren't in the form 'option=value' and so they sometimes don't contain '='. This commit clarifies the documentation about the bootloader command with regards to this fact. Also, it adds a simple test for this command.

* Concatenate 2 strings * Convenience wrapper over strncat.

If a line in kickstart remediation starts with `%post`, that line and all following lines until a line starting with `%end` are considered a block. Blocks are propagated to the output without any processing.

If an user doesn't provide `--profile`, the default XCCDF profile is used which is the standard behavior of all oscap xccdf modules. However, the generated remediation doesn't reflect that. This commit fixes it, namely the generated "oscap" commands.

jan-cerny · 2024-07-29T13:23:49Z

I have add exit 1, add ability to consume custom %pre and %post sections, add ability to disable kdump and solved the situation when --profile isn't provided. Then, I have improved the user manual changes.

jan-cerny · 2024-07-31T08:22:41Z

/packit build

evgenyz

Okay, there is nothing I would like to change immediately, although we might have some adjustments after getting some feedback from stakeholders (and more experiments with CI etc). I consider it good enough for the first implementation.

Thank you!

jan-cerny added 19 commits July 10, 2024 11:23

Introduce new fix type kickstart

b47e1c4

This fix type will be used to generate RHEL kickstarts to support unattended installation of hardened RHEL systems.

Add a generic header for Kickstarts

9d37973

Add a simple data stream with a Kickstart remediation

e9e0067

Use a special function to generate kickstarts

3a0601b

Generate post section with oscap running

c8b2418

Add a method to triage different kickstart fixes

e114913

Add multiple rules to the example data stream

aa92f56

Triage lines to Kickstart sections

87cd691

If a like starts with packages, services or post, it will be added to the respective Kickstart section.

Add a simple test for Kickstart fix

c62a905

Document generating kickstarts in user manual

e366cbc

Add a common kickstart header

7907dd8

This header will put some common options that are sensible for every RHEL kickstart. The purpose to make the installation easier and set sensible defaults. The code has been taken from ComplianceAsCode/content RHEL 9 CIS Kickstart.

Make sure openscap and scap-security-guide are installed

0d223e7

We will run an oscap scan in the post phase, therefore we need to install openscap and scap-security-guide to be able to run the oscap scan.

Add a comment

eaf2cac

Show a correct input file name

bf6f111

Instead of hard-coded "xccdf-file.xml" we will show the real input SCAP file name in the kenerated remediations.

Extract function _generate_kickstart_services

e31d82f

Extract function _generate_kickstart_packages

90a90bf

Extract function _generate_kickstart_post

95c8728

Improve the file name of oscap command

ab946f6

This will give us the correct file name for most situations.

jan-cerny added this to the 1.4 milestone Jul 10, 2024

jan-cerny mentioned this pull request Jul 10, 2024

Introduce new remediation type Kickstart ComplianceAsCode/content#12144

Merged

comps reviewed Jul 10, 2024

View reviewed changes

jan-cerny commented Jul 11, 2024

View reviewed changes

Add ability to define logical partitions

b212b7c

The generator will consume `logvol` commands and put them into the output kickstart files. This will be used in rules for partitions, for example in the `partition_for_var` rule.

comps reviewed Jul 15, 2024

View reviewed changes

Improve hardcoded items

a39161c

- network device should be autodetected by Anaconda - firewalld is added seamlessly to the port 22 - combination zerombr + clearpart --linux doesn't make sense

jan-cerny added 3 commits July 25, 2024 10:04

Fail if remediation fails

fe831b8

We will have a dedicated post section for compliance hardening. This section will fail if oscap command fails. It helps us prevent partially or wrongly hardened systems.

Add a default partition layout

563cf6b

We will add a fallback partition layout for profiles that don't specify partitioning layout, for example RHEL 9 PCI-DSS profile. We need to specify at least some layout in the kickstart to make the installation fully automated.

Add an empty line to the user manual

3c2e679

Use autopart in the default partition option

509460b

To simplify the code, we can use the "autopart" command.

jan-cerny added 4 commits July 25, 2024 15:54

Add exit 1

0e8a0f5

Improve the bootloader command

fd16278

Options for bootloader sometimes aren't in the form 'option=value' and so they sometimes don't contain '='. This commit clarifies the documentation about the bootloader command with regards to this fact. Also, it adds a simple test for this command.

Introduce function oscap_concat

24ade05

* Concatenate 2 strings * Convenience wrapper over strncat.

Add ability to specify post sections

fcf313a

If a line in kickstart remediation starts with `%post`, that line and all following lines until a line starting with `%end` are considered a block. Blocks are propagated to the output without any processing.

jan-cerny force-pushed the generate_kickstart branch from 9b6eb9a to fcf313a Compare July 26, 2024 12:12

jan-cerny added 6 commits July 26, 2024 15:46

Add support for %pre section

f37d15f

Fail if there is an unfinished section in the remediation

b90aa34

Improve User manual

b6970de

Add ability to disable kdump

1765199

Fix rule title

523f842

jan-cerny marked this pull request as ready for review July 29, 2024 13:24

evgenyz approved these changes Jul 31, 2024

View reviewed changes

evgenyz merged commit 5c0235b into OpenSCAP:main Jul 31, 2024
16 of 17 checks passed

evgenyz mentioned this pull request Jul 31, 2024

Advertise path to SSG in remediation scripts #771

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Introduce ability to generate kickstarts #2136

Introduce ability to generate kickstarts #2136

jan-cerny commented Jul 10, 2024 •

edited

Loading

comps commented Jul 10, 2024

comps Jul 10, 2024

comps Jul 10, 2024

comps commented Jul 10, 2024

jan-cerny commented Jul 11, 2024

jan-cerny Jul 11, 2024

evgenyz Jul 11, 2024

jan-cerny Jul 12, 2024

jan-cerny Jul 15, 2024

jan-cerny Jul 15, 2024

evgenyz Jul 17, 2024

evgenyz Jul 17, 2024

comps Jul 15, 2024

jan-cerny Jul 15, 2024

evgenyz Jul 17, 2024

jan-cerny commented Jul 25, 2024

comps commented Jul 25, 2024 •

edited

Loading

mildas commented Jul 25, 2024

jan-cerny commented Jul 25, 2024

jan-cerny commented Jul 25, 2024

comps commented Jul 25, 2024 •

edited

Loading

mildas commented Jul 25, 2024

comps commented Jul 25, 2024

jan-cerny commented Jul 29, 2024

jan-cerny commented Jul 31, 2024

evgenyz left a comment

Introduce ability to generate kickstarts #2136

Introduce ability to generate kickstarts #2136

Conversation

jan-cerny commented Jul 10, 2024 • edited Loading

Rationale:

How to test:

Review hints:

comps commented Jul 10, 2024

Choose a reason for hiding this comment

Choose a reason for hiding this comment

comps commented Jul 10, 2024

jan-cerny commented Jul 11, 2024

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jan-cerny commented Jul 25, 2024

comps commented Jul 25, 2024 • edited Loading

mildas commented Jul 25, 2024

jan-cerny commented Jul 25, 2024

jan-cerny commented Jul 25, 2024

comps commented Jul 25, 2024 • edited Loading

mildas commented Jul 25, 2024

comps commented Jul 25, 2024

jan-cerny commented Jul 29, 2024

jan-cerny commented Jul 31, 2024

evgenyz left a comment

Choose a reason for hiding this comment

jan-cerny commented Jul 10, 2024 •

edited

Loading

comps commented Jul 25, 2024 •

edited

Loading

comps commented Jul 25, 2024 •

edited

Loading