Hi!

Just to clarify you mean you’d like the service account used by Veeam to interact with the virtual machines to not require root privileges?

Thanks!

Thanks for the question!

No, I mean the user on the Linux Proxy executing the actions such as mounting the snapshot etc. I know that a mount operation during a file level restore needs root permisions but the set of commands where root is required is finite and I would like to configure the sudoers file for this user to exactly this set of commands and nothing more!

Very interesting question! I belief your question is better addressed in the Veeam R&D Forums (https://forums.veeam.com/). Please provide the link here if you ask your question there.

interesting question. 

I'm not a Linux expert, but is it a problem if Veeam uses root permissions? If the proxy server is dedicated to Veeam then what are the downsides?

Also for most tasks on Windows systems Veeam requires administrative permissions; so for me it doesn't look that special/negative.

I agree with @regnor on this, of course it would be possible to reduce the amount of access the user account has, you could even if you had the time and patience, likely review the log files themselves and deduce what permissions are actually required and create just those permissions for the account.

However this will likely sting whenever Veeam introduce changes, either themselves through the active product development or alternatively via OS updates that deprecate commands in favour of others.

By keeping the Veeam Proxy purpose built and using the default setup you’re less likely to have headaches instead thanks to K.I.S.S design (Keep It Simple & Straightforward). It’ll make it easier to audit especially.

Just to say as well, I’m not dismissing your point at all, and I do see value in it, however I also think this could add a lot of burden to Veeam as well with their regression testing and could then require Veeam to limit the scope of Linux supported to ensure they’ve got everything documented 100%.

This is also an issue in our environment. I'm setting up our first Linux based Veeam proxies and our policy does not allow full root permissions via sudo.  Don't forget, this user is used for a remote connection. And I don't think it's good practice that such a user has root privileges.

Of course it is possible to restrict the sudo permissions, however, I always think it’s more of a “feel good” thing vs anything that adds any practical security at all.  Yes, we don’t want to have another account that is root, but this account needs to be able to install software that runs as root, update that software, etc.  Once you give the account enough permissions to do the things it needs to do, it has all the requisite power to break out of the sudo permissions.

I can’t even count the number of times I’ve heard “we can’t just let an account have full sudo”, but then they happily give /usr/bin/cp, or /usr/bin/yum which just means I’m one command away from full sudo or not even needing sudo, so what security was really added?

Also, in the end, there’s a service running (veeamtransportservice) that Veeam will connect to and control for the proxy itself.  This service runs and root, and has to for operations like hotadd, direct SAN/NFS, etc (theoretically, it’s probably not required for this service to be root for NBD), so, after it’s all said and done, Veeam is still getting access to a service which has god like powers and runs as root.

I strongly suggest the focus shouldn’t be on the account Veeam using having sudo, but rather securing access to that account.  Create a public key for auth and encrypt that key with a passphrase, and use only that to connect to the proxy.  Restrict SSH for the veeam user to only the Veeam server IPs and only with public key auth.  This way, pretty much the only way for the account to be compromised is if the Veeam server itself is compromised, and, if that happens, you have way more things to be worried about vs whether that account manages to get access to your proxy or not, because that’s about the least interesting thing I can do from the Veeam server.

Still, here’s a sample of what’s required for a Veeam proxy to be added to infrastructure (not fully tested by me yet, but seems to work for Ubuntu):

User_Alias	VEEAM_SERVICE_USER=veeam_svc
Cmnd_Alias	VEEAM_SERVICE_CMDS=/usr/bin/whoami, /usr/bin/uname, /usr/bin/ls, \
			/usr/bin/mkdir, /usr/bin/rmdir, /usr/bin/rm, /usr/bin/cp, /usr/bin/tar, \
			/usr/bin/touch, /usr/bin/test, /usr/bin/chmod, \
			/opt/veeam/transport/veeamtransport, \
			/usr/sbin/ufw, /usr/sbin/iptables
Defaults:VEEAM_SERVICE_USER !requiretty
VEEAM_SERVICE_USER ALL=(root) NOPASSWD: VEEAM_SERVICE_CMDS

I’m guessing you could probably restrict 90% of these and allow them only during install/upgrade/removal, especially the cp/tar commands which are the ones that jump out to me as the most risk.

Also, the firewall commands are optional and not needed if you either don’t use the firewall, or are willing to manually configure the open ports (the commands will fail but Veeam will ignore this).

I’m still testing this exactly, so I may have to modify this slightly if I come up with any other commands, but it’s pretty straightforward.