Hi,
As a disclaimer, I am very new to SELinux policy development.
My team and I are responsible for software architecture on an embedded (red hat) system. We pre-build the file system and save it to a squashfs that is then burned to the device. The result of this is that the system is, for the most part, read-only.
The problem is that we would like to start using SElinux, but we do not know if there is a way we can pre-label the files before saving them to the squashfs. We cannot label them at runtime as the file system is read only.
Does any one know if there is a way to pre-label an embedded linux file system from a development computer that does not have the same SElinux policies as the embedded platform?
Thank you, Nathan Owen
On Thu, 2017-10-19 at 21:15 +0000, Nathan Owen wrote:
Hi,
As a disclaimer, I am very new to SELinux policy development.
My team and I are responsible for software architecture on an embedded (red hat) system. We pre-build the file system and save it to a squashfs that is then burned to the device. The result of this is that the system is, for the most part, read-only.
The problem is that we would like to start using SElinux, but we do not know if there is a way we can pre-label the files before saving them to the squashfs. We cannot label them at runtime as the file system is read only.
Does any one know if there is a way to pre-label an embedded linux file system from a development computer that does not have the same SElinux policies as the embedded platform?
Android does this (setting the extended attributes during image build), and I believe OpenEmbedded / Yocto now also supports this capability, so it is certainly possible to do. However, that's using tools for generating ext[234] images that support setting the security.selinux attributes directly; they aren't mounting the filesystem on the host and populating it that way. So you'd need to integrate similar support into squashfs tools if it doesn't already exist (don't know).
If you are mounting the filesystem on the host and populating it via the regular filesystem interface, and if the host runs SELinux, then the process needs CAP_MAC_ADMIN and SELinux mac_admin capability2 permission in order to set "foreign" contexts (unknown to the host policy) on files via setxattr(); that was introduced for things like livecd-creator IIRC. There is a domain in the stock Fedora/RHEL policy for that, setfiles_mac_t or similar. But that's not needed if you are just generating the image file directly.
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.
Thank you, Nathan Owen
On Fri, Oct 20, 2017 at 12:34 AM, Nathan Owen nathanowen42@gmail.com 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.
On Thu, 2017-10-19 at 23:34 +0000, Nathan Owen 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.
Use setfiles instead of restorecon (same program, but different usage; setfiles takes the path to the file_contexts file you want to use for labeling and supports use on non-SELinux hosts; restorecon uses the system file_contexts file and only runs if SELinux is enabled in the host). setfiles also supports a -r option for specifying an alternate root path; this is used by meta-selinux in OE/Yocto to label the tree (under pseudo), ala:
setfiles -r /path/to/rootdir /path/to/rootdir/etc/selinux/targeted/contexts/files/file_contexts /path/to/rootdir
This will label the tree rooted at /path/to/rootdir based on /path/to/rootdir/etc/selinux/targeted/contexts/files/file_contexts, stripping the /path/to/rootdir prefix before matching the pathname regexes.
OE/Yocto does this under pseudo so that setting the xattrs and other meta-data are redirected to a database and don't require running as root, then later fetches them under pseudo and sets them in the generated filesystem image.
The Android build tools just directly look up the contexts themselves using selabel_lookup and set them directly in the image without going through the indirection of setting them on the local filesystem first; you pass the file_contexts file and the mountpoint directory as arguments to make_ext4fs and it does it all internally.
Hi Stephen,
Thank you, that is exactly the information I needed.
Is there something that works like this for adding SELinux policy modules? I would like to add policy modules to the targeted policy on the development PC during the build process.
Thank you, Nathan Owen
On Fri, 2017-10-20 at 17:16 +0000, Nathan Owen wrote:
Hi Stephen,
Thank you, that is exactly the information I needed.
Is there something that works like this for adding SELinux policy modules? I would like to add policy modules to the targeted policy on the development PC during the build process.
You want the -p option for that, e.g. semodule -p /path/to/rootdir -s targeted -n -i foo.pp
Ah, thanks. The man page on die.net is evidently outdated seeing as how it does not list that option. The man page on my PC lists it though.
Thanks again for your help.
Thank you, Nathan Owen
selinux@lists.fedoraproject.org
-
Chris Murphy -
Nathan Owen -
Stephen Smalley