This means that:
1) When deploying images with GPT partitions labelled correctly, they can be immediately mounted into an agent.
2) When cleaning a machine which had properly labelled GPT partitions on disk, these partitions will be mounted on boot, before cleaning begins.
This gives the potential for Remote Code Execution in the IPA ramdisk, as a user could craft a filesystem to be mounted in the paths systemd looks for units in, and have those units run. In fact, in some situations, this could lead to existing or newly created units (such as the IPA unit itself) being overridden.
To fix this, we'll have to modify the CoreOS image during build to disable this autogenerator. This can be done in the current supported version of CoreOS by `chmod 000 /lib64/systemd/system-generators/systemd-gpt-auto-generator` during the image build process.
When the CoreOS image is upgraded to a newer version, we should utilize the masking behavior: https://cgit.freedesktop.org/systemd/systemd/commit/?id=e801700e9a to disable the autogenerator as well. (This is not supported in systemd 212, the version currently shipped by IPA).
Additionally, there is a functionality bug as well; when this udev event triggers, it causes a remount event which causes all mounts to remount, including those to support the IPA chroot. This would cause cleaning or deploys to fail in these cases. However, as noted above, this does not mitigate the vulnerability in chroot'd IPA ramdisks as the entire set of units used to spawn IPA could be overridden by a well-crafted partition table + filesystem.
The systemd shipped in the upstream, published IPA CoreOS image contains enabled support for automounting GPT partitions marked with the proper GUID (https:/ /www.freedeskto p.org/software/ systemd/ man/systemd- gpt-auto- generator. html). This automount is triggered by udev anytime GPT partitions are detected.
This means that:
1) When deploying images with GPT partitions labelled correctly, they can be immediately mounted into an agent.
2) When cleaning a machine which had properly labelled GPT partitions on disk, these partitions will be mounted on boot, before cleaning begins.
This gives the potential for Remote Code Execution in the IPA ramdisk, as a user could craft a filesystem to be mounted in the paths systemd looks for units in, and have those units run. In fact, in some situations, this could lead to existing or newly created units (such as the IPA unit itself) being overridden.
To fix this, we'll have to modify the CoreOS image during build to disable this autogenerator. This can be done in the current supported version of CoreOS by `chmod 000 /lib64/ systemd/ system- generators/ systemd- gpt-auto- generator` during the image build process.
When the CoreOS image is upgraded to a newer version, we should utilize the masking behavior: https:/ /cgit.freedeskt op.org/ systemd/ systemd/ commit/ ?id=e801700e9a to disable the autogenerator as well. (This is not supported in systemd 212, the version currently shipped by IPA).
Additionally, there is a functionality bug as well; when this udev event triggers, it causes a remount event which causes all mounts to remount, including those to support the IPA chroot. This would cause cleaning or deploys to fail in these cases. However, as noted above, this does not mitigate the vulnerability in chroot'd IPA ramdisks as the entire set of units used to spawn IPA could be overridden by a well-crafted partition table + filesystem.