Sudo vs. Root

lessthan0 writes "In Mac OS X, the root account is disabled by default. The first user account created is added to the admin group and that user can use the sudo command to execute other commands as root. The conventional wisdom is that sudo is the most secure way to run root commands, but a closer look reveals a picture that is not so clear." The article is about OSX but the debate is a little older ;)

Layered Security

[Mattygfunk1]

The conventional wisdom is that sudo is the most secure way to run root commands, but a closer look reveals a picture that is not so clear.

The article doesn't say that sudo isn't the most secure way to run commands, it just details how to make it even more secure.

Same applies to Ubuntu

[Anonymous Coward]

sudo is primed to let you do pretty much anything. And it's far more likely that someone gets my user password that the actual root password.

This just in:

[djh101010]

News flash: Sudo, like many other tools, has a configuration file, which allows you to customize it's behavior. Details will be provided as they become available.

C'mon, anyone with even a passing involvement with sudo has looked at the sudoers file. You can configure pretty much any group or role based permission you want; if you can describe it as a logical statement, you can do it in sudo. Yes, out of the box, you can sudo to a shell (or to an app which has a shell escape).

How To Become Root on OS X

[Synesthesiatic]

Last login: Tue Mar 21 10:44:32 on ttyp1
Welcome to Darwin!
Hunter:~ Adam$ sudo su
Password:
Hunter:/Users/Adam root#

This is on an unmodified install....woops I guess that root account wasn't disabled after all!

Re:How To Become Root on OS X

[grahamlee]

Or sudo -s, for that matter. The root account is disabled insofar as it can't log in - although even that's not quite true...

Re:Messed up sudoers

[petermgreen]

oh yeah not having physical access (or a serial console) means you have to be VERY carefull when touching certain parts of the config. This particular example can be avoided by having another way to get root but there are many others such as iptables, sshd etc

btw you don't need a livecd if you can get to the bootloader prompts, just use init=/bin/bash on the kernel command line and the box will drop straight into a shell. Type exec /sbin/init when you are done to resume normal boot.

Didn't we already have the wheel group for this

[SpaghettiPattern]

Didn't we already have the wheel group for this? No direct root login and only members of wheel can su to root. http://en.wikibooks.org/wiki/Guide_to_Unix/Explana tions/Becoming_Root [wikibooks.org]

Re:Sudo

[OxygenPenguin]

I'm with you there. I often su to root inside a shell and remain there for some time, until I'm finishing executing commands that require root. I don't feel the need to secure my 2 Ubuntu boxes at home enough to only sudo in and out. It's irritating having to type that command over and over again.

Now, the servers at the workplace are a different story, though I tend to ssh in as root at times as well.

Re:Sudo is only useful when there are lots of admi

[Joshua Cowan]

most admins get so irritated at having to type sudo before every command that they'll just sudo into a shell and be done with it

The BOFH patch for Bash works well for this scenario.

For a single-user system, sudo is pointless.

It is an effective way to eliminate root logins and encourage least privilege practices.

Re:How To Become Root on OS X

[beelsebob]

The root account is disabled by having the shadow password set to * - thus you can't enter a valid password for root. If you already are root (as in this case) you don't need to enter a password, and thus it allows you to do the command.

Re:Sudo is only useful when there are lots of admi

[Flwyd]

I'm the only user on my Linux laptop. My password is dead simple; I'm not worried about security -- the most likely people who might try to do something to my computer are other developers in my company, and they probably have a good reason.

However, I never run sudo su Why? Being forced to type "sudo" in front of potentially dangerous commands forces me to think a second time and make sure I'm not doing something stupid. If I type rm -r * and get prompted that I don't have access, you bet I'm going to double check to see if I'm in the right directory.

Re:Sudo is only useful when there are lots of admi

[goodchef]

Read the sudo manpage. After you authenticate for the first sudo command, subsequent invocations won't require a password for a set interval of time (default is 5 minutes, unless overridden in /etc/sudoers).

Re:Sudo is a tool not the entire solution

[Hieronymus Howard]

4. Allowing non-human users (e.g. www) to execute a strictly limited set of commands as root.

For example, I have this command in my sudoers file:

www ALL = NOPASSWD: /sbin/ipfw add 2000 deny ip from [0-9.]* to any in

This allows apache to use /sbin/ipfw to add the ip addresses of script kiddies to the firewall. Note that only adding addresses to one particular rule (in this case rule 2000) is allowed - any other usage of ipfw will fail.

Re:Layered Security

[Anonymous Coward]

The article is fucking stupid for another reason; it says sudo is 'insecure' because, if you're logged in as admin, you don't the username, just the password. How exactly does root make this any more secure? You already know the username for root is 'root', so whats the fucking difference? Either way its all just a password away...

Alternate methods

[Spazmania]

I ran in to these kinds of issues back in the Solaris 2.2 days and came up with a different solution.

Solaris' problems were even more acute. Sudo was a download; it didn't come with the system. If you changed root's shell from the minimal Bourne shell the boot scripts would malfunction. More, root's home directory was "/". So setting up a personalized environment where you could use root access effectively was a pain.

The solution I came up with was a second root account. I just added another name with uid 0 using a seperate password, a seperate home directory and the ksh shell. Then I randomized the main root password, stored it away and promptly forgot it. I'd only need it for fsck on boot.

Later when I was in charge of multiple system administrators I gave each one their own root account. This let them set up their environment in a way that worked for them, it showed me who was using root commands when and it logged their commands to individual .bash_historys so I could see who screwed up.

It also means that like with sudo when a sysadmin leaves I don't have to change all the passwords. I just delete their account.

I still use sudo for folks who I don't expect to do much as root, but the sysadmins get their own root account.

Re:Didn't we already have the wheel group for this

[6*7]

Short answer: no

Long answer: man sudo and man sudoers

medium length answer: sudo gives a much more fine grained access control. If I had known about sudo I never would have needed to write wrapper programs with setuid permissions and all kind of groupbased access control to them myself.

Re:This just in:

[pla]

You can configure pretty much any group or role based permission you want;

With one slight problem... Yes, for a handful of well-known low-complexity programs, you can lock down sudo. For anything more, you may as well just give the user root... For example, if you let your sudo'ers use any shell or editor, or invoke any world-writeable script, game over. Most process-, file-, and account-management programs. Anything that allows explicity suspending to a shell (or invoking an arbitrary subprogram). I could go on.

As an off-the-cuff generalization, I'd go so far as to say that most programs you need to run as root, you can use to trivially gain "normal" root access to a system. And while you might argue that you generally trust your sudo'ers more than your random users, never forget the old maxim "never attribute to malice that which you can explain as laziness".

Re:No it's not a mystery

[99BottlesOfBeerInMyF]

All that is in bash history for the root user. And anyone who knows how to clean that can clean the log as well.

Actually, this is not always true. In some environments remote logs are kept and versioned. Root on a workstation would not have access to wipe the remote log, only add more entries to it. Still, anyone working in such an environment would almost certainly have made other changes to the workstation anyway, so arguing over the default setting is pointless.

Re:Oh, great!

[das_cookie]

Bottom line is that the only thing sudo *REALLY* buys you is the ability to log who did what when with root access. And as has been pointed out, there are innumerable ways to circumvent even that (sudo vi; :!sh). It's a way to keep honest folks honest and have a way to go ask someone what they were trying to do; I've also used it for myself to create session logs for audit purposes. Someone bent on nefarious uses can easily cover their tracks.

Re:Sudo

[Phormion]

Well, it's just as convenient to type: ./configure make su -c "make install" At least on Linux, I believe; IIRC, on Solaris you had to give a different argument to 'su', but still, you get the idea.

Re:Sudo is only useful when there are lots of admi

[tony.damato]

Social engineering can assist. I work in an administrative environment where not only is sudo the preferred way to do things, but we have a policy where using 'sudo su' or 'sudo sh' can cause one to be written up and possibly terminated. I know, it sounds strict, but it works for us and makes usage of sudo much easier to manage.

There is an example in the 'sudoers' manual which tells how to remove 'su' and shell commands from those which sudo allows. I had to implement this after we discovered that some individuals who needed sudo access to do some things were using 'sudo sh' to get around the restrictions we placed on them. After the initial threat, they were much more agreeable to how we wanted them to do things *grin*

Re:Sudo

[chill]

What the article mentions is not really a big problem, since that is more or less what would happen if someone guessed the root password (then they could tamper with anything, including the logs).

Not quite. The idea is to set it so root can't log in remotely, and that sudo requires the ROOT password and not the USER password.

This way a hacker would have to obtain BOTH the user password and the root password.

For even more fun, restrict SSH to not allow keyboard-interactive logins and require anyone who needs to SSH into a box remotely to use a certificate. That way a hacker would need the certificate, the passphrase to unlock it, and the root password. To top it off you can't just "guess" a certificate like you can a password.

  -Charles

Paranoia -- everyone has to have a hobby

Re:No it's not a mystery

[Anonymous Coward]

No. [freebsd.org] See, securelevel 1 or higher.

Re:I, Root

[Aranth Brainfire]

Same reason you're not supposed to log into Windows as an administrator all the time; if something goes wrong (security hole in a user-run program), or if you accidentally use the wrong command, your system isn't totally screwed (hopefully).

Windows actually has a similar feature, sort of- right-click on something and choose "run as...", then log in as an administrator.

Re:Sudo

[lp-habu]

What the article mentions is not really a big problem, since that is more or less what would happen if someone guessed the root password (then they could tamper with anything, including the logs).

Not completely true, at least on BSD-ish systems properly configured. If you set the sappnd or schg flags on a file only root can change the file and even root can only append to the file (in the case of the sappnd flag). Since those flags can only be reset in single-user level, that greatly complicates the problem of modifying logs after an intrusion is the sappnd flag is set on them. And yes, these flags do work on OS X although I don't know anyone who uses them routinely.

$ ls -lo system.log
-rw-r----- 1 root admin sappnd 1119 Mar 21 14:03 system.log

Even root cannot modify the existing contents of this file, only append to it, without rebooting into single-user mode.