Cannot grant Shell/CLI permissions with @pbs, LDAP or other non pam accounts

B

BloodyIron

Renowned Member
Jan 14, 2013
328
32
93
Hi Folks,

I've recently tried in Proxmox Backup Server to create a new account for a new admin with full admin permissions, but there's some existing shortcomings that are noteworthy that I want the general public to be aware of. (I'm currently using v2.4-3 and these issues appear to exist even in the latest v3.2 versions too).

This user was created in the @PBS realm, and granted the "Admin" role with full permissions to full scope.
  1. Sys.Console being granted doesn't work and in the webGUI produces HTTP 400 error. Even in incognito and all cookies/cache cleared/refreshed.
  2. The user has no capability to log into the Shell/CLI at all, and in-turn cannot do sudo/elevated functions in similar vein to the root@pam account
  3. Only the root@pam account really is capable of doing actual Shell/CLI functions without completely undocumented and extreme steps taken.
This also is the case when using any other realm such as LDAP, OIDC, etc, so far as I can tell.

I have opened a bug report on the matter for Proxmox Backup Server: https://bugzilla.proxmox.com/show_bug.cgi?id=6052

And I also have already opened one for Proxmox VE as it has generally an identical/similar matter: https://bugzilla.proxmox.com/show_bug.cgi?id=5791

To date I'm not really seeing traction from the Proxmox devs on addressing this problem, and I really hope we can get traction here.

The core of the problem here is when there are more than 1 (>1) admins in the environment that _require_ full access, including elevated Shell/CLI access, to be able to do their job. The reason you do NOT want to use root@pam accounts for this is because you _cannot prove who did what and when_. So in environments where you need to audit operations, or review previous malicious actions (intentional or not) you _literally cannot prove who did what when the root@pam account is used_.

This issue is important in Proxmox Backup Server yes, and even more important for the Proxmox VE environment when dealing with clusters as in that case you can be dealing with possibly a whole team of admins that need this.

So if you are someone that cares about this stuff, please step into the above bug reports and lend your thoughts. I really want the Proxmox devs to get these added to some roadmap so they can get corrected soon-ish.

If there's anything more I can do to help on this greater topic, please let me know and I'll do my best to help!
 
Why don't you simply create Linux native Users? These would be authenticated over PAM. Or what about Key-Login for your admins over SSH when realy needing a shell.

In my opinion it's deginetly not a bug, it's just how things work.

I remeber some debian posts where you could sync/link LDAP/Kerberos/NTLM to PAM...
something like this... https://wiki.debian.org/LDAP/PAM
 
tscret said:
Why don't you simply create Linux native Users? These would be authenticated over PAM. Or what about Key-Login for your admins over SSH when realy needing a shell.

In my opinion it's deginetly not a bug, it's just how things work.

I remeber some debian posts where you could sync/link LDAP/Kerberos/NTLM to PAM...
something like this... https://wiki.debian.org/LDAP/PAM
Click to expand...

Bug is the only real class of report that can be made, regardless of if the term is fully accurate or not.

And this is a scaling problem, plus that's the whole point of the webGUI for Proxmox in general. So you can manage how the system operates _without_ having to go to the CLI. You literally can already do this just not to a sufficient degree, which is where the problem lies.
 
BloodyIron said:
And this is a scaling problem
Click to expand...
You can connect to AD (and others) - and PAM does also work for these.

Disclaimer: I have no "Howto" available...
 
UdoB said:
You can connect to AD (and others) - and PAM does also work for these.

Disclaimer: I have no "Howto" available...
Click to expand...

Okay now do that for each additional user on a huge Proxmox VE cluster one at a time... Having to manually go and set up a new user or modify an existing PAM user on a multi-hundred (or larger) PVE Node Cluster just so they can get Shell/CLI access is a very poor way to go about doing things. Using PAM sure but this needs to be managed by Proxmox VE and automated as such. Otherwise it's frankly just half-assing it.
 
BloodyIron said:
Okay now do that for each additional user on a huge Proxmox VE cluster one at a time... Having to manually go and set up a new user or modify an existing PAM user on a multi-hundred (or larger) PVE Node Cluster just so they can get Shell/CLI access is a very poor way to go about doing things. Using PAM sure but this needs to be managed by Proxmox VE and automated as such. Otherwise it's frankly just half-assing it.
Click to expand...
Not sure if I understand that correctly.

Most companies have already a Windows Domain / Active Directory. (Which is basically... sad enough.) And for those it is really easy:

You just tell PVE to connect to that one. In that process you specify that a specific group ("Domain Administrators" or "Domain Users" or a new group "PVEusers") has access to PVE with specific rights granted. That's it. No need to create new users on PVE.

PAM-login to get shell access on a Linux server is also no magic. Configure it once, define similar "group"-dependent rights and you are good to go - be it only three users or three thousands.


Disclaimer: I had tested this successfully two years ago with a local Samba AD server. I do not use this approach in my company today as I have only a very few colleges with administrative access to PVE - and my company's AD is very restrictive configured, so I can't "play" with it.

The doc is not very extensive: https://pve.proxmox.com/pve-docs/chapter-pveum.html#user-realms-ad
 
UdoB said:
Not sure if I understand that correctly.

Most companies have already a Windows Domain / Active Directory. (Which is basically... sad enough.) And for those it is really easy:

You just tell PVE to connect to that one. In that process you specify that a specific group ("Domain Administrators" or "Domain Users" or a new group "PVEusers") has access to PVE with specific rights granted. That's it. No need to create new users on PVE.

PAM-login to get shell access on a Linux server is also no magic. Configure it once, define similar "group"-dependent rights and you are good to go - be it only three users or three thousands.


Disclaimer: I had tested this successfully two years ago with a local Samba AD server. I do not use this approach in my company today as I have only a very few colleges with administrative access to PVE - and my company's AD is very restrictive configured, so I can't "play" with it.

The doc is not very extensive: https://pve.proxmox.com/pve-docs/chapter-pveum.html#user-realms-ad
Click to expand...

You're completely failing to see that to get Shell/CLI access on _each and every PVE Node in a cluster_ that currently that is _ONLY_ possible with PAM. LDAP/AD/OIDC/PVE/other authentication capabilities within Proxmox VE _CANNOT_ grant Shell/CLI access. THAT is the difference.

In order to bridge the PAM ecosystem with whatever authentication method you have you need to go onto _every single PVE Node in a cluster manually and reconfigure them to do this_. Whether it's creating each new user/modifying them on each node, adding each node to the AD domain and then extending PAM, or many other different permutations of manual work (which by the way _IS FULLY UNDOCUMENTED in Proxmox's documentation_, somehow you completely missed the documentation you linked to _does not show any methods for how to interface PAM with the AD external auth method, let alone other auth methods with PAM_).

This is a stark contrast to every other way you grant/revoke/manage access in the Proxmox (VE/Backup Server/etc) ecosystem which is done via the webGUI.

This isn't about whether it's magic or not, this is about a substantial shortcoming in the Proxmox ecosystem for access control. The very reason anyone uses Proxmox VE over manually rolling their LinuxKVM/QEMU hypervisors is the automation, webGUI, and other conveniences. Having that fall short for an important access control aspect defeats that whole point.
 
BloodyIron said:
You're completely failing to see ...
Click to expand...
Okay, your situation seems to be very different from my (really small) environment. Sorry, I can not help you - I just wanted to show one possible approach...
 
UdoB said:
Okay, your situation seems to be very different from my (really small) environment. Sorry, I can not help you - I just wanted to show one possible approach...
Click to expand...

It's really hard to not want to jump down your throat when I clearly spell out earlier in this discussion that this is a scaling problem _which you directly quote me as saying_. Yes I understand at the scale you speak to there are ways to do this, but that does not detract the value of what I speak to here.

This isn't me trying to ask how to do this, I'm literally a Samba SME and my company is listed on their support pages (plus I directly work with the Samba developers, and more).

This is about asking more from the Proxmox developers on improving this area, for VE, Backup Server, and more. Because I see this as a substantial problem that is going to grow over time. It affects me now, and is going to affect many others more and more over time.

Consider that for larger VMWare environments that want to migrate to Proxmox VE, they're going to look at details like this and decide it isn't worth it. Because their clusters are hundreds to thousands of host hypervisor nodes in count. The last thing that the Proxmox ecosystem needs going for it is more reason for environments like these to _not_ migrate to Proxmox VE right now, with the whole Broadcom situation.
 
  • Like
Reactions: Johannes S and tcabernoch
If you can't prove who did what actions on an IT System that needs to be audited, then you can't complete audit. This is a hard limitation in environments that require such auditing, whether it is for periodic certification of the environment, or ITSEC forensic purposes. This will be a reason why Proxmox VE cannot be implemented in certain environments, and that's just one example.

The problem here is tangible and real.
 
You must log in or register to reply here.
Top Bottom