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 6180C98EC8 for ; Fri, 28 Apr 2023 12:09:45 +0200 (CEST) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id 42F5932497 for ; Fri, 28 Apr 2023 12:09:15 +0200 (CEST) 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, 28 Apr 2023 12:09:14 +0200 (CEST) Received: from proxmox-new.maurer-it.com (localhost.localdomain [127.0.0.1]) by proxmox-new.maurer-it.com (Proxmox) with ESMTP id 433D44637E; Fri, 28 Apr 2023 12:09:14 +0200 (CEST) Date: Fri, 28 Apr 2023 12:09:07 +0200 From: Fabian =?iso-8859-1?q?Gr=FCnbichler?= To: "DERUMIER, Alexandre" , Proxmox VE development discussion References: <5d378b3f9838ed1f8c8cfdb0a807b4890e11d6ea.camel@groupe-cyllene.com> <2fd9041f-d7e4-bffd-f194-c783570e7430@proxmox.com> In-Reply-To: <2fd9041f-d7e4-bffd-f194-c783570e7430@proxmox.com> MIME-Version: 1.0 User-Agent: astroid/0.16.0 (https://github.com/astroidmail/astroid) Message-Id: <1682675499.wotifmndfz.astroid@yuna.none> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-SPAM-LEVEL: Spam detection results: 0 AWL 0.076 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 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] is the next pve version 8.0 with debian 12 ? (any planning on patches merge ?) 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, 28 Apr 2023 10:09:45 -0000 On April 28, 2023 11:33 am, Thomas Lamprecht wrote: > Am 28/04/2023 um 09:15 schrieb DERUMIER, Alexandre: >> We had discussed about it last year, but I would like to implement >> permissions on vmbrX && sdn vnets, as it a breaking change. >> https://git.proxmox.com/?p=3Dpve-manager.git;a=3Dcommit;h=3Da37ff602ff74= 2403f01d6682bf9948183f87eadb >>=20 >=20 > yes, here the questions is more if we want to map in below some more > general resource-mapping ACL path as slightly/peripherally hinted in > a reply[0] to Dominik's HW mapping series. Or if we want to keep netdevs > in the /sdn path, which might be fine too as network devices is a big > and important enough class to be kept all in their own "access category" >=20 > [0]: https://lists.proxmox.com/pipermail/pve-devel/2022-November/054557.h= tml >=20 > Fabian has some more spelled out questions/ideas IIRC. not so much spelled out, but yeah, this came up recently again because of a forum question :) I would really like to have the ability to restrict access to bridges and bridge-like entities from SDN in 8.0. right now it's only possible to limit the configuration itself, but not the "usage". for SDN there is a cosmetic filter in place, but that is only cosmetic, as long as a user/token has VM.Config.Network they can use *any* bridge or *any* vnet via the API. these are the basic parts I've thought of: 1.) decide on the ACLs/privs for regular bridges - ACL path and privileges shared with SDN - OR: ACL path and privileges shared with other per-node hardware entities, like those used for pass-through the former is probably more easy, since it means we don't need special helpers or complicated code when checking access in places where either a regular bridge or SDN is used.. the advantage of the map would be that we'd have a single mechanism for defining and giving access to per-node resources. so not really clear cut (yet) - which privilege levels do we need? - See (Audit), Use, Configure (Admin)? 2.) implement access control checks in all the places - mostly guest-related: create/restore/update/remote-migrate/clone - firewall (rules referencing bridges/vnets? maybe it doesn't matter, since if I can change the host firewall I can already mess stuff up, and for the guest firewall I can probably use whatever I want?) - SDN (e.g., to configure a zone to use a certain bridge?) - node network config (switch from Sys.Modify to SDN.Admin?) once the decision on the privileges has been made, we need to backport any new privileges to the last 7.x version, so that admins can setup the new ACLs before (partially!) upgrading their clusters, and also to avoid breaking not-yet-updated nodes when ACLs are modified on already upgraded ones.