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.
I mean, it's like rock vs. scissors.
I guess that this article can be skipped if you are a windows user? :)
Support NYCountryLawyer RIAA vs People
Now all the black-hats out there will have a powerful new tool in their arsenal! You mean, a sudoer can, like, type "sudo /bin/bash" and then do all sorts of things as root? Pretty irresponsible of him to go telling the world a secret like THAT!
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). If the administrator isn't knowledgeable, both sudo or root can get hacked, but this doesn't mean that sudo is worse or has more disadvantages than running as root.
Personally, I prefer sudoing a shell to run as root so I don't have to type the command all the time, but that's just in my home Ubuntu installation which I don't care much about.
Send email from the afterlife! Write your e-will at Dead Man's Switch.
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.
When there are lots of admins, sudo can be helpful. However, even then it's mostly useless because 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, which sort of eliminates most of the advantages of sudo. To get around this, you'd need a security admin that is not only diligent about what access he gives out, but is also willing to deal with a lot of abuse from the other admins because he won't let them do what they want to do.
For a single-user system, sudo is pointless. Nearly everyone is just going to sudo into a shell to do anything where root is needed on their own personal box anyway.
As part of my day to day crap sudo can really help in running remote commands as root without having to login as root. We've got a few things setup which check system settings from a central node and being able to use a non root user, and then just using sudo /file really just helps keep things under control. Also with sudo you can fine tune which commands are allowed to be run. Overall a really nice toy
SolarVPS - Quality Windows and Linux Virtual Servers
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).
This is a poor article. It does not provide any solutions to locking down sudo. Oddly enough it is an article for OS X on a site called linuxboxadmin.com. Why not focus on one of the linux distros that use sudo such as Ubuntu?
Must be a slow day for news for nerds. More like news for noobs
This article is good advice for anyone running a unix-like operating system (OSX, Linux, etc). It's not knocking on OSX, just knocking on the default configuration. Sudo is really just a way to allow root access without allowing root logins. The best way to configure it: Root Account with a unique password (not the same as your user account) Sudo requires password to activate (caching is ok, but no automatic access, no keys) Sudo logs all commands Sudo only enabled for specific user accounts Root account has login disabled, ftp/ssh disabled. (using the /usr/bin/false trick mentioned in the article, I use true myself)
The winner is clear!
rooooar
For usability purposes, sudo is nice because the user only has to enter their own password. However, this can also be detrimental... Users have been socially engineered to just enter their password whenever the box asks for it, and to the "average" user this may mask the fact that they are upping the privileges of the process asking for it... If they had to actually type in (and remember) the actual root password it may be a little more clear.
All in all, I think it's really a matter of personal preference.
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!
But when you share a root account, revoking privilege from a single admin means that every remaining admin has to learn a new password.
Ultimately all sudo means is that a cracker has to know
2 passwords to gain access to root on your system if root
itself is disabled - a user password and the root password.
If they cracker has already somehow cracked the root password
then I doubt they'll have much trouble with a user password
which are usually far less secure.
sudo passwd root
adventure-today.com
Now, a live CD and a setuid bash executable managed to fix the issue directly, but we learned an important lesson about root-less systems. If you screw up something like the /etc/sudoers, the system is hosed unless you
have physical access.
So as much as I use sudo for almost all my UID 0 needs, I think root still needs to live in every box just to safegaurd against such simple mistakes which ended up costing more hours than the sudo would've saved.Quidquid latine dictum sit, altum videtur
...is to choose a really difficult password and forget it. This will secure the box from its' worst enemy - yourself.
When your normal user has his mind set on performing a specific task (Such as installing the newest spyware-ridden p2p-downloader) you can popup a big red button and naming it "explode", the user will press it if he thinks it will get him closer to performing the task. Putting up a dialog and ask for the root password is for normal users only an obstacle to get by. They don't know what it mean, but they know how to get by it (By inserting the password).
Don't know any way of solving this except for training though. Or possibly making it IMPOSSIBLE to do certain tasks. But that no good solution.
All that is in bash history for the root user. And anyone who knows how to clean that can clean the log as well.
The principal idea of Sudo is flawed! It works with ~ 10 user accounts, but if you have, say 30 - 100 accounts then you are likely to have misconfigurations, because it becomes a tedious job to maintain the access configuration file. I've seen this happen many times - unauthorized users accessing files they should have no right to access.
Bullshit! A real administrator is always logged in as root - it's CRAP administrators that aren't!
I run as root at all times. Argue with me at your own peril!
Everyone will agree that the less you use your root account, the less vulnerable your system is. People are lazy. If they can su and do everything as root, they tend to do so. However if you "block" the root account and force the user to use sudo and type in their pass each time, they tend do use less root, thus increasing the security.
sudo -> Ubuntu -> ??
nohup cd /; rm -rf * > /dev/null 2>&1 &
Ctrl+D
LOL!!!
sudo is the most secure way of allowing certain users root privileges to all or some system commands WHEN CONFIGURED PROPERLY. "man sudoers" shows you can do a lot with sudo and restrict users/groups as much as you want. Since coming across sudo, I have disabled root accounts on all boxes I have used. It rocks.
>/dev/null 2>&1
Just expect script with ssh to root shell and script away.
Nobody expects hardtyped root passwd in user scripts.
Ubuntu also does this as well.
I would disagree, in some cases. I like that Ubuntu does things this way, because it's designed for less-experienced users. I often see posts in the forums that list several commands in a row to execute, all preceded by sudo.
Being a more experienced admin, that looks wierd and counterproductive. But here's the nice thing: it keeps users from opening up a root shell and then forgetting they're in that shell, where they could easily wreak havoc. I think that's a good thing.
Me, I pretty much just always type "sudo -i" to do my stuff. But I wouldn't want less experienced users doing that.
I'm just a part time sysadmin, so I don't know the nitty gritty, but it was beat into my head to use sudo instead of root simply so that I wouldn't "forget" I was in root and do something stupid...
There is no reason (usually) to be logged in as root, and that anything I need to do as root I could do using sudo. It seems to me that you hack with sudo just as easily as with root...
On my own boxes I commonly use sudo for installing software,
I do all of the compilation etc. in a user account.
If I log in as root then I have the hassles of all of the
files I create being owned by root unnecesarily,
and then I have to change them all back.
sudo also allows me to get a similar effect to suid, but on
a more restricted basis, via sudoers.
So I dispute your assertion about sudo ONLY being useful
when there are a lot of admins.
I guess most of the things in that article applies to Ubuntu (root disabled, sudo-only access to root privileges) as well. I wonder how Ubuntu devs and users feel about this.
I find sudoku to be the most useful... wow, I've really got to stop playing that game.
The first one is all about convinience. It makes it easy to be logged in as regular user and issue root commands as needed. This lessens the incentive to be logged in as root al the time and thereby can reduce the risk of accidentially issue unfortunate commands as root.
The second is a help to figure out what went wrong in case you need to un-fsck the system after an accident.
The part about handing out semi root to PFY's is really the least interesting part about sudo. Either you trust people or you don't.
I agree that sudo becomes a hassle when you need to perform surgery but for daily tasks it's really great. If you need to be root all the time then there is something really wrong with your setup.
TCAP-Abort
My box has ssh enabled, but it is only my box and I have not granted anyone access to it. My admin account has access via ssh but ssh is configured not to allow root logins. Also, the root account is disabled for the large majority of the time.
Even though I feel that this should be sufficent it troubles me that the sudo feature is enabled as the article implies by default. I think it makes much more sense that you need the root password for su and sudo access. I think that possibly adds another layer of security to the system.
||| I still can't believe Parkay's not butter.
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)
If you make the effort to go beyond Apple's default security you'll reduce your potential exposure to any malware that might ever be written for the platform.
I'm trying to teach myself to set people on fire with my mind... Is it hot in here?
Not in Vista, it won't.
Back when Vista was still Longhorn, they were planning to include a new Microsoft Shell, aka MSH, aka Monad. But they are saying now that it won't be released with Vista.
-ccm
Too much Law; not enough Order.
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
That's right.
What many linux affectionados do not realize is there are many much more advanced power user control systems then sudo. My favorite example is RBAC which has, unlike sudo, some corporate/security professional appeal. See there. It is mostly used on Solaris where the integration level is impressive. For example we can make a requirement that some operations can be only performed by two admins (a "two men rule" ).
Sure, sudo can also can be taken to a much higher level when properly configured, but still ;-)
By default OS X machines use the same password for sudo commands as they do for the regular user account. If you are more concerned about security than the average bear (or OS X user) you can change the password or you can disable sudo altogether and enable the root account with a different password. All of this is good info for those interested in security, but who are still learning.
From this article I predict a number of people knocking this default setup and then a rehash of the old argument as to what the default should be. I contend, that it is probably the correct default. OS X is a workstation not a server. It is designed for normal users. Having two password (heck having even one) is a usability issue for many users. People are confused by the whole concept of passwords and many have trouble remembering even one. Further, setting a second password only slightly increases the difficulty for a competent cracker. The truth is, there will be local escalations for the foreseeable future. OS X is not a super-locked-down server.
Basically, for the average user, a second password gains them very little except confusion. For more advanced users, well they can change the defaults, as many do. Maybe the only issue here is the in-between people. Those are the people targeted by this article. Those that might want to change the defaults if they knew about the issue and how to do it. Maybe this configuration should be made a little easier, or even incorporated as an option in the install process.
This default bears revisiting should Apple ever move to a more locked-down system. Maybe when users are accustomed application specific privileges they should also be introduced to a more layered security scheme. For now, though, I think the usability issue outweighs the security one.
I don't like SUDO. If someone has figured out my account password, and gotten through all other layers of protection.. I want them to have to figure out the root password.. not just sudo and enter my password again.
Same reason I don't allow root login through SSH and why I firewall the SSH ports on my machines.
Keep an xterm open with a root shell.
It'd be nice if this had a distinctive window border. It's possible with fvwm I think.
Better yet, duplicate the GNOME (or KDE) menu as a white-on-red version labled "root", with all the games and crap greyed out. That's pretty much sudo for a GUI. (per-command stuff in the regular menu is lame, because some commands are useful both as root and as non-root)
I never used "sudo -s" but always "sudo bash" on systems that allowed it. Because prefixing all commands with sudo was annoying...
Just use your handy editor, emacs, vi, Microsoft Word - whatever - to remove that pesky user "root" and its "UID 0" from /etc/passwd then update the netinfo database. Reboot Mac. Problem solved!
-- lady*seven --
Then, you can force sudo to require the root password
... well, if he knows the root-password, he will gives that out too, so it's an attacker that can acquire 1 password from Bob will be able to get a second one too.
Hu? I though one of the strength of sudo (over su) was that you DONT have to give out the root password to every user that needs some administration powers.
Of course, if the root account is completly disabled and the root password is ONLY used to authentificate against sudo, it's slightly less of an issue, but even then I dont think it's better than requiring the user password.
Example :
admin Alice has all powers (can sudo a shell)
admin Bob can only edit httpd.conf and restart apache
Alice forgets to close his session (but did close all root-shells) and Bob walks by his machine. He types in sudo in a terminal. If sudo asks for Alice's password, Bob has to guess it. If however, sudo asks for the root password, Bob knows it and can gain a root shell.
OTOH, it forces an external attacker to guess/acquire 2 different passwords, but this can be solved differently. If Bob tends to choose weak passwords, this can be solved by rejecting weak passwords (for admin users) right away. And if admin B gives out his password to whoever asks
Bottom line : Requiring a root password for sudo seams like a stupid idea.
I have discovered a truly remarkable proof for my post which this sig is too small to contain.
Yes, I know that. But admins are inherently lazy, and even typing "sudo" before every command is a burden that most don't like to deal with.
This "problem" has been around a while and is not really a Mac OS X thing problem. In short poorly configured systems are less secure, imagine that. I can make my self type 3 or 4 different passwords to get to sudo or root, will this make me more secure, perhaps. However I guarantee that if Apple did this the first thing every user would do is enable root, or otherwise make it more sane and easy to administer the system. If by some greater decree they made it impossible to do this, fewer people will want such system, as it will make them harder to use. Whatever you do, if you have boot, you have "root" ( or at lease root like access). In short it is possible to layer on many levels of security over the "root" access of a system but it this actually wise?
I don't use much OS X but I do use Linux quite abit. When I set up my machines, of course I use root access, lazy heck no. I have hordes of little tweaks and such to perform, packages to install, things to edit and permissions to set. If I had to use sudo, my first command would be to open a root bash shell. As for security, a new system it not accessible to the outside, thats it. After a system is up and running, I tighten things up.
First thing, as mentioned, is to disable root access by ssh. Of course, use public keys instead of passwords where possible. However why not go a simple step further, and the article missed that. Most of my accounts, and certainly all those accessible with ssh don't even need the privileges to use sudo or su to root at all. In fact in most cases my externally accessible shell accounts have a very limited set of commands they can run, simply because shell access is so insecure to begin with (hello gcc under remote shell users). I feel that this is clean and efficient and not a real pain to setup.
If you are paranoid and want a 2nd password for "root" access, use such a limited user for all users, then make a second account that may use sudo or root and log the heck out of it. Make each prospective admin su to that first. in the end, its only how much security is reasonable that wins. if you need more unplug the box and lock the thing up in a closet to prevent physical access by lock key, this too can be broken...
When a pack of wolves hunt a herd of sheep, as a sheep you need not out run the wolves to be safe, only the slower sheep. These slower sheep (aka windows) are generally quite abit slower these days than you (OS X). However, this all depends on the number of wolves you keep (or allow) on your netoworks... If you can't generally trust your users you have other problems.
I really don't see how sudo makes things any more secure. It's really just a shared root account.
People tell me that it protects from viruses if you log in as a normal user and only sudo when you need to install software, but surely a virus is capable of modifying your PATH to run a custom binary when you type 'sudo', capturing your password, and gaining privileges that way?
People tell me that you can only give root access for particular commands, but anybody with an ounce of intelligence can use that to gain privileges. sudo make install? Nope, you can just write a Makefile to create a root shell. sudo apt-get? Just create a package that has a root shell in it. And so on.
All the advantages for security that sudo is touted to have seem like they are completely illusory to me. Where's the real advantage to using sudo?
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.
As far as I can figure, his argument all comes down to someone possibly stealing or guessing your password. Doesn't this problem exist with root as well? I love that his solution is to disable sudo and enable remote login on root. He then says that you should only allow public key authentication. So now we are back to the original problem. If someone obtains the password to an authorized account, they now have non-password root access to any server they want. From there, it's not too hard to setup another public key on the root servers that links to an unprivileged account. Now the user cannot just change their password every week for security, they need to go update all of these keychains. No, I'm afraid this author is horribly wrong. If you want to get rid of the problem of using your own password for doing root work, shut down sudo and use su. Do not under any circumstance enable remote login on root.
In related news, I am so tired of all of these non-news blog entries that keep being put on Slashdot. Give me real news from a reliable source, not some no-name idiot that has no clue what he is talking about. Seriously, we need some sort of blog tag that allows us to immediately identify blog articles and appropriately ignore them.
pcollins$ su su sudio
-- 3 events that reshaped the world in the 20th century: WW1, WW2, and WWW
"For a single-user system, sudo is pointless."
You have that backwards. On a single user box, it makes the most sense to use sudo. On the other hand, having multiple user accounts on a box and administrated by another person then a root account makes sense.
As others have said. You can type
$ sudo -i
which is really no more a effort than typing
$ su
I'm surprised this article made the front page of /. as it arguably confuses the issue more IMHO.
Hulk SMASH Celiac Disease
None of the admins here has any problem using sudo. And if someone was caught circumventing security policy, they'd be fired. Period.
Try the following:However, that's not going to stop joe user from copying bash over to
$ man woman *
-bash:
Typical use here is: sudo su -
Now what might be interesting is to see how Solaris's RBAC comes along. I'm still sort of new to it myself, but the little that I've done with it has allowed me to create a role that can manage a few services related to a single project (they are limited to start/stop on a temporary basis and refresh as needed). In my case, I setup that role as having manage and modify rights in SMF. The users don't need to have root or sudo, just a role login which doesn't have a lot of permissions.
In my development environment, sudo is often prefered (pre-RBAC and current as most of the SA's supporting us aren't exceptionally UNIX savy) over giving out the root password as the root password may be common to multiple systems and a user may only need to be in the sudoers file for a particular system.
And this is why I like RBAC much better. Next to all your issues with security when it comes to the config file you also face the simple fact that you're dealing with a setuid program here which can form a potential problem on its own. And the chicken/egg principle (allowing someone to edit a certain config file might also give them access to editing /etc/passwd / /etc/shadow).
An alternative to this is the way Solaris does it... Namely by using RBAC which allows me to grant access to a specific part of the system without having to worry about other parts. Another decent overview here tells you some more, while Sun itself also has some good stories, to be found here while a good overview can be found here.
What Solaris might lack in userfriendly-ness (when looking at distributions like Ubuntu, SuSE and OS X) it sure makes up for robustness and simple quality. In my opinion the days of sudo are (or should) be numbered.
you can create multiple logins that resolve to UID 0; there doesn't have to be just one 'root' account, passwords don't have to be shared.
The revolution will not be televised... but it will have a page on Wikipedia
The most insecure thing about sudo that I see occurring frequently is that a person with an account that has sudo access uses the SAME account for unencrypted email.
So basically their password gets sent openly when they login via POP to check their email. Anyone with a sniffer can get their password, login, and have full sudo access.
Now that's great security for ya.
That's why when I install a distro like Ubuntu that defaults to using sudo I always make the first account a dedicated admin account. Which sort of raises the question of why not just use "root" in the first place...
Why shouldn't a single user of a host login as root, or just have root privileges for their named account? Switching contexts with su/sudo makes it more likely to make mistakes.
--
make install -not war
because 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
So configure sudo to prevent them from doing so.
It's official. Most of you are morons.
I reccomend you run a find command the deletes all files owned by root. That should do the trick! Without files, how could they be enabled?
"There is more worth loving than we have strength to love." - Brian Jay Stanley
Simple Solution: Don't turn on Remote Login (SSH) on your OS X Mac. In fact keep all Sharing under Sharing in System Preferences tuned off. Now if I can just convince my cow-irkers that they don't need these things everything would be fine. "Oh, I have to access my computer from home." "Well then just turn on File Sharing." "But, its over the web, don't I need Web Sharing and Remote Login turned on?" Undsoweiter.
Last time I checked, on MacOS X anyway, it was trivial to do sudo /bin/sh and voila I have a root shell. Get over it.
7 November 2006: The day Americans realized corruption and incompetence weren't addressing 11 September 2001
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*
If you restrict allowable commands under sudo, it becomes pretty useful. When you add a shell logger that requires you to identify yourself and the reason for opening a shell, you have an audit trail.
:o)
In short, sudo can be very good, but it requires some work and the ability to withstand much cursing from the recently crippled.
I am my own gestalt.
Very true, never opening root shells also helps minimize opportunities for you to break something horribly by typing a command in the wrong window. It's a good policy and the 'ease of use' loss is, to be honest, pretty minimal, especially compared to the security gain.
Where we do need to use actual root windows, I try to make sure they are visually distinct with color scemes that scream "DANGER, THINK!"
Same here....and I cant even begin to count how many times its saved my ass.
And Apple makes it's own hardware. Hmm. sounds like an opportunity to me.
So what if Apple built a hardware access token into their keyboards? When you get a new keyboard, you plug it in, hit a special "administrator" button, and type your password on the computer, which effectively pairs the computer to the keyboard. The event is logged to eneraseable flash ram on the mobo.
After that, you can configure your computer to allow sudo (a) any time the keyboard is connected, you are logged in, and have typed something in the minute or so , or (b) any time the user taps the "administrator" button or (c) every time the user taps the "administrator" button and provides the admin password, which is plain old two factor security.
You could tap the adminsitrator button ten times and it would allow the next ten sudo'd commands; a second "admin off" button has a blinking light meaning the keyboard is about to autorize something; tapping the "off" key sets the number of commands to authorize to zero. An LED on the "admin off" button blinks. Holding "admin off" button down for two seconds means that the keyboard won't allow any sudo commands until the password is entered.
A system like this requires that you have complete control over the hardware and the software. Only Apple does.
Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.
A few weeks back, Slashdot ran a story from Wall Stree Journal about an "original content" scam that takes advantage of Google. Basically, writers are paid to pump out senseless "original content" articles (sometimes rehashing other sources, sometime outright nonsense). This is because apparantly, Google will drive down your page rank if you don't have "original content". So you see all these "blogs" and "news sites" that have crappy, useless, or wrong content,.... but plastered all over the pages are Google AdSense adverts.
Now, apparantly they just submit the pages directly to slashdot, and they get swallowed hook, line, and sinker. Perhaps the slashdot editors should look for a pattern. Do certain submitters only submit stories that are plastered with AdSense? Multiple submitters at the same IP? Not that an advertising supported site is wrong per se, but come on....
After these comments run their course, all you geeks will have your licenses taken away for overuse of the word "sudo". Bad geeks, bad!
Thanks for that truly groundbreaking observation. I never would've guessed that might be a problem.
Admins at your place are too lazy to type "sudo" ? I bet they are too lazy to document their work too, and to test their changes.
:wq
So configure sudo to prevent them from doing so.
Can't do that - they're admins. A better approach would be to educate them about logbash.
"We returned the General to El Salvador, or maybe Guatemala, it's difficult to tell from 10,000 feet"
Virtually all the tom foolery suggested inthe article is unneeded since on macs there is a better solution. Have two logins. One has admin privs and one does not. use the latter for your bussness.
While this can be terrifically painful on Linux and Windows its not painful at all on a mac. What happend is that nearly anytime you do an opertaion that requires root privledges from the gui the mac does it but first pops up an authentication box that wasks not for your everyday account password but instead your admin user password. So it's nearly seamless.
For the few cases where this wont suffice, you can either fadt user switch to admin, or you can pull up a terminal and su to the admin.
this has all the same protections the sill approach advocated in that article suggests.
Some drink at the fountain of knowledge. Others just gargle.
I use MacOS X. I'm not a big fan of using rm with wildcards. To make sure I know what I'm throwing away, I just type "open ." select the files, Command-Delete to throw them in the trash. Then, I can check what is in the trash and hit Command-Shift Delete to empty the trash. It seems to me that it is safer than using "rm *" or even rm "foo*.h". Then, I just hit Command-Tab to get back to terminal. It is actually quite fast.
Avoid Missing Ball for High Score
Some other advantages to sudo:
1. The user uses his/her own password to auth - no need to remember 2 passwords.
2. You dont have to expose the actual root password among multiple administrators, and can thus use a complex mutual root password for a collection of servers.
3. If you want to take away admin access for a single user, you can just lock his/her account. You dont have to go across 20 servers and change the root password! If you are using centralized password database this is even easier.
4. You can revoke admin access without revoking user access.
5. root shells work with the user's environment settings. When you execute a 'sudo bash' for example, you maintain your environment variables. Your 'home dir' is still *your* own dir - not root's. Things liks 'cvs' still continue to work.
-- NeTMoNGeR
Laws do not persuade just because they threaten. --Seneca
and may god have mercy on the author's soul...
No one cares what your captcha was
Houston TX, USA
I'd think that this argument depends on the computer's usage. Sudo is much better for the average desktop computer or a small network, since it means that you can leave the computer logged in without any worries about someone messing it up, whereas being logged in as root could be hazardous. Of course, anyone who walks away from a computer logged in as root without locking it or anything doesn't deserve those privaledges.
If we can hit that bull's-eye, the rest of the dominoes will fall like a house of cards... Checkmate.
I recall arguing with someone in one of the Ubuntu IRC channels (back in my more vitriolic days) and they claimed that (arguably) the biggest draw for a desktop user using sudo is that things are separated very specifically. You access an administrative tool, for example, but that's the ONLY thing that you're doing with root access. As soon as you close that, you no longer have it at all. The same goes for anything else.
I think that a root terminal is more important for anyone who's doing a lot of administrative commands at once, but this isn't a typical scenario for a desktop user. Mac OS and Ubuntu (the only Linux distro I know of that touts the "sudo for everything" attitude) are geared for non-technical desktop users.
I used to hate sudo. However, I installed Ubuntu again in January and this time around I can appreciate using sudo a lot more. When I need to do "root stuff" at a terminal, I simply open the "Root Terminal" menu option under System Tools or su to root if I already have a terminal open. Otherwise, I just run commands with sudo or access things via the GUI (which runs gksudo). Very nice setup, if you ask me.
The article's author seems to be geared towards a server environment, in which case I ask why he's using a default sudo setup in the first place. Hell, maybe sudo isn't even a good idea at all on a server....
I dunno, I just su when I need to be root anywhere at all vulnerable. Log in as user and su if you need to ;).
... Standards and Practices !
PenGun
Do What Now ???
For a single-user system, sudo is pointless. Nearly everyone is just going to sudo into a shell to do anything where root is needed on their own personal box anyway.
Wrong!
I vary rarely run a shell from sudo. Even on my own boxes, I use sudo for perhaps 95% of my root activity. Why? Because then I have a complete log of everything I've done as root.
I always liked the system of requiring one user that has the password for the account that is allowed to sudo and another user having the password to sudo. So it takes two users to login and really do anything. Of course this is probably a bit paranoid. Would work even better with biometrics.
At what price learning? At what cost wisdom? The price is a man's peace of mind, and the cost is his life.
I use sudo pretty much exclusively for root access. At the worst, I'll do sudo zsh and get a shell.
Why would I do this, even if I'm the only admin?
a) I don't have to know the root password.
b) I have history of my recent commands that I ran as root in my shell
c) my shell, path, environment and aliases are comfortable to me. Since I never screw with root accounts, who knows how screwed up the vendor left the account, or someone that worked prior to me
d) its safer. I guess the exception is with !! or !s or whatever commands, but even the !s one will probably be hit with the password timeout.
e) if I have to routinely go to root to do "normal" things, then the system is set up wrong, and I need to quickly fix that
e is the big one here. I'm a sysadmin for my day job, and I rarely have to have root access. If I need to go to root all the time, then something is not set up right on the system. Usually a chown, chgrp, with a chmod will do wonders.
a closer look reveals a picture that is not so clear.
;)
Zoom out then.
"Beware of he who would deny you access to information, for in his heart he dreams himself your master."
Dude. Open . is totally sweet! Thank you I had no idea open worked with directories.
Why not fork?
For example:
Then as soon as I've confirmed that those are indeed the files on which I wish to act, ^P (or esc-k, or whatever) to retrieve the command, edit the 'ls' to 'rm' and go. Obviously, you can edit other parts of the command as well, but the important thing is never to edit the wildcard elements or attempt to re-type the command instead of editing. Re-typing can have errors; using the already used wildcard ensures that you'll get the results you want.I have never used OS X. But i am guessing hte system is enough like linux since all the utils are hte same.
/tmp/newconf > /etc/sudo.conf"
a) sudo su
b) sudo "cat
sudo bash
c) sudo passwd
su
Of course it logs the stuff on the local machine. So once your root you just merly need to remove / modify the log files. grep -v sudo should do it nice and cleanly
Visudo should explicitly ask you "you are about to deny *yourself* root access. Are you sure?"
Xenu loves you!
Can't do that - they're admins.
/etc/sudoers world-writable or something, you can still implement a policy that makes it a sacking offence to edit it. And then you set it up so sudo cannot be run interactively or launch a shell. And then you sack anyone who tries to get round the policy. Simple.
Huh? Your system is set up so that all admins are root, or something?
Even if for some reason you have a dumb setup that makes
I bet you like to use $ with MS like M$. What's wrong with using Microsoft Word to edit /etc/passwd; /etc/shadow; /etc/pam.d/sshd; /etc/resolv.conf; etc etc etc? You're just biased against M$, that's why. Me, I prefer TECO. Where are the trolls out running DEC down? Huh?
Huh? Your system is set up so that all admins are root, or something?
Admins are necessarily authorized to do a sufficient number of things that they are guaranteed access to a root shell if they want it. What it comes down to is this: do you trust your admins?
you can still implement a policy that makes it a sacking offence to edit it.
How is this better than logbash? They'll still get shells if they need them.
"We returned the General to El Salvador, or maybe Guatemala, it's difficult to tell from 10,000 feet"
Open an xterm (or the Mac OSX equiv)
:(){:|:};:
sudo su -
and then for fun try:
it is only after a long journey that you know the strength of the horse.
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.
In doing so, I think the author fails to see the wood for the trees, in that if you want your account to be secure, you don't have to go through (admittedly pretty trivial) hoops to enable the root account and remove the "%admin ALL=(ALL) ALL" line from the sudoers file:
You could just use a non admin level account (i.e. don't tick the 'enable this user' checkbox when creating the account - it is off by default on all secondary accounts created in Mac OS X, the end result being that the account is not in the 'admin' group).
Going so far as to disable sudo for all admin accounts, but leaving it in the admin group strikes me as a bit 'fur coat and no knickers', and could leave users with a false sense of security (as there malicious things you can do to the system with access to any account in the admin group, none of which require any form of additional authentication to perform or have anything to do with sudo).
...it means "I sweat" in my mother language, Spanish. Eww!
You argued that sudo is a vulnerable point when a browser or IM is compromised. Other people have addressed those potential weaknesses of sudo. I assert that a browser or IM process should never be able to run sudo in the first place, or for that matter, do anything other than maintain the bookmarks and preferences, read/write from a specific uploads/downloads directory, and launch a couple of viewer applications like acrobat reader and a media player.
In other words, I find it ironic that people will go to great lengths to prevent root access when their most valuable data is freely accessible by a normal user. Although having root access is a definite bonus for an attacker, there is plenty of mischief that can be done with a regular account, especially for a targeted attack. For example, do you really care if someone can't get root on your machine if your banking, investments, schedule, address book, correspondence, private encryption keys, and photographs are all in your home directory?
Whether you know it or not, you made a great case for mandatory access control as another layer of security in addition to properly configuring sudo and keeping your applications patched. A web browser should never have the same privileges as a shell, even if they are being used by the same person.
This space intentionally left blank.
That does not work. The redirection is not run as root. What happens is that "cat home/evlusr/mypasswdfile" is run as root but the redirection is done as the original user. Since the original user does not have permission to overwrite the account, you get an error, not a security exploit.
Seriously. Nobody really cracks passwords anymore.
Umm, this is dead wrong. Password attacks are getting more and more effective and popular among serious attackers all the time. Why? Very simple: because as computers get faster, passwords get weaker. If the attacker can get a copy of the encypted password file, he's home free, because peoples' ability to remember passwords has not kept pace with the ability of computers to search them. Barring that, any authentication service that doesn't do lockouts and delays (e.g. many web interfaces) provides an attacker with a great tool for password cracking.
Note that this isn't an argument for or against sudo, because sudo also uses a password. It's just a different password. Sudo is valuable, but for other reasons.
But don't fool yourself that password cracking isn't useful "anymore". It's very useful to attackers, and getting more useful all the time.
Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
That sounds like a good method as well.
Avoid Missing Ball for High Score
One of the most useful things I have created for using MacOS X is an AppleScript that opens a new terminal window located at the path of whatever Finder window is at the front. Then, I just add the script to the "Scripts" folder (after activating the AppleScripts menu item. Then, I have an easy way to get from the finder to the terminal (picking my AppleScript off the menu bar) and from the terminal to the finder (using "open").
/Applications/AppleScript/, then open "AppleScript Utility" and check "Show Script Menu in menu bar" and uncheck "Show Library Scripts" then choose "Open Scripts Folder" and drag the applescript above into that location and it will be in the Scripts menu.
." is useful, you'll probably like this idea.
The source for my AppleScript is:
tell application "Finder"
set x to target of front window as text
set y to POSIX path of x
end tell
tell application "Terminal"
do script "cd \"" & y & "\""
activate
end tell
To activate the AppleScript menu, you go to
I figure if you are the kind of person to think using "open
Avoid Missing Ball for High Score
We use sudo extensively for a large environment with many admins and many developers who think they need root equivalency on every server they log into.
There is a good tool that is a middle ground between forcing users to type sudo $COMMAND for every command and between just giving up a root shell and encouraging users to do 'sudo su'
It's sudosh - it provides the ability to get a root shell session where every command and its output is recorded.
http://sudosh.sourceforge.net/
If you want to secure the box, you need to RESTRICT (DISALLOW), instead of ALLOW.
I thought a reference to TECO would have clued you in. No, I do not use MS Word to edit config files.
/.? We need another OOG_THE_OPENSOURCE_CAVEMAN. "I WILL BEAT YOU WITH MY OPENSOURCE CD!!!"
What happened to
I agree, there are different requirements between workstations and multi-user servers. SUDO tends to be more useful on servers. One of the additional tools I like to use with SUDO is sudosh. Sudosh is a "shell" that logs everything, so you can avoid the "admin gets tired of typing sudo in fromt of everything and just spawns a shell" problem. They can spwarn a sudosh, and then do what they need to do, and I can still get an audit log. Which brings up another point, sudo provides an audit log, and from a forensic inventigation point of view, this is rather handy. Now, this also implies that your logs get sent to another machine which very few people have access to. Again, all this implies that you are running servers, and more than one server at that.
Even without enabling the root account this works.
There are a very few things I do that way...
Dog is my co-pilot.
If you use MAC/MLS type stuff like selinux (not for OSX obviously), root can be just another user, with some extra freedoms depending on circumstance (not all powerful regardless)
As an example, my understanding (not a guru) is in selinux, you don't have to be root to listen on port 80. If you do start it as root, the app has a system enforced policy that determines what it can do. ie it can listen on port 80, but only write to certain files, not make tcp conections (unless allowed etc). The rights aren't of the starting user, but of the application itself.
When this is applied to sudo, the command you run can be restricted in its operation depending on system policy. I think that the final effect depends on who you logged in as, and how that login context is allowed to change when running sudo. ie some users will be able to run a process via sudo and have it take on all its power, but others will not be able to run it with privileges beyond their own (or some subset of the max for the apps policy)
Some posts have talked about renaming/hiding bash for example. In a full selinux environment, when sudo launces bash (or any app as uid of root), it has no more privilege than system policy allows. If you create your own bash, it only has the security privs that you do, even if launched by sudo. You may end up with uid=0, but contained by your login priveleges. Some users can be assigned extra rights and can do more.
Once again, not a guru - have played a little with it in Fedora Core 4 (enforcing mode, targetted policy), which still allows sudo to do anything, via a selinux aware sudo. I beleive that there is a way that you can make it less transparent, and more secure, but as always security policy is a trade-off between usability and absoulte security. I'm happy(ish) knowing that I have strong password policy for my server and that selinux *helps* stop a compromised app operating outside of its intended policy. However, if you have the password to a sudo unrestricted user, all bets are off. When I'm more comfortable with selinux, I will find out how to wind back sudo and require manual changes in my initial security context before doing particular tasks (like changinf application selinux tagging).
I like what i've seen in selinux so far. Some new stuff to learn, and some things still to win me over, but it is a step in the light direction.
I tried to give up admin on my primary OSX account but in the end it not worth the trouble considering the security risk to my firewalled home network. For an average user its probably not that big of a deal, but trying to do Java development in Eclipse, starting and stopping web servers and tomcat, moving files around, adjusting privs to get things to work right from a normal acct. It was just a huge hassle. It would take me literally 10 times longer to do some tasks. On OSX its not as simple as sudo this or that, and for me it wasnt worth the hassle.
Whats my exposure by using an admin acct? If I were a dumbass who opened every file emailed to me and couldnt see that there was something wrong with a jpg image needing my password, then I might be in trouble. But I'm not, so I'll risk it. As an admin user I havent found the need for the root acct. Anything I would need root to do is easily done via sudo.
I work in a network with 4 1/2 admins, myself included. Notably two of them get so irritated at having to type sudo before every command that they'll just sudo into a shell and be done with it. However, we got sudo configured to last for five minutes or so, so that once you authenticate using sudo, only five minutes of sudo inactivity will require you to re-authenticate. I find that it works well. And of course, there's the extra benefit of not becoming innured to being root.
sudo is 1000 times better than having "root" enabled. First with root disabled somebody has to guess the the correct admin "user id" and "password". Which is more difficutlt than just guessing the password for root. Considering the environment where multiple admins control the machine sudo is only way for accountability.
%usergroup ALL=(ALL) ALL,!SHELLS,!SU,!SHUTDOWN,!HALT
This is called a default-allow policy. It's not going to work. You can't enumerate every possible way of executing a shell on a UNIX system.
If you want a really secure system, enumerate the "safe" commands, and allow them to be executed. Of course, it's going to be a pain - but you decide whether you want security or convenience. It's hard to have both.
useful, thanka
Another derivative of that is when sudo is used to temporarily grant access to root privs. As a consultant who travels around between different customer sites a lot, I sometimes visit customers who set me up my own permanent user account, then turn on sudo access when I get there, and turn it off when I leave. Works very well for all concerned. Much less work for them and less waiting around for me.