Idea for multi-level CLI access control

[Dridi Boukelmoune]

On Mon, Jun 26, 2023 at 6:39 PM Poul-Henning Kamp <phk at phk.freebsd.dk> wrote:
>
> We talked about the overall security model during bugwash today and
> while trimming the hedges I had the following idea:
>
> Today the fundamental authentication to open a CLI port is that
> that you have access to the exact and entire contents of the "secret"
> file and can generate a proof of this.
>
> We keep that, but...
>
> 1.  We allow varnishd to have multiple secret files.
>     When a CLI connection attempts to authenticate, varnishd tries
>     them all.
>
> 2.  Secret files can be "old style" or "new style", in both
>     cases the "proof" uses the entire content of the secret file,
>     byte for byte.
>
> 3.  "New style" secret files have the following syntax:
>
>     Lines which start with '#' are comments and are ignored.
>
>     First line:
>
>         "secret: " <any number of characters in [0x20…0x7e]> NL
>
>     Then any number of rules:
>
>         ("permit: " | "deny: ") <regexp> NL
>
>     varnishd always appends a "deny: ." rule at the end of the
>     list of rules.
>
>     All submitted CLI commands are tested against these rules in
>     the order they appear in the secret file, and the search
>     terminates when one of them matches.
>
>     A trivial example of a secret file could be:
>
>         secret: swordfish
>         deny: vcl
>         deny: stop
>         # Note: Do not name a backend "kanban"
>         deny: ban

As agreed during bugwash, Varnish Software should come back with a
proposal after our review of the current security model and what we
think we could or should change. My plan is to first summarize the
current model to have a frame of reference for a future model.

Regarding the specific suggestion above, I don't think we would be
satisfied with this model. In the security barriers diagram [1] we
identified the following roles:

- ADMIN
- OPER
- BACKEND
- ANON

For CLI access, we would probably want a new role TENANT, managed by
ADMIN. Ideally, everything in the cache (VCL, contents, operations
like ban) would be virtually partitioned such that a tenant could not
directly affect the resources of other tenants. We could effectively
have two levels of authentication, and add a command line option to
varnishadm that would translate to a varnish-cli auth option.

Here is a straw man:

    sub vcl_recv {
            ban("obj.status != 0");
    }

In a multi-tenant system, we should be confident that it will not
affect the cache of other tenants, even if they share storage.

> Random notes:
>
> * Ideally the help command output is also filtered through the rules.

The output is already filtered based on prior auth success, we can
make that work with auth levels. If a VCL is bound to a tenant, and
its VMOD wants to add commands to the CLI, they should also be visible
only to that tenant.

> * Varnishd should identify itself (-i/-n) in the 107 message so that the
>   client can pick which secret file to use if it has access to multiple.

If each "account" (admin or tenant) has one dedicated secret,
this is probably not needed.

> * Varnishadm could look for secret files in ~/.varnish/${-i/-n arg}

I'm not against the idea, but I would prefer to leave this as an
exercise to the user. Chances are that if they expose CLI directly to
their tenants, they have other problems to solve like not doing CLI in
clear text. Please note also that the multi-tenant scenario described
above can also be used entirely by the admin persona, similarly to how
MGT performs privilege (des)escalation on demand to ensure that
operations made on behalf of a tenant have a blast radius limited to
that tenant (modulus interesting details like child CLI timeout).

> Comments ?

All of the above ;-)

Best,
Dridi

[1] https://varnish-cache.org/docs/trunk/phk/barriers.html