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

[Daniel Golle]

On Thu, Mar 18, 2021 at 09:25:45AM +0100, Vincenzo Romano wrote:
> 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"?

Very little above the actual minimum. SELinux (ie. kernel support,
userland support and the policy itself) alltogether adds a few hundred
kilobytes to the final image size.

> 2. How long would it take for a complete rebuild (due to extra load on
> the builders)?

Bulders now take around ~2 hours for a phase1 run, I guess we add
another 30-40 minutes on top of that.


> 
> --
> 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
> 
> _______________________________________________
> openwrt-adm mailing list
> openwrt-adm at lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-adm