[vote] release OpenWrt 21.02 with additional SELinux SDKs and IBs

[Dominick Grift]

Petr Štetiar <ynezz at true.cz> writes:

> Daniel Golle <daniel at makrotopia.org> [2021-03-18 02:47:40]:
>
> Hi,
>
> why no discussion prior to this voting? :-)
>
>> Providing SELinux-enaled SDK and IB for all targets/subtargets allows
>
> so we're going to build something which might not be even usable and supported
> on those targets? I would start with a list of targets where it makes sense,
> for example by adding some feature/config option.
>
> Do we really want to support SELinux corner cases on really exotic targets?
>
>> Option A: Yes, provide SELinux SDK and IB for the 21.02.x releases.
>
> This is not an option for me, because it's too late for such a change. It's
> not about the SDK/IB itself, thats mostly fine with me. It's mainly about the
> possible number of additional patches needed to make SELinux enabled systems
> working, which in the turn might cause regressions for !SELinux builds etc.
>
>> Option B: Yes, and even start offering that for 21.02-SNAPSHOTS asap.
>> Option C: No, let's not do any of that.
>
> Option D: Start as always in master/snapshots and if the feature is usable
> and in a shape for a release, then include it in release.

I like this idea, but it is quite ambitious because then it becomes part
of base-os and that means that it is going to affect a majority. As long
as it only affects master which (given that it probably wont be in 21.02
in any way, shape or form) will give us quite some time to address and
identify remaining issues, and we can expect the snapshot users to
pro-actively disable it if they want to opt-out.

I kind of like the idea of turning the tables and make it opt-out
instead of opt-in, and again as long as it only affects master then I
see no issues with that at all because if someone does not like it then
he can just disable it in menuconfig.

This option will incentivice us to address issues that we might otherwise
have shrugged off with "that scenario is not important". i.e. it will
raise the bar/stakes. Remember though that this brings SELinux closer to
us and that could get intimidating/confrontational, and that it raises
the stakes not just for the rather limited number people that up to now
worked on it but also for openwrt project as a whole.

I do think we are at a crossroads here though. From a selinux-policy
perspective i've pretty much addressed what I am able to address on my
own with feedback from a limited number of users (except optimisation
work, which due to the limited exposure currently also does not get as
much priority as it could have because most of use have enough resources).
There are many components that I can not (fully) target just by my self because I do not know
the use-cases and/or do not have the hardware to test it (example
multi-wan, IPTV, VOIP but also microsoft specific stuff like upnp etc).

I would need feedback and that implies that people use it.

The above aspects should "work" as-is (for the most part at least) but:

1. These aspects are not currently targeted and obviously the idea is to
enhance security and thus to target these aspects.
2. Any LuCI integration would have to be addressed regardless because
LuCI is targeted (unless we decide to exempt LuCI which is probably not
a good idea).

The thing here is though that LuCI is opt-in with snapshots so it will get
only limited exposure/feedback with respect to LuCI selinux integration.

I am aware that i am currently not eligible to vote but my preference:

1. B
2. D
3. A

>
> So my choice is D, if that's not an option, then I'm for C.
>
> Cheers,
>
> Petr

-- 
gpg --locate-keys dominick.grift at defensec.nl
Key fingerprint = FCD2 3660 5D6B 9D27 7FC6  E0FF DA7E 521F 10F6 4098
https://sks-keyservers.net/pks/lookup?op=get&search=0xDA7E521F10F64098
Dominick Grift