I noticed that OpenWRT already ships SELinux policies in the default repositories. However, these do not work, and I expect this is because OpenWRT doesn’t ship with SELinux enabled in the kernel.
Would it be possible to enable SELinux in the default kernel build? With no policy loaded SELinux doesn’t do anything, so it is harmless.
Not really realistic, OpenWrt isn't all x86/ RPi/ sunxi, size constraints both flash and -more importantly- kernel size (bootloader constraints, OEM partitioning) will throw a spanner into the works. Shipping with SElinux enabled (enforcing mode and everything) is never going to happen (too much of a mine field, xattrs not everywhere, etc.), so enabling it in the kernel -by default- would be way too much dead weight, without any gain (by default).
Interesting. Could two kernel packages be shipped? What do you mean by “too much of a mine field”? I know that Android uses SELinux and it works very well there, but they are also more of a closed system and so they can require SELinux policies for literally everything.
No, the kernel is shared by all devices of a subtarget, it's not packaged, it can't be replaced at runtime. We don't have UEFI and grub, we can't select kernels at bootime, please keep the constraints of the typical OpenWrt plastic router in mind.
Android's minimum system requirements are 16 GB flash & 2 GB RAM (and you really-really-really don't want that little), OpenWrt's are 8MB flash & 64 MB RAM (going to be 16 MB flash && 128 MB RAM soon). Android is furthermore a heavily fortified walled garden, with all the system level software coming out of a single hand - and google is a multi-billion dollar company, who can assign manpower on making stuff work.
THe best you can do, is making SElinux easily selectable at build-time, if you really want it, you'll still end up with lots of open tasks.
Which tasks can you think of?
Is anyone using the SELinux packages in OpenWRT’s repository? If not, I’m wondering if they should be removed.
There is someone who's contributed them and was very motivated to make them work, to the extent possible. But making it default or runtime selectable isn't really on the table.
The world isn't black or white, it's shades of grey and any other imaginable colour. You can't push for SElinux by defaults, but then throw the toys out of the prawn if you realize that this demand isn't going to be served.
How difficult would it be to make them build-time selectable? Does this just require flipping a Kconfig switch?
Well, menuconfig, but you are correct along general lines. It is not fedora or refpolicy with 500 knobs and switches though.
Not having so many knobs is a good thing! Does OpenWRT support some sort of alternate build setup such that it could build more than one version of an image? If not, where would be the best place to start working on it?
For context, I wrote the SELinux policies for Qubes OS, so I know quite a bit about SELinux. I know next to nothing about how the OpenWRT build system works, though.
Now you are talking 
Policy is written in "intermediate" form, not high level pol/te/tc. You will have better luck convertling upstream or ubuntu apparmor policies to ujail sandboxes.
Also on non-x86 non-arm platforms there is no auditd and close to none wsy to debug a policy deny.
I’ve used CIL in the past, and actually find it much nicer. The syntax is slightly annoying but that is all.
Does it make sense to use SELinux on OpenWRT or is ujail a strictly better choice?
It is namespace filter, like half docker.
Does that mean that ujail and SELinux are better used together than separately?
Fairly independent from eachother.
Do the space constraints that prevent enabling SELinux by default also apply to builds for “big” platforms, such as VMs?
Indirectly, yes.
OpenWrt behaviour needs to be relatively similar between targets, or things get unwieldy. Just because a target has space, you can't make it completely different than all 'normal' targets, as that would void all testing. SELinux is a quite major behavioural change, with a huge potential for breakage, it will explode spectacularly without the appropriate testing - either it goes 'everywhere' or nowhere at all.
My reasoning is:
How much is OpenWRT tested on the larger targets? My intuition is “quite a bit”, especially for non-core features which may simply not fit in the tiny targets. Also, has the space overhead of SELinux ever been measured?
Edit: The other part of my thinking is that if SELinux will never be on by default for anyone, then perhaps it would be better for effort to go into security features that can be on by default for everyone, and which therefore can protect far more people.
You're putting the cart before the horses…
SELinux is 'available' (at build-time, opt-in), so you can test it - please do so first, before assuming that it would be an acceptable choice by default (both in terms of the policies not breaking major things, as well as its behaviour on low-end targets). A lot of the way has been paved already, but by far not to the extent that anyone would sign up for it at this point (I raised a few quite major procedural and technical points, and I'm not even touching the open question what works or breaks, there are more).
You want it, you'll have to test it to back up your plans - and if it breaks, you get to keep both pieces and the honour to actually fix it.
Thanks for the clear-cut explanation! Marking thread as solved.
Don't get me wrong, I don't want to discourage anyone - and increasing security is always a worthwhile goal. But the results aren't a foregone conclusion to the positive, just because because the config symbols allow enabling it. The mere fact that it's not available by default proves the lack of real-world testing (or even build testing exposure).
But you have to realize that OpenWrt is a rather special environment, with requirements that aren't in focus by general purpose distributions. Be aware that e.g. 32-bit mips (in both endian formats!) is still big on OpenWrt (ath79, lantiq, mt7621, realtek, to name some targets that are still in active use), barely anyone else still uses mips - and mips as an ISA hasn't seen any development since the 90s, lacking modern security features…
And for most plastic routers, size is king.
Just as an example, we don't have systemd either, not because it's bad software, but because you can't get it (alone) below ~4 MB (and that's already by disabling all the features that would be wanted and ignoring the size of its indirect dependencies). That is relevant, if most of your -even highend- target devices range from 20-90 MB usable storage space.