To support faster deployments as well as support build servers for SELinux-enabled platforms, we need to have a SELinux-enabled stage3 (which can then be used to seed further).
In order to use catalyst though, we will also need to update the policies (perhaps introduce a catalyst_t domain that has the necessary allow rules) as catalyst needs to run as root with specific privileges (like mounting /proc, /dev, etc.)
Building stages fails without a fix for #411719 (late in the stage3 setup).
Stage building currently fails because the seed stage doesn't provide the policy objects, making portage break early in the setup. So I still have to update the seed to contain the policy object itself as well. Minor inconvenience, but always takes a while to set up properly (and retest)...
Switching has recently gone a lot easier (as many packages do no longer need to be rebuild to transition to a SELinux system).
My weekend project was to build a selinux-capable stage3. This has been a gripe of mine since I started tinkering with gentoo's selinux in a seriously fashion. So I threw some time at it.
The goal here is to have a normal hardened stage3 that's built with the selinux use flag and feature in place so that all a user has to do is setup a selinux-enabled kernel and fix labeling.
To that end, here's how this process works.
1) Take an existing hardened stage3. I chose hardened amd64 + nomultilib, just because. The choice does not matter, as far as I can see.
2) Modify the stage3 seed so that it has libselinux built in. Just a simple emerge, then repack the stage3.
This is necessary because packages need header files from it, and want to link against it.
Note: The selinux.h the kernel provides in linux-headers IS NOT what it wants. Don't make my mistake :D
3) Modify (well, create) the package.use.force for hardened/linux/amd64/no-multilib/selinux as per https://bugs.gentoo.org/show_bug.cgi?id=527938
(that bug needs to be added as a dependency on this one)
The reasoning is explained there as well, but basically the static-libs changes are 100% necessary in order for the packages to be built.
4) Build stage1-3 using the modified stage3 seed + the modified profile.
The process for me wasn't 100% smooth, mostly because this was literally my first usage of catalyst. Plus it took about 8 hours overall to build (!).
Now, for a new system, I used a basic 2g of ram / 2 vCPU xen HVM for testing.
1) Do a new gentoo install without worrying about selinux.
The profile, use flags, and features are already set.
2) Build a kernel that has selinux support.
Sidebar: Is the kernel makeconfig process selecting useful stuff for me automatically? I just realized as I was writing this that I was so focused on digging up xen drivers that I didn't even deliberately select selinux support in the kernel, though it was set anyway.
3) Reboot into the kernel with enforcing=0 on the kernel command line.
Nothing is labeled, but selinux will be activated and you will find your user has a role.
3) Restore labels
(Maybe explain that relabeling /usr/portage is gonna take forever and that it is faster to just redownload a snapshot if /usr/portage itself is labeled right)
* Restore them with restorecon -Rv /
* Reboot to get services running with the new labels
* Restore one more time to account for any labeling issues picked up on the reboot while unlabeled
4) Setup fstab entries for /run and /tmp as per the selinux guide
I poked perfinion on maybe getting those into openrc. It'd be nice.
5) Add gentoo_selinux to boot as per the selinux guide.
Yes I know this is going away as per new userspace/later openrc but the stage3 is built with what's considered stable. This step can go away when newer openrc is stabilized.
The result is a fully functioning (less any issues in policies and whatnot) selinux-enabled gentoo.
This process was ran on a non-selinux machine. This was deliberate.
Now, I understand that catalyst doesn't fully function in a selinux env. But that's not a big blocker to selinux stages at the moment, since the stage building machines aren't selinux. But if it becomes an issue, one thing I think could be done (other than fix catalyst's selinux policy) would be to just make sure the /sys used in catalyst doesn't have selinuxfs mounted.
This radically simplifies the wiki guide on selinux installation. The process can be truncated from the current eldrich horror into something a bit more managable.
The existing process would have to stick around for folks who want to upgrade a non-selinux system into selinux, but that's a separate problem. Plus I think even that could be simplified to the process I have above. After beating on selinux for the past few weeks I think some of the caution is historical rather than being still necessary.
Additional thought, shouldn't the default python be set to 2.7 for the stage3 / profile?
As it stands, the default python comes out as 3.3 which isn't good for the selinux userspace stuff. But it doesn't seem to matter since the appropriate symlinks are set for it, so I'm not sure...
The stages build successfully now. Eric has been a great help in testing this.
I have uploaded the stage3 to /experimental/amd64 in the distfiles server.
@jmbsvicetto: I have tested your latest autobuild hardened selinux stage3, it works great.
Once its added to the official mirrors then we can start updating the installation docs in the wiki.