Open jlebon opened 5 months ago
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
Testing this temporary workaround:
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).
There are additional denials too on selinux-policy > 38.1.36:
Unable to create stuff in /etc:
May 23 19:14:52 localhost kernel: audit: type=1400 audit(1716491692.577:4): avc: denied { write } for pid=927 comm="mkdir" name="etc" dev="loop0" ino=131 scontext=system_u:system_r:coreos_installer_t:s0 tcontext=system_u:object_r:etc_t:s0 tclass=dir permissive=0
This comes from https://github.com/coreos/coreos-installer/blob/6cae7770dcd37f3dd69931212f46f9e7ef7518a2/scripts/coreos-installer-disable-device-auto-activation#L10.
Unable to run udevadm:
May 23 19:14:54 localhost.localdomain coreos-installer-service[1082]: /usr/libexec/coreos-installer-service: line 133: udevadm: command not found
May 23 19:14:54 localhost.localdomain kernel: audit: type=1400 audit(1716491694.014:5): avc: denied { getattr } for pid=1067 comm="coreos-installe" path="/usr/bin/udevadm" dev="loop1" ino=3712 scontext=system_u:system_r:coreos_installer
_t:s0 tcontext=system_u:object_r:udev_exec_t:s0 tclass=file permissive=0
May 23 19:14:54 localhost.localdomain kernel: audit: type=1400 audit(1716491694.014:6): avc: denied { getattr } for pid=1067 comm="coreos-installe" path="/usr/bin/udevadm" dev="loop1" ino=3712 scontext=system_u:system_r:coreos_installer
_t:s0 tcontext=system_u:object_r:udev_exec_t:s0 tclass=file permissive=0
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 https://github.com/fedora-selinux/selinux-policy/commit/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 if a new issue appears now, please file a bug
coreos-installer is confined in Fedora since 1 year ago and in RHEL 9 since 9.4 issues.redhat.com/browse/RHEL-5164
To clarify, when I say "delta", I'm referring specifically to https://github.com/fedora-selinux/selinux-policy/commit/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?
if a new issue appears now, please file a bug
All changes are almost always put to Fedora first. Since the last rebase, these branches have separate development. For RHEL 9, I can confirm it as this:
commit 9caf659df2c829beceadcd41e446cb58f5770021
Author: Zdenek Pytela <zpytela@redhat.com>
Date: Tue Nov 22 10:46:45 2022 +0100
* Mon Nov 21 2022 Zdenek Pytela <zpytela@redhat.com> - 38.1.1-1
- Rebase selinux-policy to the latest one in rawhide
Resolves: rhbz#2082524
Have the same confusion, we remove coreos_installer_t
permissive domain on c9s
, not on rawhide
, should we have the change on rawhide
first?
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 kola testiso
tests passed, realized that was expected as it was the permissive mode, if remove permissive mode, then a lot of things broken, will collect the denied logs and put it in https://issues.redhat.com/browse/RHEL-38614
There is restriction for characters in jira, so put all the coreos_installer_t
denied logs here (from fcos with selinux-policy-40.20-1.fc41.noarch (fedora-rawhide)
, which might be the same as c9s).
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 init_t
, but I would expect a generic shared type (e.g. systemd_generator_t
) and only have generator-specific labels if it truly requires it. Usually, a generator will just read state from somewhere and generate systemd units/symlinks in /run/systemd/
(this is also enforced by systemd now in v253, which is in c10s at least). A type for this should be safe to apply to most generators, including coreos-installer.
For testing, I've just written https://github.com/coreos/coreos-assembler/pull/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:
[ 8.718476] audit: type=1400 audit(1718805526.519:7): avc: denied { map_read map_write } for pid=931 comm="coreos-installe" scontext=system_u:system_r:coreos_installer_t:s0 tcontext=system_u:system_r:init_t:s0 tclass=bpf permissive=0
...
[ 8.952784] ln:
[ 8.952787] failed to access '/run/systemd/generator/default.target'
[ 8.953053] : Permission denied
[ 8.955590]
[ 9.050233] (sd-exec-[928]: /usr/lib/systemd/system-generators/coreos-installer-generator failed with exit status 1.
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:
[ 15.551428] audit: type=1400 audit(1719315829.291:4): avc: denied { create } for pid=1328 comm="systemd-network" name=".#networkhsYri0" scontext=system_u:system_r:systemd_network_generator_t:s0 tcontext=system_u:object_r:init_var_run_t:s0 tclass=file permissive=0
I'll file a separate Jira for that one.
Also now seeing systemd-network-generator failures:
[ 15.551428] audit: type=1400 audit(1719315829.291:4): avc: denied { create } for pid=1328 comm="systemd-network" name=".#networkhsYri0" scontext=system_u:system_r:systemd_network_generator_t:s0 tcontext=system_u:object_r:init_var_run_t:s0 tclass=file permissive=0
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.
Issues go stale after 90d of inactivity.
Mark the issue as fresh by commenting /remove-lifecycle stale
.
Stale issues rot after an additional 30d of inactivity and eventually close.
Exclude this issue from closing by commenting /lifecycle frozen
.
If this issue is safe to close now please do so with /close
.
/lifecycle stale
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 https://github.com/fedora-selinux/selinux-policy/commit/55e9ed8edf, i.e. https://github.com/fedora-selinux/selinux-policy/pull/2111, i.e. https://issues.redhat.com/browse/RHEL-22173.
/cc @zpytela