Mailing List Archive

On Mon, Jun 26, 2023 at 6:39?PM Poul-Henning Kamp <phk@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
_______________________________________________
varnish-dev mailing list
varnish-dev@varnish-cache.org
https://www.varnish-cache.org/lists/mailman/listinfo/varnish-dev

--------
Dridi Boukelmoune writes:
> On Mon, Jun 26, 2023 at 6:39=E2=80=AFPM Poul-Henning Kamp <phk@phk.freebsd.=
> dk> wrote:
> >

> 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

My idea was not meant as a replacement for any of those roles,
it just an idea for how to implement CLI connections with
different access levels - if we want to have that.

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

I think that is a bit beyond the scope of the current discussion, but
it is certainly relevant to keep it in mind.

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

I dont see the admin/tenant split eliminating the potential benefit
of being able to hand out restricted CLI access secrets.

As for CLI plain-text: I would really love to find a good and mostly
seamless way to use SSH for CLI access.

--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
_______________________________________________
varnish-dev mailing list
varnish-dev@varnish-cache.org
https://www.varnish-cache.org/lists/mailman/listinfo/varnish-dev

On Tue, Jun 27, 2023 at 9:24?AM Poul-Henning Kamp <phk@phk.freebsd.dk> wrote:
>
> --------
> Dridi Boukelmoune writes:
> > On Mon, Jun 26, 2023 at 6:39=E2=80=AFPM Poul-Henning Kamp <phk@phk.freebsd.=
> > dk> wrote:
> > >
>
> > 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
>
> My idea was not meant as a replacement for any of those roles,
> it just an idea for how to implement CLI connections with
> different access levels - if we want to have that.

Same, my overview keeps the current roles and adds TENANT below ADMIN.

> > 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.
>
> I think that is a bit beyond the scope of the current discussion, but
> it is certainly relevant to keep it in mind.
>
> > > * 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.
>
> I dont see the admin/tenant split eliminating the potential benefit
> of being able to hand out restricted CLI access secrets.

The whole idea is to partition the cache logically, so each tenant
sees a "restricted" set of resources. Commands like start and stop
would require admin privileges, so a "mere" tenant would not be able
use them. They would however be able to vcl.load and vcl.list, but
only see their VCLs, not other tenants'.

Instead of a tenant or a partition, let's call it a context and use a
familiar -Z option:

# operate as ADMIN, regular CLI `auth ...` under the hood
# secret found from VSM with varnish credentials
# /etc/varnish/secret read with MGT credentials (same as today)
$ varnishadm context.create -S /etc/varnish/example.com/secret example.com

# operate as TENANT, performs `auth -Z example.com ...` under the hood
# secret found from VSM with varnish credentials
# /etc/varnish/example.com/secret read with TENANT credentials
$ varnishadm -Z example.com vcl.load www /etc/varnish/example.com/main.vcl

That's one way you could interpret my previous email.

> As for CLI plain-text: I would really love to find a good and mostly
> seamless way to use SSH for CLI access.

Another option could be mutual TLS once we bring HTTPS support to the cache.

We will discuss this internally and come back with a proposal.

Best,
Dridi
_______________________________________________
varnish-dev mailing list
varnish-dev@varnish-cache.org
https://www.varnish-cache.org/lists/mailman/listinfo/varnish-dev