public inbox for pve-devel@lists.proxmox.com
 help / color / mirror / Atom feed
From: "Fabian Grünbichler" <f.gruenbichler@proxmox.com>
To: Proxmox VE development discussion <pve-devel@lists.proxmox.com>
Subject: Re: [pve-devel] [PATCH v2 access-control 11/12] api: allow superusers to edit tfa and password settings
Date: Thu, 17 Mar 2022 10:30:37 +0100	[thread overview]
Message-ID: <1647433600.6icgczfenm.astroid@nora.none> (raw)
In-Reply-To: <<20220311112504.595964-12-o.bektas@proxmox.com>

On March 11, 2022 12:25 pm, Oguz Bektas wrote:
> Signed-off-by: Oguz Bektas <o.bektas@proxmox.com>
> ---
> v1->v2:
> * also adapt change_password
> * didn't remove the comments in TFA.pm since it was still confusing without them
> 
>  src/PVE/API2/AccessControl.pm | 6 ++++++
>  src/PVE/API2/TFA.pm           | 7 +++++--
>  2 files changed, 11 insertions(+), 2 deletions(-)
> 
> diff --git a/src/PVE/API2/AccessControl.pm b/src/PVE/API2/AccessControl.pm
> index 5d78c6f..1b471f6 100644
> --- a/src/PVE/API2/AccessControl.pm
> +++ b/src/PVE/API2/AccessControl.pm
> @@ -378,9 +378,15 @@ __PACKAGE__->register_method ({
>  
>  	$rpcenv->check_user_exist($userid);
>  
> +	# check for SU privs on user groups
> +	my $is_superuser = $rpcenv->check($authuser, "/access/groups", ['SuperUser'], 1);

I know this is modelled after userid-group, but it's a lot more 
restrictive? I'd either use full userid-group semantics, or just 
'/access' as path, the current one doesn't make much sense as a middle 
ground.. I think I'd prefer '/access', given the issue further below..

but also, this check here is with $noerr set.. (ctd)

> +
>  	if ($authuser eq 'root@pam') {
>  	    # OK - root can change anything
>  	} else {
> +	    if ($is_superuser && $userid ne 'root@pam') {
> +		# OK - superusers can change any user's password except root@pam
> +	    }

and here you add an empty `if` with a side-effect free condition as only 
place where the result of the check above is used.. so effectively, 
nothing about this API path changes at all? how did you test this? what 
was the expected change, "adapt change_password" doesn't really give me 
a clue ;)

one could argue that if a user is SU anywhere, changing their password 
should require SU as well (on '/access' ?) or be limited to the user 
itself, similar to the semantics of 'root@pam'..

the 'user is SU anywhere' part doesn't exist yet and is a bit tricky 
(handling of groups/..) or expensive (get list of all currently defined 
ACL paths, query actual permissions on all of them).

changing another user's password already requires fairly high privileges:
- realm != pam
- Realm.AllocateUser on realm
- User.Modify on user (i.e., either User.Modify on all groups or a group 
  the user belongs to, like the other user-modification API endpoints)

there obviously is a pit-fall there though with the last part (add a SU 
to some group without knowing about the implication that other users 
with User.Modify on that group can now modify the SU, including changing 
password if the other conditions are met).

>  	    if ($authuser eq $userid) {
>  		$rpcenv->check_user_enabled($userid);
>  		# OK - each user can change its own password
> diff --git a/src/PVE/API2/TFA.pm b/src/PVE/API2/TFA.pm
> index bee4dee..bab78ea 100644
> --- a/src/PVE/API2/TFA.pm
> +++ b/src/PVE/API2/TFA.pm
> @@ -102,13 +102,16 @@ my $TFA_UPDATE_INFO_SCHEMA = {

comment above this sub is now wrong..

>  my sub root_permission_check : prototype($$$$) {
>      my ($rpcenv, $authuser, $userid, $password) = @_;
>  
> +    # authuser = the user making the change
> +    # userid = the user to be changed
>      ($userid, undef, my $realm) = PVE::AccessControl::verify_username($userid);
>      $rpcenv->check_user_exist($userid);
>  
> -    raise_perm_exc() if $userid eq 'root@pam' && $authuser ne 'root@pam';
> +    my $is_superuser = $authuser eq 'root@pam' || $rpcenv->check($authuser, "/access/groups", ['SuperUser'], 1);

same as above applies here as well w.r.t. the checked path / semantics.

> +    raise_perm_exc() if $userid eq 'root@pam' && !$is_superuser; # root@pam can be only edited by superusers

if we add a check for the other direction (special restriction of who 
can change a SU's password) above, the same semantics might make sense 
here (i.e., changing a SU's TFA settings requires SU as well).

>  
>      # Regular users need to confirm their password to change TFA settings.
> -    if ($authuser ne 'root@pam') {
> +    if ($authuser ne 'root@pam') { # we still do password confirmation for superusers like the other users
>  	raise_param_exc({ 'password' => 'password is required to modify TFA data' })
>  	    if !defined($password);
>  
> -- 
> 2.30.2
> 
> 
> 
> _______________________________________________
> pve-devel mailing list
> pve-devel@lists.proxmox.com
> https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
> 
> 
> 




  parent reply	other threads:[~2022-03-17  9:31 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-11 11:24 [pve-devel] [PATCH v2 access-control++ 00/12] SuperUser privilege Oguz Bektas
2022-03-11 11:24 ` [pve-devel] [PATCH v2 docs 01/12] pveum: add SU privilege and SA role Oguz Bektas
2022-03-17  9:36   ` Fabian Grünbichler
2022-03-11 11:24 ` [pve-devel] [PATCH v2 qemu-server 02/12] api: allow SU privileged users to edit root-only options for VM configs Oguz Bektas
2022-03-17 10:05   ` Fabian Grünbichler
2022-03-11 11:24 ` [pve-devel] [PATCH v2 qemu-server 03/12] api: allow 'skiplock' option to be used by SU privileged users Oguz Bektas
2022-03-17 10:12   ` Fabian Grünbichler
2022-03-11 11:24 ` [pve-devel] [PATCH v2 manager 04/12] api: backup: allow SUs to use 'tmpdir', 'dumpdir' and 'script' options Oguz Bektas
2022-03-17 12:18   ` Fabian Grünbichler
2022-03-11 11:24 ` [pve-devel] [PATCH v2 manager 05/12] api: vzdump: allow SUs to use 'bwlimit' and 'ionice' parameters Oguz Bektas
2022-03-11 11:24 ` [pve-devel] [PATCH v2 manager 06/12] api: update comment about login prompt for non-root users Oguz Bektas
2022-03-17 12:33   ` Fabian Grünbichler
2022-03-11 11:24 ` [pve-devel] [PATCH v2 manager 07/12] ui: adapt sensible 'root@pam' checks to SU privilege Oguz Bektas
2022-03-17 12:28   ` Fabian Grünbichler
2022-03-11 11:25 ` [pve-devel] [PATCH v2 container 08/12] fix #2582: api: add checks for 'SuperUser' privilege for root-only options Oguz Bektas
2022-03-17 12:11   ` Fabian Grünbichler
2022-03-11 11:25 ` [pve-devel] [PATCH v2 storage 09/12] check_volume_access: allow superusers to pass arbitrary fs paths Oguz Bektas
2022-03-11 11:25 ` [pve-devel] [PATCH v2 access-control 10/12] add "SuperAdministrator" role with the new "SuperUser" privilege Oguz Bektas
2022-03-11 11:25 ` [pve-devel] [PATCH v2 access-control 11/12] api: allow superusers to edit tfa and password settings Oguz Bektas
     [not found]   ` <<20220311112504.595964-12-o.bektas@proxmox.com>
2022-03-17  9:30     ` Fabian Grünbichler [this message]
2022-03-11 11:25 ` [pve-devel] [PATCH v2 access-control 12/12] api: acl: only allow granting SU privilege if user already has it Oguz Bektas
2022-03-16 12:24   ` Fabian Grünbichler
     [not found] ` <<20220311112504.595964-1-o.bektas@proxmox.com>
2022-03-17 13:04   ` [pve-devel] [PATCH v2 access-control++ 00/12] SuperUser privilege Fabian Grünbichler

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1647433600.6icgczfenm.astroid@nora.none \
    --to=f.gruenbichler@proxmox.com \
    --cc=pve-devel@lists.proxmox.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Service provided by Proxmox Server Solutions GmbH | Privacy | Legal