Feature Request: Please address SUDO security

[jgh]

1. Insecure sudo commands

Please supply sudo least privilege commands. At this time, I have this entry and it works perfectly, however still insecure:

Code: Select all

    Defaults:svc-veeam-guest!requiretty
    Cmnd_Alias VEEAM_FLR = /bin/uname, /usr/bin/scp, /bin/arch, /bin/mount, /bin/sh, /bin/rm, /tmp/*
    svc-veeam-guest ALL=(ALL) NOPASSWD: VEEAM_FLR

However, this is still more open that we would like. Specifically /bin/rm and /tmp/*. This is still far better than letting Veeam have access to run every command without a password on our systems.

2. Turn off !requiretty in SUDO configuration

If ssh -T is used to connect (as I believe the FLR is doing), the tty is disabled by default (the below is taken from the man page, and I've done this in practice many times)

Code: Select all

 -T      Disable pseudo-tty allocation.

3. Disable NOPASSWD in SUDO configuration

Since the password is supplied on the Veeam application when doing the backup, and the same credentials are used for the restore, is it possible to feed this password back through the API during restore operations and use a password? With this method, we could require the password and maintain more security for FLR Other-OS restores.

4. Remove SUDO configuration

At this time, if you have the restore update the /etc/sudoes file with the required commands for the restore, that access is left after the restore is complete. This is very insecure, as this leaves access open for this user irregardless of restore status.

These requests are a result of support ticket 01732540.

Thanks,
Jason

[PTide]

Hi,

Thanks for the heads up. We will discuss this internally and update the thread once we come to any conclusion.

Thank you.

[chrisdearden]

Was any conclusion reached on this ? particularly the NOPASSWD side.

[tsightler]

To play devils advocate, requiring a password for SUDO doesn't inherently add any significant security for an automation/service accounts. Requiring a password for SUDO is normally done to protect interactive accounts since those are most at risk from simple attacks like, for example, a user sitting down at an unlocked terminal.

However, for automation/service accounts, the only additional protection it provides is if an attacker somehow manages to get access to this service account but not have the SUDO password. This is a measurable risk with a persistently running service, but Veeam is not a persistent service, the account is used only as long as is required to perform the request action and then it is logged out. No interactive users should be using the same account and no persistent services are running to provide an attack vector.

If we support a SUDO password for the Veeam service account we would also have to store this password in our database (i.e. both the key/password to login to account and the password to SUDO stored in the same place) and, more importantly, because SUDO requires the password to be provided in plain-text, we'd have to decrypt the stored password and send it across the SSH tunnel in plain-text. Of course this should still be safe because the SSH tunnel is itself encrypted, but it's questionable if requiring the decryption of a password and sending it in plan-text to a shell is really adding much safety to an SSH authenticated session.

[chrisdearden]

In this instance, I believe the customer was running centrify, so just needed to re authenticate with the same password?

[tsightler]

I know Centrify offers an alternative to sudo, DirectAuthorize (dzdo) and perhaps it does not have a NOPASSWD equivalent since I believe it authenticates to AD groups so it may need the password again regardless. My response was more to the older post in this thread that implied it could improve security as I believe at best it a net-neutral move from a security perspective.

That being said, most tools that use sudo do at least offer support for sudo that requires a password, so I'm not arguing against including it as a feature so much as simply pointing out that it's not really going to change the security profile very much.

[joebranca]

We are working on our Unix PaaS team to convince them to get their VMS off Networker backups on to Veeam for a standardized backup service. The snag right now appears to be FLR credentials. Our Security group has set out goals for all admin-ed servers to be using two factor authentication (Duo in our case), and local root SSH is obviously disabled. So this seems to pose a problem for our Linux FLR operations, as I assume there are no plans to implement 2FA capabilities in FLR operations. So that is a feature request at least.

What is the best workaround? Dedicate a local user account on each Linux VM, using SSH keys, and add to sudoers? The other problem is one of our Linux admins does not like giving generalized root privilege to an account like this, he would rather button it down to what specific processes are needed to be run by the user, but I can't seem to find information on that either.

I hope that is clear, and thanks in advance for any pointers. It seems the increasingly restrictive access policies being implemented especially with our Linux VMs is making self service FLR less and less doable, at least in a straightforward way.

joe

[joebranca]

Bumping --- anyone else running into restrictive Linux access scenarios with FLR operations?