From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from firstgate.proxmox.com (firstgate.proxmox.com [212.224.123.68]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by lists.proxmox.com (Postfix) with ESMTPS id 2301E94C5C for ; Fri, 23 Feb 2024 11:21:18 +0100 (CET) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id 0CC8416396 for ; Fri, 23 Feb 2024 11:21:18 +0100 (CET) Received: from proxmox-new.maurer-it.com (proxmox-new.maurer-it.com [94.136.29.106]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by firstgate.proxmox.com (Proxmox) with ESMTPS for ; Fri, 23 Feb 2024 11:21:15 +0100 (CET) Received: from proxmox-new.maurer-it.com (localhost.localdomain [127.0.0.1]) by proxmox-new.maurer-it.com (Proxmox) with ESMTP id 21D2544ECB for ; Fri, 23 Feb 2024 11:21:15 +0100 (CET) Date: Fri, 23 Feb 2024 11:21:08 +0100 From: Fabian =?iso-8859-1?q?Gr=FCnbichler?= To: Proxmox VE development discussion References: <20240219171412.1576651-1-t.lamprecht@proxmox.com> In-Reply-To: <20240219171412.1576651-1-t.lamprecht@proxmox.com> MIME-Version: 1.0 User-Agent: astroid/0.16.0 (https://github.com/astroidmail/astroid) Message-Id: <1708683464.bi76ltgkfr.astroid@yuna.none> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-SPAM-LEVEL: Spam detection results: 0 AWL -0.084 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DMARC_MISSING 0.1 Missing DMARC policy KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment POISEN_SPAM_PILL 0.1 Meta: its spam POISEN_SPAM_PILL_1 0.1 random spam to be learned in bayes POISEN_SPAM_PILL_3 0.1 random spam to be learned in bayes SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record SPF_PASS -0.001 SPF: sender matches SPF record T_SCC_BODY_TEXT_LINE -0.01 - Subject: Re: [pve-devel] fix #5254: add separate Sys.AccessNetwork privilege X-BeenThere: pve-devel@lists.proxmox.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: Proxmox VE development discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Feb 2024 10:21:18 -0000 On February 19, 2024 6:14 pm, Thomas Lamprecht wrote: > Adds a new Sys.AccessNetwork privilege that can be used to guard API > endpoints that can do outgoing network requests with (some) user control > over said requests, like e.g. the "download URL to storage" one. >=20 > ## Backstory: >=20 > This stems from an user request [0] w.r.t. the "download image through > and URL directly to a storage" functionality and their use case of that > through automation while wanting to adhere to the principle of least > privilege. >=20 > Because before this series the access to the required endpoints was > guarded by the more powerful Sys.Modify and Sys.Audit privilege > requirement on the / root ACL object path. > So, if anybody wants to set up an API token so that automation can > handle image downloads they'd need to give that API token very powerful > permissions to make it work. >=20 > A more specialized privilege seems warranted now, so add the > Sys.AccessNetwork one and adapt the /nodes/{node}/query-url-metadata and > the related /nodes/{node}/storage/{storage}/download-url API endpoints > for now. >=20 > ## Testing: >=20 > Tested by creating a new custom role with the privileges > `Datastore.Audit,Datastore.AllocateTemplate,Sys.AccessNetwork`, then > created a user that gets a permission with above role for a specific > node and a storage and then try querying and downloading an image, with > and without this patch series applied. >=20 > ## Future Work >=20 > We could this even re-use for other endpoints, like adding storages that > are accessed through the network, as that provides a (limited) side > channel too. for the whole series: Reviewed-by: Fabian Gr=C3=BCnbichler this seems like a sensible addition, and is hopefully neither to specific nor too generic for future extensions. while the dependencies are not "hard", it might still be a good idea to bump the min versions to ensure no weird combination is moved along the repositories (and also, it makes it easier to tell users which version they need, since just looking at pve-manager or pve-storage depending on the endpoint is needed).