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

[Vincenzo Romano]

It's a great idea, indeed and I would say it's a good step forward.
But I have two main questions:
1. Is there any change in the "minimum hardware requirements"?
2. How long would it take for a complete rebuild (due to extra load on
the builders)?

--
Vincenzo Romano - NotOrAnd.IT
Information Technologies
--
NON QVIETIS MARIBVS NAVTA PERITVS
ΟΥΚ ΕΠΙ ΑΚΥΜΟΝΑΙΣ ΘΑΛΑΣΣΑΙΣ ΠΛΟΤΙΚΟΣ ΝΑYΤΗΣ

On Thu, Mar 18, 2021 at 9:15 AM Dominick Grift
<dominick.grift at defensec.nl> wrote:
>
> 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
>
> _______________________________________________
> openwrt-adm mailing list
> openwrt-adm at lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-adm