c9s: coreos-installer-generator hitting SELinux denials, breaking ISO tests #1514
Labels
lifecycle/stale
Denotes an issue or PR has remained open with no activity and has become stale.
Comments
|
Testing this temporary workaround: diff --git a/manifest-c9s.yaml b/manifest-c9s.yaml
index 47d773e..5577278 100644
--- a/manifest-c9s.yaml
+++ b/manifest-c9s.yaml
@@ -93,6 +93,11 @@ postprocess:
rm -f /etc/issue /etc/issue.net
ln -s /usr/lib/issue /etc/issue
ln -s /usr/lib/issue /etc/issue.net
+ - |
+ #!/usr/bin/env bash
+ set -xeuo pipefail
+ cd /usr/lib/systemd/system-generators
+ chcon --reference ostree-system-generator coreos-installer-generator
# Packages that are only in SCOS and not in RHCOS or that have special
# constraints that do not apply to RHCOS |
Ahhh right, this doesn't work because we do a final relabeling at commit time. I think let's just pin to the previous working selinux-policy package for now (selinux-policy-38.1.36). |
jlebon
added a commit
to mike-nguyen/os
that referenced
this issue
May 23, 2024
The latest selinux-policy breaks ISO tests: openshift#1514 Pin to the previous working version for now. To do this, introduce a new `overrides-c9s.yaml` manifest that we can use going forward when we need to pin to older versions.
|
There are additional denials too on selinux-policy > 38.1.36: Unable to create stuff in /etc: Unable to run udevadm: This comes from https://github.com/coreos/coreos-installer/blob/6cae7770dcd37f3dd69931212f46f9e7ef7518a2/scripts/coreos-installer-service#L133. Not sure... we could poke holes just for these though ISTM like coreos-installer should just run unconfined given that this isn't some long-running service daemon; it's an OS installer, which is naturally a very privileged thing. Also, is there a reason for the delta between c9s and Fedora? I'm not seeing fedora-selinux/selinux-policy@55e9ed8edf there. |
|
coreos-installer is confined in Fedora since 1 year ago and in RHEL 9 since 9.4 https://issues.redhat.com/browse/RHEL-5164 |
To clarify, when I say "delta", I'm referring specifically to fedora-selinux/selinux-policy@55e9ed8edf. E.g. comparing the c9s and rawhide branches of the selinux-policy repo: $ git diff origin/rawhide origin/c9s -- policy/modules/contrib/coreos_installer.*
diff --git a/policy/modules/contrib/coreos_installer.te b/policy/modules/contrib/coreos_installer.te
index d6c3a808e..ab720fa88 100644
--- a/policy/modules/contrib/coreos_installer.te
+++ b/policy/modules/contrib/coreos_installer.te
@@ -12,8 +12,6 @@ init_daemon_domain(coreos_installer_t, coreos_installer_exec_t)
type coreos_installer_unit_file_t;
systemd_unit_file(coreos_installer_unit_file_t)
-permissive coreos_installer_t;
-
########################################
#
# coreos_installer local policyIs that expected?
|
|
All changes are almost always put to Fedora first. Since the last rebase, these branches have separate development. |
mike-nguyen
pushed a commit
to mike-nguyen/os
that referenced
this issue
May 28, 2024
The latest selinux-policy breaks ISO tests: openshift#1514 Pin to the previous working version for now. To do this, introduce a new `overrides-c9s.yaml` manifest that we can use going forward when we need to pin to older versions. (cherry picked from commit 455ea2a)
|
Have the same confusion, we remove |
|
Sorry that I did some testing before based on https://issues.redhat.com/browse/COS-2227, thought that work well with the change as the |
|
There is restriction for characters in jira, so put all the coreos_installer_t denied logs |
|
You are right it should have happened in inverse order, but for independent products it cannot be considered a regression. Will be synced anyway in one of the next builds. |
|
I can assign a specific label for the generator if there is some easy deployable test, or if you can test coprbuilds which are a part of each selinux-policy PR. |
|
I think it makes sense to try to make systemd generators more confined than For testing, I've just written coreos/coreos-assembler#3819 which should help. However, unfortunately there's no great shortcut to testing changes to the ISO. You kinda have to rebuild it today. I added some docs there for that too. Though you can also post an RPM somewhere and we can test it. |
|
To be clear, also OK to have a dedicated label if that aligns better with some wider plan. Just making sure we're not creating more work for ourselves than we need to. |
|
Thanks, Jonathan, I'll give it a go. Actually, systemd_generic_generator_t is in place in Fedora rawhide already since 2 weeks ago. |
|
Looks like this is also hitting rawhide now: |
|
The first one is a different problem in libbpf with a workaround in systemd. The second one will probably be fixed with the next build, but without further information I cannot be sure. |
|
Also now seeing systemd-network-generator failures: I'll file a separate Jira for that one. |
|
This was referenced Jul 10, 2024
|
Looks like c9s composes are now failing because selinux-policy-38.1.36-1.el9 (the last working version) is no longer on the mirrors. |
|
Issues go stale after 90d of inactivity. Mark the issue as fresh by commenting If this issue is safe to close now please do so with /lifecycle stale |
openshift-ci
bot
added
the
lifecycle/stale
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Specifically, coreos-installer is prevented from writing to
/run/systemd/generator/. The type of the generator here looks suspect. It's one of the only generator which isn'tinit_exec_t:This looks like a regression from fedora-selinux/selinux-policy@55e9ed8edf, i.e. fedora-selinux/selinux-policy#2111, i.e. https://issues.redhat.com/browse/RHEL-22173.
/cc @zpytela
The text was updated successfully, but these errors were encountered: