On Thu, Jul 11, 2024 at 10:57 AM Vit Mojzis <vmojzis@xxxxxxxxxx> wrote: > > Hello, > I'm trying to address a known "issue" where SELinux context of files in > SELinux store gets changed on policy rebuild. This triggers some system > verification tools and unnecessarily raises concerns in users. > I created a patch using getfilecon and setfscreatecon, but am not sure > if this is the best approach since it will not fix a context that has > already been changed. Also, any files created as a result of execve > need to be addressed separately (e.g. file_contexts.bin), maybe using > selabel_lookup to get the proper label since that way sefcontext_compile > does not need to know the path to the SELinux store (only to sandbox). > I considered relabeling the whole sandbox before semanage_commit_sandbox, > but that seems wasteful. Would a name-based type transition work? This would avoid the need for any code changes (to libsemanage or sefcontext_compile). Otherwise, I think doing a selabel_lookup() followed by setfscreatecon() makes the most sense if you want to ensure that the file has the correct label at creation time, or calling selinux_restorecon(3) on the file after it is created prior to copying data to it would be even simpler. > Then there is a related issue where the rebuild is performed as a > non-root user, causing files in the policy store to change ownership. > \# capsh --user=testuser --caps="cap_dac_override+eip cap_setpcap+ep" --addamb=cap_dac_override -- -c "semodule -B" > This can actually cause issues in some scenarios (e.g. remote login failing). > Addressing this seems to require more drastic measures. My attempts to > use "chown" failed, even with the CAP_CHOWN capability and using > seteuid/setegid does not seem safe. Any suggestions would be > appreciated. setfsuid() is a safer option than seteuid() for filesystem operations, but what is preventing the chown() from working?
