Please vote for feature request: Add sudo to ESXi

[peetz]

Hi all,

talking about AD integrated ESXi hosts. With ESXi 5.0 VMware has introduced an important improvement in AD integration by making the name of the infamous "ESX Admins" AD group configurable (see my blog post here for instructions and an explanation of why this is important).

However, there is still a problem: You can log on to a local or remote console using an AD account that has administrative rights, but you won't have root privileges in this session, e.g. you cannot edit any configuration files, restart services etc. To gain root rights you need to use su, but that means that you still need to know and enter the password of the root user! From a compliance standpoint this is not acceptable, because the whole point of AD integration is that each VMware administrator uses his AD account for administration and does not even know the root password - to make sure that each change to the system can easily be related to a personal account (Well, for emergency cases e.g. when AD authentication is not available you still need someone who knows the root password or e.g. has it written down on a piece of paper in a sealed envelope).

The easiest way to achieve this would be to use the sudo command in the ESXi shell to run commands in root context without the need to know root's password. This is common practice when managing Unix/Linux servers.

Now the point is: sudo used to be available in ESX, but it is not available in ESXi.

So, my feature request for VMware is that easy: Add sudo to ESXi! It is the missing piece that would make AD integration a success story, finally.

Now give me your +1's ! (or tell me that I'm wrong and why 😉

Thanks

Andreas

[mcowger]

I've asked for this in the past to the PM.  Was told flat out no.

VMware's stance is that anything you are doing thats changing the ESXi host shouldbe done through the API, which already has separate authentication schemes.  Not that I agree with this, but thats what I was told.

[peetz]

So, why do they not disable the shell completely then?

Even PMs can change their mind, so let's try it I will file a feature request through my TAM anyway, but having supporters here in the forum should put additional pressure to it.

[wila]

Andreas,

Agreed. +1

At least when the user uses sudo you get a proper audit trail. When the root password can be used it is easy to "fly under the radar" which really is a no go.

--

Wil

[dhabbetichandra]

Agreed

[Rubeck]

I for sure want to give a +1 on this request...!

/Rubeck

[Masa2]

I also agree. +1 for me as well please!

[iwienand]

We've heard this request before, and in the next release after 5.0 we are working on a slightly different model that acheives the same thing wihtout the need for sudo.  Anyone who logs in will effectivley be root (i.e. getuid() will return 0), although for logging and audit purposes you will see who as logged in, and of course they are using their password.

The reflects the reality of the situation that you can effectively do nothing on the host as a non-root user.  Once you go "underneath" the API by logging in directly, you can consider the host compromised.

What we're really interested in is any part of the API's that are deficient to the point that you need to resort to logging in directly.

[wila]

Umm, no it is not the same at all. With sudo every command run through sudo gets written out to the log, so you as administrator can determine if the host is compromised or not by extracting that info from the logs.

What you are saying is that basically one should destroy every host that has been accessed via the root account... as it is now no longer trusted...

Sure there are valid reasons for accessing the console and NO the APIs do not always solve that, take the simple example that you miss network connectivity. How are you going to solve that "through the API"? You cannot, you might be able to do a reinstall if you have a PXE server setup, but that won't always be the case. With console access you can solve it, but there's no detailed log of the changes / troubleshooting steps made by the user as they have to be root...

I also wonder how you can see "who has logged in" if it is going to be root anyways? Direct console access? What will it log? Every user logging in remotely will be lifted to root levels? Automatic sudo? Ewww...

thanks for your reply

--

Wil

[peetz]

Thank you for your response!

I like the idea of every user user logging in automatically having root permissions (without the need for sudo). This more resembles the Windows model where you are either an admin or not. It doesn't offer the granularity of control that you have with sudo, but on the other hand you also do not have the effort of configuring this granularity through /etc/sudoers.

However, wila is making a good point about logging: That is important, so having every console command sent to syslog (including time stamp and the original user id issuing it) is a necessity.

According to your question: I'm not really concerned about the API missing a functionality that you have with console access only. We need the console access in situations where API access is not available remotely (because the management network is down), or not at all, because hostd is malfunctioning or has crashed, or when the host as a whole becomes unresponsive, e.g. because of hardware related issues or special heap memory pool exhaustions.

I am aware that hostd (and ESXi as a whole) has a very high overall code quality, but every software has bugs, and I experienced quite a few issues in the past that made it necessary to access the console, because you could not use the API.

- Andreas

[iwienand]

With sudo every command run through sudo gets written out to the log, so you as administrator can determine if the host is compromised or not by extracting that info from the logs.

This assumes that you forsee the set of binaries you want used via sudo and limit them such that you are 100% sure that none can be used to escalate your privileges further and then subvert the audit logs; e.g. you give someone sudo access to vi -- of course useful to edit config files -- but they can then use '!' to run aribtrary shell commands (actually, I don't think ESXi vi does let you do that, but you get the point).

A restricted environment is not the idea of our trobleshooting shell -- it is, by design, full and complete access to the system for unforseen circumstances. 

What you are saying is that basically one should destroy every host that has been accessed via the root account... as it is now no longer trusted...

I would not go that far; we have login and shell audit logs (/var/log/shell.log, /var/log/auth.log) that help establish what has gone on.  If you are sending logs across the network to a secure host, you at the very least have the login and the first thing that was run that can not be subverted.  You would have to evaluate what has been run from that point to see if you trust the logs.

Sure there are valid reasons for accessing the console and NO the APIs do not always solve that, take the simple example that you miss network connectivity.

The managment interface should be recoverable via the DCUI interface; which is a secure subset of configuration options (you can not run arbitrary things from it).  Again, we're always looking to make things better, so suggets for what doesn't work here are always appreciated.

I also wonder how you can see "who has logged in" if it is going to be root anyways? Direct console access? What will it log? Every user logging in remotely will be lifted to root levels? Automatic sudo? Ewww...

Users authenticate as usual, a record of which gets sent to the audit logs.  Once authenticated, all shell users are considered as uid 0.  The logs in /var/log/shell.log retain the username of the person executing them.

[vogtmatt]

Here, here!! +1

[jobl]

+1 from me to!

[AWoroch]

Put me down for a +1.  I can understand why they'd want to say you shouldn't be doing anything as root, etc.  But if you're going to enable root, then let's enable sudo so we can do some kind of auditing.  Best practices say that there shouldn't be shared logins, and this is the only good way to comply.

[MisterTrep]

YES YES YES

[garank]

i agree, +1

[blahblahblah123]

this has my vote, either sudo, or equivalent(with logging).

[blahblahblah123]

btw, found this for 5.1; not sure if it works yet...

http://blogs.vmware.com/vsphere/2012/09/vsphere-5-1-full-admin-support-for-named-user-accounts.html

[CMitchell3]

Yes please!

[MisterTrep]

YES we need it  !!!!!