On Fri, Oct 20, 2017 at 12:34 AM, Nathan Owen <nathanowen42@xxxxxxxxx> wrote: > Hi Stephen, > > Thanks for the help. Based on the information you provided, I think we will try to make a modified version of restorecon which can run on the development PC, load a specified set of policies, and apply the correct xattrs to the files immediately before we invoke mksqaushfs. Since our development PCs do not yet use SElinux I do not think this should cause a problem in the short term (though I may be wrong). Then we will just need to figure out how to build policies for the embedded device from the development PC. That might be less work that this alternative but I'll give it a go anyway: Another possibility is a Btrfs image with zstd compression, should get you pretty close to squashfs with xz compression, and zstd uses less CPU to do the compression and decompression at similar compression levels. And once it's labeled, you can make the image a read only seed. Optionally a 2nd device can be added to which all writes go, this could be a zram device making it volatile; or it could be a partition on flash storage or even iSCSI if you want some kind of persistence. You could even ship an unlabeled read-only image, and during boot a 2nd device gets added making the volume rw, now label the volume, and now make the volume read-only, and remount. Btrfs supports multiple device seed (read-only) devices. So the writes representing only the labels go on the 2nd device, which then gets marked read-only. And then that volume is mounted. All the Btrfs multiple device stuff is baked into the kernel code, so there's no complex device mapper like scripting that you see in dracut to handle this. Of course the gotchas are, zstd in Btrfs is brand new. While it's had zlib and lzo for a while, zstd is only going to be supported by 4.13 and newer kernels. And Red Hat has deprecated Btrfs support, but that might just be ending support for unlimited use cases for all I know, whereas your use case is very constrained, with a file system that pretty much isn't being modified. An additional plus for embedded devices in particular is the preponderance of super shitty flash, where the "deterministic representation of data" quite a bit more often means your data is simply not decoded from flash correctly, and right now only Btrfs unambiguously detects this problem. I'm willing to bet squashfs will soon support zstd as well. -- Chris Murphy _______________________________________________ selinux mailing list -- selinux@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to selinux-leave@xxxxxxxxxxxxxxxxxxxxxxx
