0

I and a friend are administrating a fair number of virtual machines, each one dedicated to some task in the overall system. When we need to administrate them, we typically log in as root, since the only time we log in to the machines at all are when we need to perform administrative tasks in them. We do not use sudo, since every command we do will typically be a sudo command.

We would prefer to keep our accounts separate on these machines, to give us separate .bash_history, see when the other one was last logged in, etc. To do that, we will need two accounts with full root permissions.

One method is to change our normal user accounts to have UID=0 GID=0, i.e. the same as root, however I was dissuaded from that solution in this question: Are there any gotchas with granting a user root privileges by making them UID=0 GID=0?

[That question is the same as this, up to here]

The answer in that question was to use sudo, but as I mentioned, sudo is very inconvenient for our use case. Almost all commands done on those VMs are sudo-commands (and | sudo tee >\dev\null for every output redirect is mind numbing!), so sudo is likely more inconvenient than having separate histories and other account logging is an advantage.

My follow up question then becomes: Is there a reliable way to make several user accounts behave as root, apart from sudo? Or is there a way to make sudo more convenient (apart from sudo -i which defeats the purpose).

00prometheus
  • 761

2 Answers2

3

If you use sudo -s your $HOME is not updated, so your shell history is kept within your own account.

(Bear in mind that other configuration/history files, such as those created by vim, are also created as root. This means that you may end up with files owned by root in your home directory. This can create "interesting" situations when you want to modify them without being root, and occasionally you'll need to run something like chown -R myusername "$HOME" to fix it.)

Chris Davies
  • 116,213
  • 16
  • 160
  • 287
  • 1
    This one really seems to give me what I want! I just made the assumption that sudo -s would put my history in /root, but I didn't check! Doh! – 00prometheus Aug 14 '17 at 19:56
  • We will probably always do sudo -s immediately after log in on these machines, so likely all files in our home directories will be owned by root, but since we will always be root anyway, that will be no problem :-) – 00prometheus Aug 14 '17 at 20:00
  • 1
    @00prometheus forewarned is forearmed, and all that... – Chris Davies Aug 14 '17 at 20:18
  • This does not work out of the box on Fedora, RHEL, or CentOS. Both always_set_home and env_reset are on in the default /etc/sudoers. I think this is a sensible default and the caveats in the "Bear in mind..." parenthetical are pretty important, and I'd really recommend against this. – mattdm Aug 14 '17 at 20:27
  • Thanks for that heads-up! We are Ubuntu based, but we should keep that in mind when distributing /etc/sudoers to the VMs. And yes, there will likely be one caveat or another to bite us at some point, but this is close enough to make me happy! At least I will be happy until I have tried it; later on we will see what my mood is after I have tried it! ;-) – 00prometheus Aug 14 '17 at 20:32
  • Hmmm, we could our add our users to group "root", and umask 002, to mitigate the problem. – 00prometheus Aug 14 '17 at 20:40
  • Apart from ~/.ssh - that will have to belong to the user. Oh, well, I'll need to try this out for a while! – 00prometheus Aug 14 '17 at 20:44
  • Adding users to the group root is probably functionally identical to giving them root. – mattdm Aug 14 '17 at 21:11
  • @mattdm not here on Debian-flavoured systems. Case in point: passwd {some_other_user} works as root but does not work otherwise. – Chris Davies Aug 14 '17 at 21:48
  • Sorry, I wasn't clear. I mean that putting users in the root group probably gives them an easy escalation path to full root. – mattdm Aug 14 '17 at 22:30
  • @mattdm I'm not aware of any reason why that should be so. The root group is not like the Administrators group under Windows, and has no particular rights implicitly given to it. – Chris Davies Aug 14 '17 at 23:56
  • It is very possible that there are files belonging to group root which could be modified to escalate to the root user. I'd really recommendations just not. – mattdm Aug 15 '17 at 03:29
  • Adding the users to group root and setting the users' umask to 002 was mainly to mitigate the problem of lots of files belonging to root showing up in the users' home directories. – 00prometheus Aug 16 '17 at 12:19
  • @00prometheus I don't see how adding a user to a group will change the ownership of files being newly created. – Chris Davies Aug 16 '17 at 14:38
  • @roaima They won't, but they will let the user access and delete the files created as root that are in their home directory, so it is just a mitigation. Also, note that in this very particular use case, all user accounts that will ever exist on these VMs belong to people that have administrator privileges for the VM. Remember that the current situation is that we both simply log in as 'root' directly. – 00prometheus Aug 16 '17 at 18:11
2

Here's how we handled this at a previous job.

First, we had a secure bastion host that admins logged into for all root access to target machines. This host had a special keymaster account configured which held private keys corresponding to root on the target hosts. (We also had a system where new hosts would automatically register themselves. But that's outside of the scope here.)

Admins would log into this bastion host with user-level accounts, and then connect out to the target systems.

Except for the few of us with access to root on the bastion host itself, no admin could actually access the keys directly; instead, they used a connect command run under sudo (as keymaster, not root) to connect. That connect command set the environment variable REMOTE_ADMIN to be the name of the connecting user, and connected as root to the target system.

Then, the remote systems were set to have AcceptEnv=REMOTE_ADMIN in sshd_config, and .bashrc files to set BASH_HISTORY to ~/.bash_history-$REMOTE_ADMIN.

With this setup, the different .bash_history files aren't secure records, but they're at least distinct for the purposes of non-malicious looking back at what happened. The security record is on the bastion host, showing who connected when. (We used 2FA for the sudo connect command, too.)

Additionally, short of subverting the hosts, there's no need to worry about root access outside of the designated system (whether malicious or just for "convenience"). And while keys can be retired, there's no need to do so just because someone's access level has changed.

You could use all or part of this solution; simply having .bash_history-$SUDO_USER might be sufficient, depending on what you're really trying to accomplish.

mattdm
  • 40,245
  • This is at least gives some mitigation to the problem! It doesn't give the full logging a real account would give, but at least we get our own histories! – 00prometheus Aug 14 '17 at 19:20
  • You can't really have full logging of a system where you're letting people have root, anyway. We also used a version of bash which sent all commands to remote syslog, but this is easy to circumvent. The audit logs are a little better, but... when you've got people as root, it really comes down to trust. – mattdm Aug 14 '17 at 19:22
  • Well, trust isn't the problem, it is more about having a way of going back to see what was done and when it was done for those times our manual logs are insufficient. – 00prometheus Aug 14 '17 at 19:24
  • Any system must have at least one root admin, and any critical system must have at least one redundancy, so there must always be at least two root admins. I can't believe there is no commonly used best practice solution to this! – 00prometheus Aug 14 '17 at 19:32
  • 3
    I think best practice these days is to have no humans log into boxes directly ever. Changes go into config management which goes through code review and is then pushed to systems. If something goes really wrong, you blow up the machine and build a new one. – mattdm Aug 14 '17 at 19:45
  • But this is probably a better topic for http://serverfault.com/ – mattdm Aug 14 '17 at 19:45
  • LOL, yes, you are right I suppose. ansible, docker and restore from backup every time something fails. I am getting too old for this stuff! :-) I did ask the question at Superuser, but that got me a Tumbleweed badge. Serverfault seems more about networking stuff. The question seems to be too arcane for other forums than this one. – 00prometheus Aug 14 '17 at 20:03
  • Check out roaima's answer! It's such a Doh! that I am blushing! – 00prometheus Aug 14 '17 at 20:06
  • Serverfault is for sysadmin topics in general, not just networking. – mattdm Aug 14 '17 at 20:28
  • You are likely right, the networking bit at Serverfault was just a general impression I got at some point. – 00prometheus Aug 14 '17 at 20:45