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 21A848A7B8 for ; Wed, 27 Jul 2022 11:08:47 +0200 (CEST) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id 16CA837B2 for ; Wed, 27 Jul 2022 11:08:17 +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 ; Wed, 27 Jul 2022 11:08:16 +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 53E2842C7B for ; Wed, 27 Jul 2022 11:08:16 +0200 (CEST) Date: Wed, 27 Jul 2022 11:08:10 +0200 From: Fabian =?iso-8859-1?q?Gr=FCnbichler?= To: Oguz Bektas , pve-devel@lists.proxmox.com References: <20220602072450.55209-1-o.bektas@proxmox.com> <20220602072450.55209-19-o.bektas@proxmox.com> In-Reply-To: <<20220602072450.55209-19-o.bektas@proxmox.com> MIME-Version: 1.0 User-Agent: astroid/0.15.0 (https://github.com/astroidmail/astroid) Message-Id: <1658911706.38rwgb92pl.astroid@nora.none> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-SPAM-LEVEL: Spam detection results: 0 AWL 0.162 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% 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 Subject: Re: [pve-devel] [PATCH v4 docs 18/18] pveum: add SU privilege and SA role 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: Wed, 27 Jul 2022 09:08:47 -0000 On June 2, 2022 9:24 am, Oguz Bektas wrote: > with some warnings about imposed restrictions and the danger of giving > this role/privilege to untrusted users. this should probably have a warning about giving whole groups SuperUser=20 privileges, since anybody able to add users to that group (which does=20 not require SU) can give themselves SU that way. unfortunately groups=20 are not a proper entity that we can query privs for, so this is hard to=20 check/guard against reliably/in a future proof fashion. something like this maybe? Be careful to restrict access to groups with `SuperUser` privileges -=20 anybody who can modify such a group can give themselves `SuperUser`=20 access, without the group modification itself requiring it! >=20 > Suggested-by: Fabian Gr=C3=BCnbichler > Signed-off-by: Oguz Bektas > --- > pveum.adoc | 14 +++++++++++++- > 1 file changed, 13 insertions(+), 1 deletion(-) >=20 > diff --git a/pveum.adoc b/pveum.adoc > index 840067e..8067984 100644 > --- a/pveum.adoc > +++ b/pveum.adoc > @@ -705,7 +705,11 @@ Roles > A role is simply a list of privileges. Proxmox VE comes with a number > of predefined roles, which satisfy most requirements. > =20 > -* `Administrator`: has full privileges > +* `SuperAdministrator`: has **full** privileges including `SuperUser` > +* `Administrator`: has all privileges **except** `SuperUser` > + > +NOTE: `SuperAdministrator` role is equivalent to 'root@pam'! Do not give= this role to untrusted users. should be warning likely? > + > * `NoAccess`: has no privileges (used to forbid access) > * `PVEAdmin`: can do most tasks, but has no rights to modify system sett= ings (`Sys.PowerMgmt`, `Sys.Modify`, `Realm.Allocate`) > * `PVEAuditor`: has read only access > @@ -748,6 +752,14 @@ We currently support the following privileges: > =20 > Node / System related privileges:: > =20 > +* `SuperUser`: modify root-only configuration options (warning! **do > +not give this privilege to untrusted users**) should be a proper warning? and, as discussed, `SuperUser` should be its=20 own section (also, the warnings/notes would look weird otherwise/break=20 formatting). > + > +NOTE: `SuperUser` privilege by itself does not equal the access level of= 'root@pam'. > + > +NOTE: Certain actions on users with the `SuperUser` privilege are restri= cted to others > +with `SuperUser`, i.e. changing their password or two-factor-authenticat= ion settings > + > * `Permissions.Modify`: modify access permissions > * `Sys.PowerMgmt`: node power management (start, stop, reset, shutdown, = ...) > * `Sys.Console`: console access to node > --=20 > 2.30.2 >=20 >=20