-
Notifications
You must be signed in to change notification settings - Fork 104
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
c9s: coreos-installer-generator hitting SELinux denials, breaking ISO tests #1514
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). |
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:
This comes from https://github.com/coreos/coreos-installer/blob/6cae7770dcd37f3dd69931212f46f9e7ef7518a2/scripts/coreos-installer-disable-device-auto-activation#L10. 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 policy Is that expected?
|
All changes are almost always put to Fedora first. Since the last rebase, these branches have separate development.
|
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. |
|
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. |
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: