Comment 7 for bug 1878234

On Fri, May 15, 2020 at 3:40 PM Christophe de Dinechin
<email address hidden> wrote:
>
> Sent reply this morning through email, but apparently the system is not
> smart enough to update the bug!!!
>
> On 15 May 2020, at 08:20, Christophe de Dinechin
> <email address hidden> wrote:
>
> > Le 15 mai 2020 à 05:35, Peng Tao <email address hidden> a écrit
> :
>
> > What about adding a global config option to disable the config-via-
> > annotation property completely (and enable it by default)? Instead of
> > trying to identify and remove each risky annotation configs, we keep the
> > ability and warn about their usage.
>
> I think this is a good idea, but as an addition to the proposed fix, not
> a replacement.
>
> If you decide to enable it, you should still not be allowed to execute
> host binaries.
>
Those options also have their valid use cases. For example, they would
allow easy rolling upgrade and fallback for each of these binaries.
Some additional validation/protection is OK but I don't think we
should completely disable them.

> I will add the option in a next iteration of the patch series.
>
>
> > In general, config-via-annotation is not a capability we would like to
> > expose to end users. They are mostly targeting service providers who
> > wrap their own services (e.g., container or kerbenetes as a server) over
> > infrastructural Kubernetes and have a proper validation on every field
> > user can input at a higher level.
>
> Actually, the reason I started looking into annotations is because they
> solved a problem we had, specifically about passing kernel boot options
> on a per-workload basis. So I conclude there are valid use cases where
> you would want them and still want the system to be secure.
>
So your plan is to still expose such functionality to end users? If
so, I'd suggest that we go the other way around: an explicit whitelist
instead a blacklist.

>
> > Also while the executable options are more dangerous, other options
> > might be used for an expolit as well. That's why I think we should
> > completely disable such config-via-annotation for end users.
>
> I plan to review other options as well. This one is urgent and comes first.
> Other options may lead to exploits on a case-by-case basis, and indeed,
> they need to be carefully scrutinized.
And as you identify each secure option, it can be put into the
whitelist instead of being moving out of the blacklist.

Cheers,
Tao
--
Into Sth. Rich & Strange