Selinux support

[davidcassany]

This is a work in progress PR about setting and enabling SELInux in cOS-Toolkit

Fixes #22

[davidcassany]

So far I did few findings regarding the SELinux story around #22

• I could not manage to apply labels in a build process, dockers complaints of not being permitted. Fails with:

  /sbin/setfiles: Could not set context for /:  Operation not permitted
  

  The build is executed as root and I just realized that docker build does not run in privileged mode and that my docker daemon does not except --security-opt seccomp=unconfined. So to me it looks like, at least with docker we can't set SELinux labels within a container at build time. docker run --privileged ... allows to do so, so the limitation is only at build time. We could always think of a multi step procedure: docker build -> docker run -> setfiles ... && gomtree -> docker commit.

• As far as I could see xattr are mostly not preserved into container layers, buildah only preserves security.capabilities and few more, but not SELinux labels (see Security Extended Attributes are not preserved using buildah containers/buildah#2127). Similar story in Moby, there is a PR to support it raised concerns and it is still opened for more than a year now Extend xattrs support for security.* and user.pax.* moby/moby#40855

• As a result of the above the obvious solution is to relabel the filesystem once the system boots. However this fails on the concept of the immutable root. We mount the root-tree as read only, so it miserably fails to relabel most parts of the root-tree. In addition, using the build of selinux-policies for Leap 15.3 from OBS causes a reboot after relabeling, which in turn causes a reboot loop as the relabel gets lost at reboot.

• Another alternative could be applying the relabeling at install/upgrade face, IMHO this is the way to go. We need to be careful this does not invalidate the root-tree checksum so mtree reports the same result with and without SELinux labels.

• Since there are no selinux policies for SLE I am wondering what are we supposed to deliver here, adapting refpolicy to be functional with cOS seams to be a huge task. It is just frightening to see that fedora selinux polices are already a fork of it (due to the amount of differences) and the selinux-policies in TW are heavily patched over the fedora ones (and they are not submitted to SLE)... If the time arrives we require SELinux I am confident it is possible to get it given some suited policies, how to get those policies is the though part and probably something big (I am not a SELinux expert I can't asses the complexity of it)

• SELinux requires again some further changes on the kernel command line parameters (security=selinux selinux=1). With the current setup this not easy to achieve via upgrades as the grub configuration files do not belong to the image itself. IMHO this is design error, to build an image nothing no further bits from what the image contains should be required, meaning that in iso/cOS.yaml nothing beyond system/cos should be needed, I would include grub and its configuration in system/cos and then copy what ever is needed into the boot partition at installation time. I believe this way would be easier to design upgrades that bootloader sensitive. Related to Embed grub configuration into published images #109

The current PR is mere informative about how I executed the tests, I don't think it is worth to merge it as it is now, it does not work and it will not work unless policies are refined.

[davidcassany]

Finally I managed to install the TW selinux packages, apply selinux labels at install time and then boot. The boot procedure now is on permissive mode and after boot one can see labels are applied on the rootfs (e.g. ls -Z /), if one provides the enforce=1 as a kernel parameter then SELinux is enfornced and the system boots with the only failures of cos-setup services, I guess this is a good sign as there are no specific policies for the boot time configurations executed by cos-setup. Even the system boots, since cos-setup miserably failed to execute any stage the system is not configured as requested, including the root password, which makes the system unusable.

[davidcassany]

Apparently go-mtree optionally supports parsing xattrs, it is an option. So I was wondering if it wouldn't be possible to actually include the go-mtree result of labeled files into the pushed image, so we could eventually dump the image to the filesystem then apply the labels and after that run go-mtree and compare with the pre-stored result that was included into image metadata. No labels processing on boot time, just at install/upgrade time and with a proper sanity check before rebooting. This way we could eventually avoid having to push a filesystem image to the registry.

[davidcassany]

#147 seams to be a valid procedure to verify the images however this still has a problem, which is that we need to somehow provide the mtree manifest as part of the image. Applying SELinux labels to the rootfs at build time even if it is just to create the mtree manifest might be tricky since my attempts to relabel inside the container all failed. Apparently docker does not allow to actually run docker build in privileged mode (I could not figure out how to disable seccomp too).

I also gave a trial using podman build --security-opt seccomp=unconfined and buildah bud --security-opt seccomp=unconfined and it did not work in any case. Podmand and buildah seams allow setting SELinux Labeling at build time by providing extra capabilities, at least adding the CAP_SYS_ADMIN does the job. Probably it can be better refined to a more suited subset.

In fact this is a reasonable limitation, allowing this sort of operations at build time could easily lead to non portable images...

[davidcassany]

@mudler @Itxaka @kkaempf This PR is the first step of having SELinux support in cOS. This installs the policies and sets the labels at upgrade/install time. Currently SELinux is started on permissive mode to ensure SELinux does not block cloud-init operations. Proper policies should be applied to ensure all the changes we do on the fly aren't blocked.

Proper policies is something TBC and probably not something we should spend time on, since we are not experts on it.

[davidcassany]

Merging since all required tests are passing and pull_request suite passed all clean. Only one test of the push suite failed...