Comment 6 for bug 1878234

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.

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.

> 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.