tl;dr? Use completely unprivileged accounts for day-to-day tasks, then log out and log in with a privileged, trusted account for privileged tasks; don't use runas or sudo from your day-to-day account; it eliminates the security benefits of using the unprivileged account.
Operating system security has improved a lot in the past 10 years; for example, mainstream OS's have been hardened by the introduction of exploit mitigations and cryptographic libraries have advanced. But there's been a lot of cargo cult security "wisdom" that causes more problems than it solves as well. Most of the time, bad security defaults and decisions appear to block obvious and unsophisticated attacks, but actually increase vulnerability to more common and more serious attacks. One of those is the tendency for many administrators and operating systems to recommend an "escalate yourself" approach to managing elevated permissions instead of separate logins.
Escalating on Linux/OS X
Most Linux distributions' (and OS X's) default is to have administrators log in with their own day-to-day use account that runs with no special privileges, then run "sudo <command>" or a graphical equivalent and type their own password to run a command with root privileges. I'll call this the "single account sudo" solution. To understand the problems with this solution, you have to understand the most likely threats to Linux users, from the hacker's perspective.
The first threat is that of accidentally running malicious code; such as by running a script from the internet or a github repository that turns out to be untrustworthy. 17,000 users ran untrusted code by typo'ing the names of packages while installing something from a package manager; sometimes as root and sometimes under a normal user account. Other very common attacks use macros embedded in office files; although normally not targeting *nix systems, a standard MS Office document macro can run shell commands through OpenOffice just as reliably as through Word on Windows or OS X.
A more advanced threat is exploits; chat programs like Pidgin use libpurple, which is so insecure "Security people who have examined the code have said there are so many possible ways to exploit libpurple there is probably no point in patching it... they are bugs that let someone take over your whole computer, see everything you type or read and probably watch you pick your nose on your webcam." Common PDF viewers aren't any better either. Vulnerabilities in browsers like Chrome, Firefox, and Safari have repeatedly been found and exploited in contests like Pwn2Own.
The third main threat is that of credential theft, re-use, cracking, and guessing; if you use passwords to remotely access your system, and you re-use that password anywhere else, there's a good chance it will eventually be stolen and someone will keep trying it until they hit your system. Even if you don't, but you base your passwords on dictionary words, maybe swapping in a few letters or symbols, chances are very good it will be cracked if someone tries. (over 90% chance on average any given password will crack if offline attacks are possible)
To summarize, in most cases (client software exploit, typo, etc.) an attacker will not directly get or have your password, but they will be running code with your day-to-day-use account's privileges; in the other cases (password attacks), the attackers will have both code execution and your password. In the default Linux settings, if you allow sudo escalation with your normal account's password, anyone who has that password will immediately have root access. If they do not, they will be able to obtain your password and root access the first time you use sudo to do any administrative task by configuring an alias or PATH variable or shell rc file in your account to run a program like sudomitm or launching a program like stdioterminallogger each time you open a terminal to record the password you type in whenever you run the legitimate sudo or su program.
Common wisdom would have you believe when you run sudo that you are only granting root privileges to one command at one point in time. In reality, you are granting root privileges to any hacker who has ever run any code in any process at any previous time in your account and decided they wanted escalated privileges.
Running most programs at "regular user" permissions and only escalating a few commands is just security pretend; it's just pretending a compromise of the "regular user" won't reliably compromise the entire system. Having users type in their password to that sudo (or su or kdesu...) prompt often makes it even worse because it:
- Gives a false sense of security; countless users believe it will stop attackers when it really won't.
- Exposes the privileged password to theft in the most common hacking scenarios, which is likely to get other systems compromised, such as in single sign-on systems.
- Trains admins to type their privileged access password into prompts/windows spawned within their own login, which can easily be spoofed.
Recommendation
For *nix desktops; things you run your chat programs, browsers, email, and development tools on, I recommend using a separate dedicated account for admin tasks, which is able to run commands via sudo without any password. For admin tasks, the user should completely log out of their untrusted account and then log in to their trusted account. I'll call this the "separate account solution."
Some servers, such as the one hosting scriptjunkie.us, exist to run a service and are only rarely logged into, and only to perform some administrative tasks. For example, here's the last few things I logged into the scriptjunkie.us server to do:
- Reconfigure SSH settings to make the SSH daemon faster and more secure
- Install and configure ntp to keep time in sync
- Look at the apache error log to see why some page wasn't working.
- Change the apache configuration and restart apache
- Add a cron entry to reset the server if it got into a deadlock-like state (long story...)
All of these tasks (and corresponding commands) have one thing in common; they all require escalated privileges, and for good reasons. It doesn't makes much sense on these special purpose systems to have limited personal accounts (of course, limited accounts like www-data are still a good idea for services). Instead have just one account per user with the ability to sudo to root without a password. Since servers are often only accessed remotely, use SSH keys and remove passwords entirely if possible since again, without special equipment an average hacker can crack > 90% of password hashes and 0% of SSH public keys.
Objections
So with that said, let's take a look at the situation from the blue side; OS/system admin perspective. In contrast with Microsoft, the Linux world is much more direct and opinionated about how to administer elevated rights. The OpenSuse and Red Hat documentation recommends the standard su/sudo-from-normal-account process, and the Ubuntu documentation is even more direct (and helpful), listing 9 benefits and 2 drawbacks of administering with "single account sudo." Let's examine them one by one.
1 & 2 state that remembering multiple passwords is simply complex and inconvenient. I agree and would counter that you shouldn't remember any password except for a full disk encryption password on your primary system; additional passwords can be unlocked from that or a password manager if necessary, but most of the time you should use SSH keys on your primary system or on an inexpensive smart card.
3. "Make you think about" major changes before doing them. This is a good goal, which the separate account solution meets by requiring a separate login for.
4. "sudo adds a log entry" This is not a viable security feature; one of the first things attackers will do once getting root access is deleting all incriminating entries from /var/log/auth.log but even if that wasn't the case, the separate account solution uses sudo as well, just not requiring a password, so this log entry will still be created in /var/log/auth.log.
5. The Ubuntu docs claim hackers will try to crack the root account and not know about your account. This is hopelessly naive and betrays a complete lack of understanding of hacking; as if hackers assume you use a configuration that is not the default on any major Linux distro, a laughable idea. If a hacker is targeting your server, they'll know who the user is. Even if that wasn't true, the separate account solution still has this property; the elevated accounts are distinct from root.
6. and 8. "Allows easy transfer for admin rights." The separate account solution easily meets this by creating or removing the admin accounts. This is only a problem if you share a root password, something I hope no security expert would recommend.
7. "sudo can be setup with a much more fine-grained security policy." The separate account solution can support this with sudo, but I would actually caution against this, because just like capabilities, almost any individual root-level grant is equivalent to full root control. Tailored sudo policies almost always grant a false sense of security.
9. "The authentication automatically expires" this just shows how bad the false sense of security is. The author of the article believes that the account is low-privileged or secure, when in reality any hacker will have elevated privileges in no time.
Giving a day-to-day account the ability to sudo to root and requiring a password to do so simply encourages this false sense of security. The situation is very similar on Windows.
Escalating on Windows
On Windows, by default admin accounts are configured under User Account Control restrictions, in which most programs run unprivileged, and to launch a program with full admin privileges, the user has to right-click and select "Run as administrator" then click to confirm in a system confirmation screen. At least Microsoft claims UAC is not a security barrier, although sadly this is buried in obscure technical documentation while the UI which is in everyone's faces seems to imply it is a security feature. Even if admins do use separate privileged and unprivileged accounts, they often will still launch privileged programs from their unprivileged login desktop, using the runas utility or supplying a different account username and password to the UAC prompt instead of e.g. logging out of a limited account and then logging in with a privileged account.
Just like in Linux, hackers generally obtain access via user tricks, exploits, or credentials. And just like in Linux, a hacker who obtains access via one of those methods can alter the graphical or text shells or environment to execute their own man-in-the-middle program to steal the password you type in as you type it in, or change the program or command line that will be executed when you do authenticate.
There is one main difference though; you might be wondering why malware can't simply simulate a logout when the user tries to log out and then capture the elevated credentials when the user tries to log in again. Windows tends to have better protection against this, since it requires Ctrl+Alt+Delete as part of the login sequence and the Windows kernel won't allow an unprivileged program to intercept those keystrokes.
Conclusion
It is important to use a low-privileged account for most day-to-day activities, and only use a high-privileged account when you need to. But the method you use to do that can undermine the benefits of using that account in the first place. Technologies like sudo are useful to prevent accidentally breaking your computer with root privileges and for granting different users privileges without sharing creds, but are not sufficient to be actual security barriers.
This advice isn't limited to just accounts on the same system either; the same error is made every time an untrusted environment is given the ability to control a trusted environment. Control should always flow from a more privileged and more trusted environment to the less privileged, untrusted environment; going the other way, even when presenting credentials, only allows those credentials to be stolen and hackers to ride up to the higher privileges. This is not a new idea; it is why Microsoft's #1 recommendation to secure privileged accounts from credential theft is to make it so you cannot log into a privileged account from an ordinary, untrusted workstation. But this principle frequently seems to be forgotten.