When creating a policy with semodule when cross-compiling, utilities on the host are accessed.

[aduskett]

Hello;

I am working on cleaning up the refpolicy package for the Buildroot project.
Currently, our refpolicy package only builds a monolithic policy, however, I would
like to add the possibility to build a modular policy.

In the context of Buildroot, there are three places where packages are installed:

• host
• staging
• target

When running semodule -p output/target -s targeted -n -B, semodule calls out to libsemanage and tries to open three utilities on the host filing system that are hardcoded:

/sbin/load_policy
/sbin/setfiles
/sbin/sefcontext_compile

If these files do not exist on the host, then semodule will crash with a file not found error, even if these files do exist in output/host/sbin.

I am aware that I could set these paths in output/target/selinux/semanage.conf, however, this is not ideal because then the paths would either point to either two locations:
output/host/sbin which would then break during runtime on the target.
output/target/sbin which would then point to possibly files of the wrong architecture.

If I manually patch libsemanage/src/conf-parse.y and change the hardcoded paths to output/host/sbin then semodule -p output/target -s targeted -n -B works properly.

I am not sure what the best way to proceed would be, so I wanted to ask the maintainers themselves.

My first idea is either an argparse value in semodule that allows someone to overwrite the host-utilities base directory.

My next idea would be much like the meson project and support a cross-compile.conf file of some sort of which libsemanage could look.

Any ideas?

Edit:
If anybody is interested in reproducing the error, I have a git project setup for this very issue:

git clone https://github.com/aduskett/buildroot-docker-devel.git
cd buildroot-docker-devel/CentOS/7/
docker-compose build
git clone https://gitlab.com/aduskett/buildroot.git -b selinux-enforcing
docker run --name=br-centos7  -v $(pwd):/mnt -ti br-centos7 /bin/bash
cd /mnt/buildroot
make qemu_x86_64_selinux_modular_defconfig
make refpolicy

Right now the refpolicy.mk file doesn't pick up on the policy files on first target_install, so after make refpolicy you will have to do the following:

rm output/build/refpolicy-2.20190609/.stamp_target_installed; make refpolicy

Sorry about that!

Centos7's base docker image doesn't come with selinux utilities, although I am positive this would also fail on Debian or Ubuntu as well.

This should reproduce the problem.

Thanks!
Adam

[stephensmalley]

A new semodule command-line option along with corresponding libsemanage support for changing the path prefix for the host utilities makes sense to me. However, be aware that load_policy should never be run at all in the cross-compile scenario and should already be suppressed via -n and sefcontext_compile output is now arch-dependent when using pcre2 (libselinux however recognize a mismatch and ignore the precompiled regexes if they do not match, or you can specify -r as an argument to omit them entirely as is done in Fedora's semanage.conf).

[aduskett]

Thanks for the information!

I set up a new branch, and before I made a fool of myself and submit this to the mailing list, if it's not too much trouble could you take a look at my modifications?

My C skills are rusty at best, but this does work and Valgrind doesn't show any leaks.
https://github.com/aduskett/selinux/commit/1a270bc31a6aa15e1414e4e6c069d58477b3c438

Thanks so much!

Adam

[stephensmalley]

Looks basically sane, just need to check error returns for asprintf() and semanage_set_host_utils() and deal with them appropriately. Post to [email protected] using git send-email or ask a maintainer to do so if you are unable.

[aduskett]

Thanks for the review! I can add those now and then post them to the mailing list.

[stephensmalley]

Are you still planning on updating this and submitting it?

[aduskett]

Hey! Sorry for the radio silence. I do plan to work on this, I have just been a bit busy at work. I am planning on going to FOSDEM next week and then working with the Buildroot team to hammer this out.