How can an SELinux filesystem be relabeled in an unpacked squashfs filesystem?

Question

I am trying to configure selinux for a live boot Debian system.

SELinux is inoperable due to copious changes during build and system configuration and requires the entire filesystem to be relabeled. This must be accomplished at build with filesystem as unpacked squashfs file, from inside chroot or systemd-nspawn or from host system.

No way has yet been found to successfully accomplish this. The /etc/selinux/default/contexts/files/file_contexts.subs_dist file is supposed to alias filesystem targets behind filesystem locations, but an attempt to use this to redirect the host filesystem to the unpacked squash system during SELinux relabeling did not work: SELinux continued to relabel the host filesystem, and squashfs filesystem was cited as unknown filetypes.

Is there a simple way to relabel a filesystem for SELinux in squashfs?

Answer 1

Currently this problem has no known solution I have been able to find, though I am sure it should be possible to operate SELinux in or on a writable unpacked squashfs.

Otherwise, one live build solution is to build manually using debootstrap, without isolinux at this stage and thus no squashfs or iso, adding kernel and packages; then boot this writable Debian to USB key or boot in a virtual guest; then run the SELinux relabeling for the filesystem. Once this is done, the build process can be continued from isolinux to squashfs, iso and the usual, non-writable hybrid system.

The writable method is outlined here:

https://vdmit.org/linux/debian-live-usb-debootstrap.html

The advantageous, non-writable hybrid manual build - the manual method otherwise attempted automated with the Debian live-build scripting - is outlines here:

https://l3net.wordpress.com/2013/09/21/how-to-build-a-debian-livecd/

The only drawback of this method is that the complete configuration must be present at the debootstrap stage, as it will be in the bootable hybrid system, for the labeling to be correct, and that no method continues to be available to relabel an unpacked squash, which I regard as unacceptable as squashfs may need to be edited after build.

Additional objects imported with config-hooks of course require appropriate or custom contexts or permissive contexts labeled after boot, but this is a minor task of little RAM consumption.

Otherwise, this is still an open question.