Reason no sudo in default install

[proximity]

Hi,

I wondered if there is any security or other reason besides that sudo is not in default debian install that it is not included in proxmox.

thank you

 

[fabian]

it's just not used for PVE itself. if you want to use it, feel free to install it.

 

[esi_y]

it's just not used for PVE itself.

Why? Is this something to be considered given the increased security with the flexiblity of sudoers config and groups for limited set of commands PVE needs at its disposal?

if you want to use it, feel free to install it.

This is the closest I had found anyone asked over 10+ years on a forum related to sudoers. In this I detract from the OP's question - it's not the issue of not having it installed, but PVE not already taking advantage of it as a basic building block - it barely touched the security-conscious setup in e.g. separate pvedaemon from pveproxy (running under www-data).

EDIT:

NB: There's many posts which are attempting on increasing security of their installs, e.g. running zfs receive [1] or disabling root [2], but it's all just afterthoughts, nasty to manage manually on a large cluster.

NOTE: This is NOT the same as scope of Bug #2852: "add special privilege Sys.Root" [3].

[1] https://forum.proxmox.com/threads/how-to-create-a-user-that-only-can-zfs-receiv.139213/#post-621915
[2] https://forum.proxmox.com/threads/disable-root-account.83967/#post-607562
[3] https://bugzilla.proxmox.com/show_bug.cgi?id=2582

 

[fabian]

sudo is not the right way to implement unprivileged services - but of course, reducing the amount of code running in root context is something we want to do, but it's a fairly involved process given all the flexibility PVE offers (e.g., things like custom storage plugins, arbitrary storage paths, .. are all far from trivial to handle correctly with a good user experience out of the box).

as a sidenote - many many setups out there using sudo are not locked down in the fashion the admin expects, a lot of things offer practical root shells when executed via sudo, even if the sudoers config itself restricts which commands are "allowed" to be used. that doesn't mean it doesn't have its place, but it's very easy to misconfigure/misuse and give a false sense of security.

 

[esi_y]

sudo is not the right way to implement unprivileged services

I just want to reduce the scope of my follow-up Q here to basically what I think the OP was after as well, i.e. shouldn't the root user be password-less and human admin be forced to log in under separate cred, as a starting point. He could be a general sudoer to begin with, later it could be even cut down to only PVE's CLI suite. I understand this needs couple of changes including in installer, but it's something that would increase security as in prevent at least some human error (people go copy&paste all sorts of things into that # shell).

PVE's API restricts one quite reasonably in managing the cluster, but as far as I know there's no CLI external tool to run on a separate machine as the whole architecture is monitor-less.

- but of course, reducing the amount of code running in root context is something we want to do, but it's a fairly involved process given all the flexibility PVE offers (e.g., things like custom storage plugins, arbitrary storage paths, .. are all far from trivial to handle correctly with a good user experience out of the box).

I figured, I didn't want to nitpick on this, as long as it's rapidly changing system I understand the argument could be made the security gains are smaller than the complexity it adds on if it's kept within select components.

as a sidenote - many many setups out there using sudo are not locked down in the fashion the admin expects, a lot of things offer practical root shells when executed via sudo, even if the sudoers config itself restricts which commands are "allowed" to be used. that doesn't mean it doesn't have its place, but it's very easy to misconfigure/misuse and give a false sense of security.

I know the blanket answer could be just secure the management network access, so my question was mostly related to the "human error" and also sort of brining awareness when something more involved is going on, e.g. one could be asked for password for pvecm add, but not bothered with the same for pveversion.

 

[fabian]

I just want to reduce the scope of my follow-up Q here to basically what I think the OP was after as well, i.e. shouldn't the root user be password-less and human admin be forced to log in under separate cred, as a starting point. He could be a general sudoer to begin with, later it could be even cut down to only PVE's CLI suite. I understand this needs couple of changes including in installer, but it's something that would increase security as in prevent at least some human error (people go copy&paste all sorts of things into that # shell).

you can do that already if you want, nobody's stopping you there's a slight caveat w.r.t. shell completion breaking, but that could possibly be fixed. the gain of setting that up by default is very little, but it adds a potential source of problems (if you often paste things into a shell without checking them, you will also paste things into your shell that start with "sudo").

PVE's API restricts one quite reasonably in managing the cluster, but as far as I know there's no CLI external tool to run on a separate machine as the whole architecture is monitor-less.

you can use whichever API client you want, including building one that gives you a CLI interface to manage remote PVE hosts.

but like I said - making more parts of PVE run as unrestricted user, and potentially also allowing execution of the CLI tools (as the logged-in PAM user) is on our long-term agenda, it's just a massive undertaking that won't happen overnight.

 

[esi_y]

(if you often paste things into a shell without checking them, you will also paste things into your shell that start with "sudo").

I take it like "me" represents an average person, out of being kind to myself, in that sense ... I know a lot of people who do curl | bash, but they become vigilant once it asks to confirm their pwd - psychologically it works.

you can use whichever API client you want, including building one that gives you a CLI interface to manage remote PVE hosts.

I just wish I could separate apt install the shipped for PVE.

but like I said - making more parts of PVE run as unrestricted user, and potentially also allowing execution of the CLI tools (as the logged-in PAM user) is on our long-term agenda, it's just a massive undertaking that won't happen overnight.

Noted, thanks,.

 

[esi_y]

Just a random thought... Not sure why it struck me now, but having e.g. separate dedicated non-human root (or the other way around, not allow to log in as one) would also allow for e.g. EscapeChar or BatchMode (it's the only way, isn't it) be in ssh_config of that particular user cleanly.

(But I like that it's finally refactored, I really do!)