Closed jeremycline closed 4 years ago
Yeah, if I read this correctly, we ran into the same issue just some weeks ago. osbuild now ships custom selinux policies which grant it mac_admin
. I am unsure whether this has hit F32, yet. @gicmo probably knows more on that?
Nevertheless, mac_admin
is definitely needed for custom selinux policies which are not available on the host-kernel. This is one of the things that leaks into any sandbox or container and little we can do about it. The mac_admin
policy avoids this, but at the same time grants way too broad permissions for the things required.
Yeah, if I read this correctly, we ran into the same issue just some weeks ago. osbuild now ships custom selinux policies which grant it
mac_admin
. I am unsure whether this has hit F32, yet. @gicmo probably knows more on that?
We do have a custom selinux policy, but we don't grant osbuild (i.e. osbuild_t
/osbuild_exec_t
) mac_admin
, but the custom policy allows the transitioning of setfiles
into setfiles_mac_t
via seutil_domtrans_setfiles_mac
. The latter has mac_admin
. Additionally we also allow transitioning from osbuild_t
to install_t
, which also has mac_admin
, which fixes the custom selinux (and thus unknown labels) issue for ostree
(which is install_exec_t
).
So this is all good.
Nevertheless,
mac_admin
is definitely needed for custom selinux policies which are not available on the host-kernel. This is one of the things that leaks into any sandbox or container and little we can do about it. Themac_admin
policy avoids this, but at the same time grants way too broad permissions for the things required.
For now we are ok. There is still the issue of cp
being just bin_t
and thus also unable to read and copy unknown labels but that can be fixed with the labeling cp
as install_exec_t
in the build root (see e80130a830c351b71e34d2e5b5e6e967e286bd9b).
The reason osbuild is failing here is very likely because for all of the selinux custom labelling to work, the binaries in the build root need to be labelled correctly, i.e. the build pipeline needs to have an SELinux stage, which osbuild-composer currently does not have. This is the plan though, and also to get it into the next release so it ends up in RHEL as well.
So this is either a dup of osbuild/osbuild#400 or we move it to composer?
Just checked, composer is not adding the SELinux stages in the build pipeline for Fedora 31, 32 yet, only RHEL. Pretty sure that is why you are seeing that issue. Moving to composer.
This should be fixed once #799 get merged. The PR is currently blocked by the fact that we test Azure upload only in Travis but the SELinux stage makes the image build fail when running on Ubuntu (Travis). Once the test is migrated to Jenkins, this PR should be ready to go.
On a Fedora 32 host with builds from the tip of osbuild my build fails with:
The root cause is:
The blueprint, generated by adding ejabberd-19.09.1-2.fc32:
ejabberd ships its own selinux policy which is what I assume is triggering this particular issue. Adjusting the SELinux policy with something like:
fixes the issue. https://selinuxproject.org/page/NB_ObjectClassesPermissions describes mac_admin as "Allow MAC configuration state changes. For SELinux allow contexts not defined in the policy to be assigned. This is called 'deferred mapping of security contexts' and is explained at: http://www.nsa.gov/research/selinux/list-archive/0805/26046.shtml".
The link is dead and I've not bothered digging in other archives for the explanation, but the brief description makes sense and sounds like a capability osbuild would need.