package: Apply install_exec_t SELinux file context to kiwi executables

[Conan-Kudo]

This ensures that the kiwi executable is labeled such that it works properly in SELinux enforcing mode.

[Conan-Kudo]

This is an alternative to #2756 that does the bare minimum.

[dcermak]

I have asked the security team for a review, but they won't be able to do so until next week. Please hold unless you absolutely must merge this week

[Conan-Kudo]

Note that if SUSE security rejects this, then I will simply just exclude it from SUSE distributions.

[Conan-Kudo]

The other option would be to create an SELinux policy module similar to what the osbuild folks have. They define a domain for osbuild and then make it an unconfined domain.

[rfrohl]

Note that if SUSE security rejects this, then I will simply just exclude it from SUSE distributions.

I think there was a bit of wrong understanding here: The SELinux team got a ping to look at this change , but we do not have time this week (as it is almost weekend here). The initial question I had was why this can not go into the general policy and is handled in %post/%postun instead ?

We simply would look at this next week to understand this better.

[rfrohl]

Is there a reason why this should not go into https://github.com/fedora-selinux/selinux-policy ? We use rawhide as our upstream and could simply add it there, if they are willing to take it.

Especially since you want to use the solution for multiple distributions, which I assume to mean Fedora. If it is added to the policy then it would be there already as well.

[Conan-Kudo]

Is there a reason why this should not go into https://github.com/fedora-selinux/selinux-policy ? We use rawhide as our upstream and could simply add it there, if they are willing to take it.

Especially since you want to use the solution for multiple distributions, which I assume to mean Fedora. If it is added to the policy then it would be there already as well.

I will probably send it there too, but there still will be lag for months (!!!) across CentOS, Fedora, and SUSE distributions before it will be available everywhere.

[rfrohl]

there still will be lag for months (!!!)

So you would remove the %post/%postun change again, once the policy change landed in all the relevant places ?

The change had a smell to it, which is why I engaged. Using just semanage to manage the new file context will be error prone. Depending on how the users manage their systems, the file context might disappear. Leading to bugs that are hard to figure out, and these might land on our table so I wanted to make sure that the goal of this change is well understood.

[Conan-Kudo]

Eventually it will be guarded out for distributions where the policy has been updated. Most likely it would be dropped for kiwi 11 next year.

[Conan-Kudo]

(But yes, I'm working on a policy module that will probably be contributed to fedora-selinux.)

[rfrohl]

Why is adding the fcontext need?

The change from https://github.com/OSInside/kiwi/pull/2756/files, introduced these file context in the kiwi-selinux module:

/usr/bin/kiwi			--	gen_context(system_u:object_r:install_exec_t,s0)
/usr/bin/kiwi-ng(.*)		--	gen_context(system_u:object_r:install_exec_t,s0)

By my understand the fcontext should be available. Am I missing something?

[rfrohl]

Ah i see, the change was declined.

[rfrohl]

Is the plan not to have a module and use the post/postun instead of a module?

[Conan-Kudo]

For now, yes. A module needs some more work before we go to that.

[rfrohl]

ok, thank you for being patient with my questions

[rfrohl]

So I could offer to backport any submission to fedora-selinux/selinux-policy into our selinux-policy. That I think would lead to a cleaner solution, then adding these fcontext manually during package install.

Which is really the main issue that I have with this change: that these fcontext's are not part of any policy and would only show up once the %post ran. That there is not even a separate selinux module will make this almost impossible to find. Therefor needing quite a bit of detail knowledge to find the root cause, if issues are reported.
edit: Plus if the user interacts with the policy in strange ways, then these additions could also be removed from the running policy.

[Conan-Kudo]

I could go back to #2756 approach, but I need to add a few more things to use that.

[rfrohl]

I could go back to #2756 approach, but I need to add a few more things to use that.

I think that would be cleaner. The benefit from that solution from my POV: it uses a standard approach that will be on peoples radar, even though modules that are not part of the main policy can be a problem in some ways, they are still better then dynamic change to the running policy of a system.

[Conan-Kudo]

Okay, I'll switch to that. Reopened that PR as draft and am closing this one.