Slashdot Mirror
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 ;)
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.
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.
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).
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!
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
/sbin/init when you are done to resume normal boot.
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
note: i'm known as plugwash most places but i screwd up registering that here somehow in the past and now can't register
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
I hadn't the slightest objection to his spending his time planning massacres for the bourgeoisie... (P.G. Wodehouse)
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.
Read the only personal Runyon page out there.
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.
Ceci n'est pas une signature.
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).
"Inflammable means flammable? What a strange country!" -Dr. Nick, The Simpsons
4. Allowing non-human users (e.g. www) to execute a strictly limited set of commands as root.
/sbin/ipfw add 2000 deny ip from [0-9.]* to any in
/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.
For example, I have this command in my sudoers file:
www ALL = NOPASSWD:
This allows apache to use
I ran in to these kinds of issues back in the Solaris 2.2 days and came up with a different solution.
.bash_historys so I could see who screwed up.
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
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.
Moderating "-1, Disagree" is simple censorship. Have the guts to post your opinion.
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.
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.
You! Yes, YOU! Out of the gene pool!
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.
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*
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
Learning HOW to think is more important than learning WHAT to think.
No. See, securelevel 1 or higher.
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.
"Quoting yourself is stupid." -Me