From scan-admin at coverity.com Wed Jun 7 15:06:12 2023 From: scan-admin at coverity.com (scan-admin at coverity.com) Date: Wed, 07 Jun 2023 15:06:12 +0000 (UTC) Subject: Coverity Scan: Analysis completed for varnish Message-ID: <64809ce3cd833_350ba2aeae73759a44137f@prd-scan-dashboard-0.mail> Your request for analysis of varnish has been completed successfully. The results are available at https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P0qcxCbhZ31OYv50yrJbcjUxJo9eCHXi2QbgV6mmItSKtPrD4wtuBl7WlE3MQ-3D-3DpW26_WyTzqwss9kUEGhvWd0SG502mTu1yasCtuh9h-2FD3Je4-2BYuuHmmxxNF24n0wBFc5zCubll7uva-2B7tGpLFWzvtFp4QWqJ-2FZMTKCkTOjkuu6rBdlIj0mPP1ARuGRbOnEcU0u3xkf9s01bcIiJsbz4vAlfUyV05OTV3B3voUeJbOdDKF4-2BAB1OdY-2FnzIt-2B7H9G08pi3E8QueT4-2BcqmT7LE00CSkfIT7G00K-2FeOgY1jsWqka4-3D Build ID: 536778 Analysis Summary: New defects found: 1 Defects eliminated: 0 If you have difficulty understanding any defects, email us at scan-admin at coverity.com, or post your question to StackOverflow at https://u15810271.ct.sendgrid.net/ls/click?upn=CTPegkVN6peWFCMEieYYmPWIi1E4yUS9EoqKFcNAiqhRq8qmgeBE-2Bdt3uvFRAFXd-2FlwX83-2FVVdybfzIMOby0qA-3D-3DbCWs_WyTzqwss9kUEGhvWd0SG502mTu1yasCtuh9h-2FD3Je4-2BYuuHmmxxNF24n0wBFc5zCubll7uva-2B7tGpLFWzvtFp-2BKj-2FGXuSCmvpA6ZDU0toec-2F1C0Gz5Dj0EpMlJTkEzLYzLOfBskjTYCu7grNlMCPjmeaxGFA7ln8EfXeVwlysGXM1Ycg0sl90mXe6cMvJZIZJaR8183OQDZ8fILidj816m9IWA575LKD8x83fXV8sFI-3D From scan-admin at coverity.com Mon Jun 12 08:10:36 2023 From: scan-admin at coverity.com (scan-admin at coverity.com) Date: Mon, 12 Jun 2023 08:10:36 +0000 (UTC) Subject: Coverity Scan: Analysis completed for varnish Message-ID: <6486d2fbed7c0_7f7d92aeae73759a441330@prd-scan-dashboard-0.mail> Your request for analysis of varnish has been completed successfully. The results are available at https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P0qcxCbhZ31OYv50yrJbcjUxJo9eCHXi2QbgV6mmItSKtPrD4wtuBl7WlE3MQ-3D-3DDMVT_WyTzqwss9kUEGhvWd0SG502mTu1yasCtuh9h-2FD3Je4-2BvfXpMK7oy6ORTC76xWIi9vIyMdEoeu8PwwP-2BiMRAkBXyWaHcNALfTw1wVt1rqMYukOKFZtDQYPeZ-2BMiOAsUe42BTdikfE1LS-2F9XMQsZ4gMURuatkIgNST7Rag6-2Fjtm1rvVubmIJ7RbZJgDDxz5Rx-2FbckKKuLYCmslRN8xnHK2hpsezzFyvLbZCq0QRCZuVg0-3D Build ID: 537687 Analysis Summary: New defects found: 0 Defects eliminated: 1 From scan-admin at coverity.com Mon Jun 19 08:16:52 2023 From: scan-admin at coverity.com (scan-admin at coverity.com) Date: Mon, 19 Jun 2023 08:16:52 +0000 (UTC) Subject: Coverity Scan: Analysis completed for varnish Message-ID: <64900ef3de7d3_ed8e32aeae73759a4413f@prd-scan-dashboard-0.mail> Your request for analysis of varnish has been completed successfully. The results are available at https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P0qcxCbhZ31OYv50yrJbcjUxJo9eCHXi2QbgV6mmItSKtPrD4wtuBl7WlE3MQ-3D-3DECwG_WyTzqwss9kUEGhvWd0SG502mTu1yasCtuh9h-2FD3Je48eVnBengdViVjcHfEBLu22S8P-2BejTK4JpE06xM4SZNPeo0Dxbsg5tEd3Z378vrDwMz7xRMbBxpgCE-2BuY40hYtM3wZeT-2FMHkQiKZp-2FpMbTLa8un1kn5ydz5NdZ19uZKNnbt8-2B-2Bq6SznSZX1WOmU6yK4SpUE2OOggN7xw8iLlH7-2BG7h-2FHGMIGQT4gI2hD6K-2BERU-3D Build ID: 539111 Analysis Summary: New defects found: 0 Defects eliminated: 0 From scan-admin at coverity.com Mon Jun 26 08:11:33 2023 From: scan-admin at coverity.com (scan-admin at coverity.com) Date: Mon, 26 Jun 2023 08:11:33 +0000 (UTC) Subject: Coverity Scan: Analysis completed for varnish Message-ID: <6499483498db2_4753b2b249bf959943388f@prd-scan-dashboard-0.mail> Your request for analysis of varnish has been completed successfully. The results are available at https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P0qcxCbhZ31OYv50yrJbcjUxJo9eCHXi2QbgV6mmItSKtPrD4wtuBl7WlE3MQ-3D-3DmJ6c_WyTzqwss9kUEGhvWd0SG502mTu1yasCtuh9h-2FD3Je4-2FEqCAsYPKAEt0BUcBP1ddmDShgfCJ3L2C6jCYk8Kg9pPcVpYap1qMFM3leBGirmABWoJcy7TLGm8qh-2BuZUVeWaJoWq1xd6-2BRm4uY9eVHwReIkWdvaK0c1ujYiss6j3B7ChgRaKV43jpFSv-2BdRYQhqa2wJWa-2Bnk-2BOO6R2Z9BkydQNFJEspXX951We295MTLKcs-3D Build ID: 540476 Analysis Summary: New defects found: 0 Defects eliminated: 0 From phk at phk.freebsd.dk Mon Jun 26 18:38:47 2023 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Mon, 26 Jun 2023 18:38:47 +0000 Subject: Idea for multi-level CLI access control Message-ID: <202306261838.35QIclul023655@critter.freebsd.dk> 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: " NL Then any number of rules: ("permit: " | "deny: ") 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 Random notes: * Ideally the help command output is also filtered through the rules. * 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. * Varnishadm could look for secret files in ~/.varnish/${-i/-n arg} Comments ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk at 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. From dridi at varni.sh Tue Jun 27 08:01:30 2023 From: dridi at varni.sh (Dridi Boukelmoune) Date: Tue, 27 Jun 2023 08:01:30 +0000 Subject: Idea for multi-level CLI access control In-Reply-To: <202306261838.35QIclul023655@critter.freebsd.dk> References: <202306261838.35QIclul023655@critter.freebsd.dk> Message-ID: On Mon, Jun 26, 2023 at 6:39?PM Poul-Henning Kamp 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: " NL > > Then any number of rules: > > ("permit: " | "deny: ") 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 From phk at phk.freebsd.dk Tue Jun 27 09:24:35 2023 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Tue, 27 Jun 2023 09:24:35 +0000 Subject: Idea for multi-level CLI access control In-Reply-To: References: <202306261838.35QIclul023655@critter.freebsd.dk> Message-ID: <202306270924.35R9OZRo000790@critter.freebsd.dk> -------- Dridi Boukelmoune writes: > On Mon, Jun 26, 2023 at 6:39=E2=80=AFPM Poul-Henning Kamp 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 at 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. From dridi at varni.sh Tue Jun 27 12:24:39 2023 From: dridi at varni.sh (Dridi Boukelmoune) Date: Tue, 27 Jun 2023 12:24:39 +0000 Subject: Idea for multi-level CLI access control In-Reply-To: <202306270924.35R9OZRo000790@critter.freebsd.dk> References: <202306261838.35QIclul023655@critter.freebsd.dk> <202306270924.35R9OZRo000790@critter.freebsd.dk> Message-ID: On Tue, Jun 27, 2023 at 9:24?AM Poul-Henning Kamp wrote: > > -------- > Dridi Boukelmoune writes: > > On Mon, Jun 26, 2023 at 6:39=E2=80=AFPM Poul-Henning Kamp > 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