78

Should the sole user of a *nix (particularly Linux and MacOS) have two accounts, one with sudo privileges and one without? Years ago I read that on your personal computer you should do your daily tasks as an unprivileged user and switch to a privileged user for administration tasks. Is this true?

Note: I am not referring to whether or not you should log in as root for daily use. That's obviously a bad idea, but should your daily use account be able to use sudo?

Second note: I am specifically referring to personal devices that are not being used as servers or to host any functionality for remote users.

  • 26
    The advice you read might have been meant as recommending that you use a non-root user for daily tasks and root for administration tasks, so just using a regular account with sudo privileges would already be meeting this advice. – Macil Oct 31 '16 at 18:41
  • 19
    I have an unprivileged account that I can sudo to (with no password), but that can't sudo to anything else. It's handy for running software that might have security holes but that connects to the network (like a torrent program) in a somewhat-sandboxed environment: it can't modify my .bashrc or .ssh/, or stuff like that. – Peter Cordes Nov 1 '16 at 1:57
  • 1
    I tried to tag this best-practices, but for some annoying reason that is aliased to defense. Now it won't let me untag that. – smci Nov 2 '16 at 9:02
  • 3
  • 2
    @tylerl I'd argue non-dup because server vs personal computer changes the question scope significantly. – Mike Ounsworth Nov 3 '16 at 14:51
99

Updated dramatically after 69 upvotes, see answer history for original answer. Thanks to @JimmyJames for the discussion.


First, let's talk about threat model: what are you trying to stop the potential attacker from doing?

Threat model: identity theft / ransomeware on a single-user system

Generally for end-user systems the de facto threat model is identity theft / ransomware. If the attacker has access to your documents and/or can run shell commands as you, it's game over. From that perspective, root access doesn't gain the attacker anything; they can get what they want without it.

If identity theft / malware is the only thing you're worried about, then it doesn't seem like it matters much whether your user has sudo powers, or ever whether the browser is running as root.

(I should also point out that malware / connecting you to a botnet can happen without root access since login scripts / scheduling a cron job does not require root).

Randall Munroe at XKCD seems to agree with this view:

Authorization

Lastly, I'll add this disclaimer: Yes, I'm aware that this goes against the general public opinion that "more security is always better". It's just not true. Sometimes more security is worse, like overly complex password policies that end up forcing people to write down their passwords. You always have to look at the risks and decide how much security is actually appropriate. In this case there's no harm to locking down root access, but you are making your life more complicated and it's not clear that you're gaining anything from it.

Threat model: root access or multi-user system

If you have a threat model where the attacker wants something that only root has access to, or there is more than one user account on the machine, then the answer actually depends on which *nix you're talking about. This is quickly getting away from personal computer cases and into server cases, but I'll discuss anyway. For linux, because of a bug (*ahem feature*) in the Xorg windowing system, your everyday account should probably not have sudo powers. For operating systems that don't use X, it's probably ok.

Linux (running X.org window system)

Here's a great article that shows you how to log all keystrokes on a gui linux machine using a simple user-land (non-root) shell command. In summary:

$ xinput list shows you all connected human-input devices

$ xinput test <id> starts echoing all keystrokes on the selected device.

I tested and I get logs of the password that I type into sudo in a different terminal window. If I lock my computer then when I log back in, I see logs of the password I typed into the lock screen. Apparently this is not a bug in X, it's a feature. Right, I'm gonna go hide under my bed now.

So yeah, this supports the idea that any user you log into in the gui with should not have sudo powers because it's trivial to log your password and then become root. I suppose you should have a dedicated account for sudoing and switch to a TTY terminal (ctrl+alt+#) when you want to use sudo. Whether or not this is worth worrying about is up to you: personally, all the data I care about is already there in my user account, but I probably will change my laptop setup because I'm a security nerd.

Note that in my tests I was not able to keylog across users. Doing "Switch Account" in the gui, or startx in a new tty terminal seems to launch an isolated instance of X.

Thanks to @MichaelKjörling for this observation:

That's one of the things that Wayland [windowing system designed to replace X] actually tries to fix (see the bullet point on security). Remember that X11 originated at a time when the threat model was hugely different from what it is today.

For sysadmins: this reinforces the habit of only interacting with your Linux boxes over ssh, never use the GUI.

Mac OSX

I'm not an OSX expert, but I know that it does not use the Xorg server so I would assume that Apple's GUI handles this properly, but I would love for someone more expert than me to weigh in.

Windows

I'm not a Windows expert either, but I believe that the User Account Control (UAC) feature introduced in Windows 7 addressed this by having admin prompts render in a secure desktop whose input busses are isolated from your regular desktop.

  • Let us continue this discussion in chat. – JimmyJames Nov 2 '16 at 19:47
  • 1
    To expand on this concept, using more than one user account only really protects you if you spread your workflow across those accounts to protect your data. For example, only access your bank accounts and financial/personal information on one account, and use a different account for the rest of your less important/more risky internet operations. Maybe use a third one just for your email. Qubes-OS takes advantage of this philosophy but at a more separated level, running separate virtual machines for different tasks. – cscracker Nov 3 '16 at 17:23
  • 1
    @MikeOunsworth: Thank you for pointing out the major security risk inherent to X. If I understand correctly, that attack is only useful if the attacker has access to an account on the machine. In my case I'm the only user on my personal machine, so if an attacker can run xinput it's already game-over. Do I understand you / the situation correctly? On a side note: How are people not upset about this huge vulnerability in X? – Ender Wiggin Nov 3 '16 at 18:36
  • 1
    Hmmm - odd bug won't let me shift them over... will look into it. Can folks please use the chat for ongoing discussion? thanks – Rory Alsop Nov 3 '16 at 19:40
  • 3
    @MikeOunsworth That's one of the things that Wayland actually tries to fix (see the bullet point on security). Remember that X11 originated at a time when the threat model was hugely different from what it is today. – a CVn Nov 4 '16 at 15:04
26

In most situations, requiring a password with sudo is sufficiently enough protection.

The primary difference between suing to another account and sudoing to gain privileges is that with sudo you enter the same password you used to log in. If your threat model assumes that an attacker has your account password, then you're already in pretty deep trouble, more than another password on the root account will protect you from.

  • 4
    Re: entering the same password for logging in, you can set targetpw or rootpw to change that, of course. – muru Nov 1 '16 at 1:54
  • 1
    sudo can only stop legitimate users and programs that don't want to go too far. But for a hacker, it's easy to set up programs imitating sudo, or run sudo before the time out, and get the permission the next time the user uses sudo. – user23013 Nov 1 '16 at 19:34
  • They could do the same thing with su. – Xiong Chiamiov Nov 1 '16 at 20:12
  • 2
    "with sudo you enter the same password you used to log in" -- This is configuration dependent. See the rootpw and runaspw flags in sudoers. – Ben Voigt Nov 3 '16 at 15:46
6

I have found that having two accounts on my unix systems is essential for the following reason:

If I ever mess up my .bashrc or other login / terminal setup files I can get into a sitution where I cannot even log in. So I am totally borked. This is the worst situation imaginable as you can't do much if you can't log in.

The only way I was able to fix this on a couple of computers was having the other login which allows me to go in and using sudo, fix the startup files for my primary account. I then log out of my account'2' and back into my regular account.

Sometimes I might be able to use the boot from USB option but to be honest I find being able to log into another account, use sudo and fix my .bashrc then logout and back into the other account can all be done in a few second with the second login and much less scary / unfamiliar than the USB boot to fix option for me. Of course YMMV (Your Mileage May Very)

  • 1
    Can't you login as root in order to fix the problem? – enkryptor Nov 1 '16 at 10:37
  • @enkryptor: depends on your distro. For example Ubuntu disables the root account by default. So on an Ubuntu system, if you've enabled the root account for login by doing "sudo passwd root" then arguably you've already created two accounts, albeit that's not what the questioner is talking about :-) And if you haven't enabled it then no, you can't login as root to fix the problem. – Steve Jessop Nov 1 '16 at 11:46
  • 8
    You can use recovery mode from GRUB or boot a Live CD to fix it. – user31389 Nov 1 '16 at 13:45
  • 2
    @user31389> Not if it's a remote server. Or it might cost you a fee, depending on the hosting provider. – spectras Nov 1 '16 at 18:12
  • 1
    @XtraSimplicity On your own desktop, sure. A hosted VM? You won't have access to it from outside the virtualization environment. It's the same as with a physical server in that respect. Higher-end hosting providers will let you access OOB management (such as DRAC or IPMI), mid-range will just offer rebooting on a rescue image. Lower end will typically have you request manual intervention from their teams for a fee. With VMs the tools change but the concepts will be the same. – spectras Nov 2 '16 at 6:53
1

I'm using this setup, but the reason goes beyond a single system.

If you want backups which provide some protections against ransomeware (and you don't like to assume no-one will write ransomeware for Linux), you need to be backing up to an external system which keeps multiple revisions.

However, I haven't got a dedicated workstation/terminal for administration of the backup server. Logging in as a separate user for this (not using su) provides one layer of protection here. If my normal login had sudo privileges, there'd still be a speed bump, but it would be pretty thin (obscurity, and malware would have to capture the sudo password).

0

What is the benefits of sudo ?

You don't need to share the root password with every user to perform some type of administrative tasks on your own system.

The authentication automatically expires after a short time (15 min) and you can set timestamp_timeout=0 under /etc/sudoers to makes the sudo password expire every 0 (zero) seconds. This means that every time you use sudo, you will be asked for the password.

What is the disadvantages of sudo :

When a user use a weak password it will allow an attacker to quickly crack the user password and elevate the privilage to get the root access

The root password can be locked by default in some linux distro like Ubuntu. Why?

Because in the presence of the root account , an attacker will try the first time brute-force the root password. It will be more complicated if the root account is disabled .

A user can change the ownership of system files by knowing the root password or harming your system by executing a malicious programs.

  • I don't see how this discusses the relative merits of having one versus two accounts (one with and one without sudo privileges). Could you edit to clarify that? – a CVn Nov 4 '16 at 15:15
0

All PC users should have at least local admin, but common sense dictates this be password protected (Android users note this.). Depending upon usage I see no reason why there cannot be just one account. This is the case for Puppy Linux and has been quite successful for years. However it is good to have two levels of protection and a separate /sbin folder for those times we are clumsy and/or foolish. It is one thing to butt dial someone, it is another to butt delete directories. Lazy users will just add all they need to the sudoers file. Privilege escalation generally relies upon having access to some account in the first place, so we control this. Accounts on servers and appliances need to be justified, and we care about our workstation being used as a defacto appliance against us. The point is, for many PC's there is no other real user.

0

Every machine needs a admin account, whatever the OS. Ok, most Linux flavours hide root user by giving it an inexistant password - in the sense that any input will return false - but root does exist and has user id 0.

That admin account can change anything to the system, including things that are not allowed to normal users. The line of defense here, is that if an attacker gains access to the root user by chance (*) he can easily install a backdoor to be able to gain it again at will. And you will hardly notice it unless you consitently analyze the security of your systems (logs, changes in system files, ...) on a regular base.

If an attacker gains access to a non root account by chance, he will only be able to make changes to what is accessible to this account. Ok, he could change the password if he managed to get a shell, but you will certainly notice it next time you try to login!

That means that the defence line of not using root is only against distant attacks - if somebody has physical access to a machine, he can read everything that in not strongly encrypted and write/erase absolutely everything - including the password database to add other admin accounts. The only exception here is that if the whole disk is encrypted, the only possible action is to erase everything and fresh re-install.

But I admit that even if I know that sudo is a great software and can be used to allow fine grained permission. I do not like very much the default Linux way where sudo can do anything, because it is vulnerable to this:

  • an attacker gains access to a non root shell allowed to sudo
  • he changes the account password
  • he sudoes as root and installs a backdoor (or a modified version of su that asks no password - trivial to write)
  • he breaks the master password file and goes away

Next time you try to login, you will notice that you cannot, use the recovery procedure to discover that the master password is broken, rebuild it or re-install it from an archived version and if you do not carefully analyze the system, never notice the back door.


When I said gain access by chance, I mean in a non reproductible way, for instance, if it uses a vulnerability when you connect to a malicious site. Unless the attacker install a backdoor, he will only gain access again when you come back to that site, which may or not occur.

TL/DR: My opinion is that any machine should have at least 2 account: one non priviledged one for normal usage, and an administrative one for administrative tasks.

-2

Aren't backups the solution to this problem? Backing up the entire hard drive on a regular basis looks like a good idea in general for various reasons, the possibility of screwing up .bashrc is one of them.

  • Backing up is the solution if the OP is concerned with ransomware. However, they don't help if the OP is concerned with malware or identity theft. – Mike Ounsworth Nov 1 '16 at 12:15
  • I found that backing up the entire hard drive is a bad idea for various reasons as well. I turned to backing up just /srv and /home, and using a configuration management tool (namely, ansible) to recreate the rest. Logs are lost in the process, but you could back them up too or, better, have them copied to a remote server on the fly. – spectras Nov 1 '16 at 18:17

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.