Comprehensive data protection for all workloads
Post Reply
jgh
Novice
Posts: 6
Liked: never
Joined: Mar 10, 2016 11:10 pm
Contact:

Feature Request: Please address SUDO security

Post by 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
Product Manager
Posts: 6408
Liked: 724 times
Joined: May 19, 2015 1:46 pm
Contact:

Re: Feature Request: Please address SUDO security

Post by 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
Veteran
Posts: 1531
Liked: 226 times
Joined: Jul 21, 2010 9:47 am
Full Name: Chris Dearden
Contact:

Re: Feature Request: Please address SUDO security

Post by chrisdearden »

Was any conclusion reached on this ? particularly the NOPASSWD side.
tsightler
VP, Product Management
Posts: 6009
Liked: 2843 times
Joined: Jun 05, 2009 12:57 pm
Full Name: Tom Sightler
Contact:

Re: Feature Request: Please address SUDO security

Post by tsightler » 1 person likes this post

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
Veteran
Posts: 1531
Liked: 226 times
Joined: Jul 21, 2010 9:47 am
Full Name: Chris Dearden
Contact:

Re: Feature Request: Please address SUDO security

Post by chrisdearden »

In this instance, I believe the customer was running centrify, so just needed to re authenticate with the same password?
tsightler
VP, Product Management
Posts: 6009
Liked: 2843 times
Joined: Jun 05, 2009 12:57 pm
Full Name: Tom Sightler
Contact:

Re: Feature Request: Please address SUDO security

Post by tsightler » 1 person likes this post

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
Enthusiast
Posts: 49
Liked: never
Joined: Oct 28, 2015 9:36 pm
Full Name: Joe Brancaleone
Contact:

[MERGED] Linux FLR credentials - 2FA support or workarounds?

Post by 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
Enthusiast
Posts: 49
Liked: never
Joined: Oct 28, 2015 9:36 pm
Full Name: Joe Brancaleone
Contact:

Re: Linux FLR credentials - 2FA support or workarounds?

Post by joebranca »

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

Who is online

Users browsing this forum: Bing [Bot], Google [Bot], Semrush [Bot] and 208 guests