Add a policy for installkernel and dracut #1063
Conversation
| corecmd_exec_bin(dracut_t) | ||
| corecmd_exec_shell(dracut_t) | ||
| corecmd_mmap_all_executables(dracut_t) | ||
| corecmd_delete_all_executables(dracut_t) |
There was a problem hiding this comment.
What's happening here (the delete in particular)?
There was a problem hiding this comment.
Related: there's also deletions in the files_* block and others.
There was a problem hiding this comment.
What's happening here is installkernel creates the staging area for the initrd in /tmp. dracut copies all the binaries, shared libs, config files, etc. for all the components needed to boot the system to its own directory in the staging area. dracut also relabels all the files to the correct type so that the SELinux contexts inside of the initrd are correct. After the initrd is created, dracut recursively deletes this temporary directory and all its contents.
The delete access here is a rather unfortunate byproduct of the fact that these objects are copied and then deleted while having their destination SELinux contexts.
There was a problem hiding this comment.
Can you file a bug to have it use mv/install -Z? I would prefer to have a comment in the policy with a reference to a bug.
There was a problem hiding this comment.
I don't mind submitting an issue about the current behavior, but I'm not sure what mv/install -Z will do that is different from what is here currently. Let me know if I am misunderstanding something.
I think our shared concern is that the policy permits the deletion of sensitive files (e.g. shadow_t), so I think what we might really want is for dracut to be in a different domain that can only normally be transitioned to from dracut_t that does the cleanup, e.g. dracut_cleanup_t, and this domain is what is permitted to delete these files.
There was a problem hiding this comment.
If they use install -Z then it would be getting the expected label as it is written out, without having to label it in the tmp dir.
There was a problem hiding this comment.
Ah, I see now. I'll do some investigating. If the change is easy enough then we might be able to just submit a patch.
Signed-off-by: Kenton Groombridge <concord@gentoo.org>
Upstreaming current version of the dracut policy from Gentoo. Signed-off-by: Kenton Groombridge <concord@gentoo.org>
Signed-off-by: Kenton Groombridge <concord@gentoo.org>
Signed-off-by: Kenton Groombridge <concord@gentoo.org>
dracut uses fsfreeze when building an initrd. Signed-off-by: Kenton Groombridge <concord@gentoo.org>
Upstream a change from Gentoo to allow readers of udev rules runtime dir access to read udev rules in /run/udev/rules.d. Signed-off-by: Kenton Groombridge <concord@gentoo.org>
0xC0ncord
force-pushed
the
installkernel-dracut
branch
from
fe293d4 to
88e9a96
Compare
|
Also upstreamed some minor adjustments to the
|
| ## </summary> | ||
| ## </param> | ||
| # | ||
| interface(`portage_read_config',` |
There was a problem hiding this comment.
Please split to portage_read_config and portage_mmap_read_config.
2 participants
Pull in the
dracutpolicy module from Gentoo and get it working with modern systems. For this, we:dracutpolicy module as-is from Gentoo.installkernel. This tool is used on several distros (including Gentoo) as a helper for calling the necessary utilities for installing a kernel. In our case, this tool can be used to call intodracut.dracutmodule to get it working as needed.The workflow I tested is installing a hostonly kernel via the kernel's
make install, which callsinstallkerneland thendracut. Happy to share thedracutconfig if needed.Normally
dracuthas helper scripts that get installed by other system tools (e.g. ZFS) that allow it to handle installing those components as needed. I only tested the tools that I am using personally, so there may be others that need looking into as well.