Slashdot is powered by your submissions, so send in your scoop

 


Forgot your password?
Close
typodupeerror
×

Sudo vs. Root 327

Posted by CmdrTaco from the security-comes-first dept.
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 ;)
This discussion has been archived. No new comments can be posted.

Sudo vs. Root More

Sudo vs. Root

Comments Filter:

  • Layered Security (Score:5, Informative)

    by Mattygfunk1 ( 596840 ) * on Tuesday March 21, 2006 @11:39AM (#14964254)
    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.

    • Re:Layered Security (Score:5, Insightful)

      by Jason Hood ( 721277 ) on Tuesday March 21, 2006 @11:42AM (#14964277)
      I honestly feel dumber for RTFA.

  • Oh, great! (Score:4, Funny)

    by Len Budney ( 787422 ) on Tuesday March 21, 2006 @11:41AM (#14964267)
    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!

    • I'm going to be even more irresponsible and invoke our good friend Tim Towtdi....

      • sudo /bin/bash
      • sudo su -
      • sudo -s

      • Re:Oh, great! (ways around) (Score:5, Insightful)

        by HTMLSpinnr ( 531389 ) on Tuesday March 21, 2006 @12:49PM (#14964783) Homepage
        Ya know, I've always worked around the first two with exclusions, and the -s flag is automagically included.

        Try the following:
        Cmnd_Alias SHUTDOWN = /sbin/shutdown
        Cmnd_Alias HALT = /sbin/halt
        Cmnd_Alias SHELLS = /bin/sh, /bin/bash, /sbin/nologin, /bin/ash, /bin/bsh /bin/ksh, /usr/bin/ksh, /usr/bin/pdksh, /bin/tcsh, /bin/csh, /bin/zsh
        Cmnd_Alias SU = /usr/bin/su, /bin/su, /usr/sbin/visudo
         
        %usergroup ALL=(ALL) ALL,!SHELLS,!SU,!SHUTDOWN,!HALT
        However, that's not going to stop joe user from copying bash over to /usr/local/bin/myshell and still gaining root that way. A better approach is to permit specifics and allow for an implicit deny rather than explicitly permitting all and denying specifics. There are times though when it's a giant PITA to permit just about everything specific under the sun because there's always going to be one command you've left out here or there. At that point, you just have to trust your users enough to know better and then take steps to secure the machine from the outside world.

    • Re:Oh, great! (Score:4, Interesting)

      by diegocgteleline.es ( 653730 ) on Tuesday March 21, 2006 @12:46PM (#14964756)
      Well, and what happens if it's a application being compromised who runs sudo?

      I've never liked that "security measure" in mac os x or ubuntu. Take a IM app or browser. Find a bug in it, and exploit the hole by running "sudo rm -rf /".

      AFAIK there's nothing stoping that from happening? What that tells to my head is "you can do anything as root by using sudo". How can that be called "security"? I use a shared computer between several people and the first thing I do is to run "sudo passwd" because, well, other person could do it if I don't do it before him.

      If it doesn't have a password, I don't trust it. sudo just helps people to jump walls that they're not supposed to be able to jump.

      • Re:Oh, great! (Score:5, Insightful)

        by GoingDown ( 741380 ) on Tuesday March 21, 2006 @01:07PM (#14964932)
        When running "sudo rm -rf /" it still asks user's password if that user has not ran sudo before on that same environment. In Ubuntu, only FIRST user account created during installation is able to do sudo by default, rest of the accounts are not in wheel group and are not permitted to sudo. Root account is disabled, it is not "account without a password". So, you need to know password of wheel user to be able to use it.

      • Re:Oh, great! (Score:2, Informative)

        by das_cookie ( 619577 )
        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:Oh, great! (Score:3, Interesting)

        by Knuckles ( 8964 )
        I've never liked that "security measure" in mac os x or ubuntu

        As far as Ubuntu is concerned (dunno about OSX) it never was about security, or at least not in an abstract way, "what's more secure: root or sudo?". This is one of those myths that get perpetuated on mailing lists, /. and whatnot and drive me crazy. Someone misunderstood, and since then the myths refuses to die. Everyone writing about this topic should be forced to read the article on Ubuntu Wiki [ubuntu.com]

        Sudo in Ubuntu was done for one thing: convenience

      • Re:Oh, great! (Score:3, Insightful)

        by Excelsior ( 164338 )
        If it doesn't have a password, I don't trust it. sudo just helps people to jump walls that they're not supposed to be able to jump.

        Okay, wrong. Sudo still involves a password. Only allowed "sudoers" are able to run sudo, and they are prompted for a password. Sudo, in my humble experience, actually is more secure simple because of human nature. And here's why:

        1) In distributions that expect you to use root, users tend to leave a terminal logged into root all the time. With sudo, there's an automatic t

  • Sudo (Score:4, Interesting)

    by Poromenos1 ( 830658 ) on Tuesday March 21, 2006 @11:41AM (#14964268) Homepage
    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.

    • Re:Sudo (Score:2, Informative)

      by OxygenPenguin ( 785248 )
      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.
    • There is another reason to run sudo over root, and probably the most important. It is significantly easier to track user actions through sudo since commands (can depending on configuration) be associated with the user that ran them. If everyone used "root", the paper trail is much harder to follow. Its also easier to lock down available system commands.

      In my mind the sudo approach is an obvious chouce. But I use both approaches.

    • Re:Sudo (Score:3, Informative)

      by chill ( 34294 )
      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 need

    • Re:Sudo (Score:3, Informative)

      by lp-habu ( 734825 )

      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 prob

  • Sudo is only useful when there are lots of admins (Score:5, Insightful)

    by eln ( 21727 ) on Tuesday March 21, 2006 @11:42AM (#14964280)
    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.
    • 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 ty

    • Re:Sudo is only useful when there are lots of admi (Score:4, Informative)

      by Joshua Cowan ( 27300 ) on Tuesday March 21, 2006 @12:09PM (#14964448)
      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:Sudo is only useful when there are lots of admi (Score:5, Informative)

      by Flwyd ( 607088 ) on Tuesday March 21, 2006 @12:20PM (#14964534) Homepage
      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.
    • 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).
      • 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.
        • 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

    • 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 [sun.com] which has, unlike sudo, some corporate/security professional appeal. See there. [sans.org] 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" [sun.com] ).

      Sure, sudo can also can be taken to a much higher level when properly configured,

    • 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)
    • None of the admins here has any problem using sudo. And if someone was caught circumventing security policy, they'd be fired. Period.

  • Remote managment (Score:3, Interesting)

    by solarbob ( 959948 ) on Tuesday March 21, 2006 @11:44AM (#14964285) Homepage
    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

  • This just in: (Score:5, Informative)

    by djh101010 ( 656795 ) * on Tuesday March 21, 2006 @11:44AM (#14964286) Homepage Journal
    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).

    • Re:This just in: (Score:3, Informative)

      by pla ( 258480 )
      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
  • 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

  • Good Advice (Score:5, Interesting)

    by Se7enLC ( 714730 ) on Tuesday March 21, 2006 @11:44AM (#14964289) Homepage Journal
    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)

    • Re:Good Advice (Score:3, Insightful)

      by Dom2 ( 838 )
      One of the key benefits of using sudo, particularly in a single user situation is that it uses your regular password, not some "admin" password you typed in at the install 3 months ago and forgot to write down. This is one reason why both OSX and Ubuntu are using sudo.

      Personally, I also like the ability to go back through the logs and see what I've done...

      -Dom

  • Sudo vs. Root? (Score:5, Funny)

    by Evro ( 18923 ) <evandhoffman.gmail@com> on Tuesday March 21, 2006 @11:44AM (#14964291) Homepage Journal
    The winner is clear! [googlefight.com]

  • How To Become Root on OS X (Score:3, Informative)

    by Synesthesiatic ( 679680 ) on Tuesday March 21, 2006 @11:46AM (#14964295) Homepage
    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!
    • 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:How To Become Root on OS X (Score:5, Informative)

      by beelsebob ( 529313 ) on Tuesday March 21, 2006 @12:11PM (#14964457)
      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:How To Become Root on OS X (Score:5, Interesting)

        by ScriptedReplay ( 908196 ) on Tuesday March 21, 2006 @02:24PM (#14965615)
        The root account is disabled by having the shadow password set to * - thus you can't enter a valid password for root.

        Why people keep on confusing this?

        Password login to the root account is disabled by having the shadow password set to * - thus you can't enter a valid password for root. Just because password logins are disabled does not mean the account is disabled — try ps -U root -u root u sometime. Besides, 'root' is just one name for uid=0, change your user's uid to 0 and bam! you're it, whatever name you have (but then if you can change your uid you're it already, this was just an academic example)

        Also, if your login relies on other methods than pam_unix then the star in /etc/shadow is meaningless. So in fact it should be further qualified as password login to root relying on /etc/shadow is disabled... The point being that 'root account is disabled' is hugely misleading.
    • Or alternatively you can just do "sudo -i".

  • Use sudo to revoke root from a single user (Score:5, Insightful)

    by jrifkin ( 100192 ) on Tuesday March 21, 2006 @11:48AM (#14964303)
    One advantage of sudo occurs when a box has multiple admins, because a single admin can have his root privilege revoked without affects other admins.

    But when you share a root account, revoking privilege from a single admin means that every remaining admin has to learn a new password.

    • i guess it depends on WHY you are revoking the admins privilages in the first place. if your just moving them to another group with no hard feelings then i suppose you could argue this. If your getting rid of them for misconduct you have to seriously consider that they may have installed a rootkit.

    • untrue (Score:2)

      by x2A ( 858210 )
      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.

      • Re:untrue (Score:3, Insightful)

        by pclminion ( 145572 )
        I've done that, and it's a serious pain. I'm also not convinced that it won't fuck various things up. For one thing, there is now a many-to-one mapping from usernames to UIDs. The mapping is supposed to be bijective, and a lot of system software probably depends on it. Is your "true username" the associated name from /etc/passwd (in which case all the users would be called "root" presumably because it's first in the list), or does it derive from the $USER environment variable (in which case the user could a
  • 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.

    • Re:2 passwords instead of 1 (Score:5, Insightful)

      by asuffield ( 111848 ) <asuffield@suffields.me.uk> on Tuesday March 21, 2006 @01:44PM (#14965266)
      Actually, you missed the point of why sudo only asks for the user password. And so did the author of that web page (which is why he's wrong).

      Firstly, asking for a root password has no effect on the security of the system. A cracker does not have to crack an extra password. Once your user account has been cracked, if you know the root password and use su (or sudo or whatever), then at some point you are going to login and do that. Unfortunately, the cracker knows your user password - your .bashrc was replaced, the shell you are running is a trojan. The password that you typed in was captured, and the cracker now knows the root password. In fact, it probably just used that password to launch a rootkit.

      This can be solved, with some form of secured authentication path (like a smartcard device, which can't be trojaned using the user's password, and there are also ways to do this without needing extra hardware). sudo supports stuff like that, if you know what you're doing. But simply asking for a second password, in an application running in the terminal, is no more than a speed bump. It's not the second layer of security that it looks like it should be. Anything you type into the terminal is compromised once an attacker has your user password.

      Secondly, shared passwords are bad security. You can't easily change them - it has to be arranged between several people. You have to pass the secret between at least two people on at least one occasion, and somebody else can overhear when you do that. People tend to be less careful about information that is known to several people. If the secret leaks out, there's no easy way to trace who leaked it. There's all sorts of issues with shared passwords. If you really wanted a second password, you should have one 'root' password for every user who has root access (Kerberos systems allow for this scenario, because a Kerberos environment can have secure authentication paths; sudo and su don't, although you could have one 'login' password and one 'sudo' password by creative use of PAM, but you have to tackle the authentication path issue first).

      Thirdly, the point of sudo asking for the user password is to authenticate that the user currently sitting in front of the computer is the same user that logged in at some point in the past. Users are forgetful; they walk away from their console to get coffee without locking it. sudo attempts to verify that the user currently sitting there is probably the right one, and not somebody else who snuck into their office. If you have sudo ask for a single shared root password, then one of the other users with root access could use somebody else's account, and would appear in the logs as that user. That means they deflect blame for their actions onto somebody else. If you really wanted to have a second password with a shared root password, you should ask for both the user and the root password.

      You could argue that a user with root access can always just clean the logs afterwards - but this is not necessarily true. A system can be configured so that syslog immediately sends every message over the network to another host. sudo deliberately sends the message to syslog before running the command, so that this scenario remains secure. The user could immediately disable this configuration, but they can't stop that first message from going out, saying who they are and when they logged in. (We will assume that this scenario involves ssh access to a server located in a locked datacentre, so there is no opportunity to interfere with the physical network connection).

      sudo's way of doing things really does have security advantages. It may be true that these advantages aren't relevant to the default macosx configuration, but that does not mean they don't exist. However, using a single root password, like the article author suggests, does not have security advantages over the default behaviour (see the first point in this post). And the default behaviour is more convinient for users (who only have to remember one password instead of two), which is almost certainly why Apple set it up that way. The article ignored this aspect.

  • My favorite sudo command: (Score:5, Funny)

    by AsnFkr ( 545033 ) on Tuesday March 21, 2006 @11:48AM (#14964308) Homepage Journal
    sudo passwd root

  • Messed up sudoers (Score:4, Funny)

    by Gopal.V ( 532678 ) on Tuesday March 21, 2006 @11:48AM (#14964311) Homepage Journal
    Recently one of my friends editied his sudoers file with the following
    admin ALL=(ALL) ALL
    Now it is obvious to me that he forgot a % in there. From that point onwards, there was no way we could actually run sudo to be able to edit the file using visudo. Since there is no root account, we couldn't just log in as root to fix this issue. And because of the syntax error, sudo refused to work for any user.

    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.

    • Re:Messed up sudoers (Score:3, Insightful)

      by Bake ( 2609 )
      I suppose you could write a small wrapper that creates a backup copy of the sudoers file before editing it. That wrapper then creates an at job to rollback the changes after, say 5 minutes, giving you ample time to verify that the new sudoers file works and remove the at job once testing is complete.

    • Re:Messed up sudoers (Score:4, Informative)

      by petermgreen ( 876956 ) <plugwash.p10link@net> on Tuesday March 21, 2006 @12:04PM (#14964417) Homepage
      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.

    • Single user mode. No boot media required.

      If you've disabled single user mode, there's not much that can be done. That's the nature of security.

    • Re:Messed up sudoers (Score:5, Insightful)

      by cloudmaster ( 10662 ) on Tuesday March 21, 2006 @12:31PM (#14964606) Homepage Journal
      In addition to the other comments about using visudo (which respects the EDITOR env. variable, so if you really wanna use pico or whatever, just run "EDITOR=pico visudo"), you should always leave an active shell runnuing when you're editing something that could potentially break login access. Editing the main authentication scheme in pam.d/? Editing sudoers? Changing nsswitch.conf around? Make sure that you already have a root shell open in another terminal - either another xterm, a virtual console, or something else. Save your changes, make sure they worked, and if not, you can usually use the already-open root shell to change it back.

      Yes, this is the voice of experience with breaking just about everything at some point or another - it's how you learn. Well, it's one way *I* learn, anyway. :)
    • 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.

      If you blow up /etc/passwd or /etc/shadow, you're still g

    • If it was FreeBSD or OS X, you could have tried single-user mode. I assume most Linux distros have an option for that as well, but I could be wrong. Once in single-user mode, you can mount the file system as normal and edit the config file.

  • The best way to secure the root account... (Score:5, Funny)

    by aurb ( 674003 ) on Tuesday March 21, 2006 @11:49AM (#14964315)
    ...is to choose a really difficult password and forget it. This will secure the box from its' worst enemy - yourself.

  • Problem with both sudo and Root (Score:4, Insightful)

    by Lussarn ( 105276 ) on Tuesday March 21, 2006 @11:49AM (#14964316)
    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.

  • No it's not a mystery (Score:5, Insightful)

    by doomy ( 7461 ) on Tuesday March 21, 2006 @11:50AM (#14964320) Homepage Journal
    Every other command after starting a root shell does NOT get logged at all. All you can tell from this is when someone started the root shell. Whatever happened after that is a mystery.


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

    • 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.

  • Sudo more secure? (Score:2, Insightful)

    by smoor ( 961352 )

    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...

  • Ubuntu (Score:3, Interesting)

    by towsonu2003 ( 928663 ) on Tuesday March 21, 2006 @12:02PM (#14964400)
    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.
  • Sudo provides a number of features:
    1. Issue commands as root whith the sudo prefix (and some password checking)
    2. Logging of commands issued using sudo.
    3. Handout of semi-root permisions to assistant operators (PFY's ?)

    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

    • Re:Sudo is a tool not the entire solution (Score:5, Informative)

      by Hieronymus Howard ( 215725 ) on Tuesday March 21, 2006 @12:29PM (#14964591)
      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.

  • Didn't we already have the wheel group for this (Score:3, Informative)

    by SpaghettiPattern ( 609814 ) on Tuesday March 21, 2006 @12:06PM (#14964432)
    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]
    • 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.
  • If Apple made an administrative account in sudoers and a non-admin one without it, most users would probably just run as the administrative account anyway. Sudo's reasonable, but most people will blindly enter their password when prompted for it. It took me years to get my room mate conditioned to ask me whenever the computer asks her something she doesn't understand. To be really secure, you should usually run as a user that has no way to write to system directories. Apple (or maybe BSD) does a really good

  • Here's the Score (Score:5, Interesting)

    by 99BottlesOfBeerInMyF ( 813746 ) on Tuesday March 21, 2006 @12:30PM (#14964601)

    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.
  • 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!
  • Then, you can force sudo to require the root password

    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 h

  • Old, but valid news (Score:3, Insightful)

    by dnamaners ( 770001 ) on Tuesday March 21, 2006 @12:39PM (#14964687) Journal
    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.

  • Alternate methods (Score:4, Informative)

    by Spazmania ( 174582 ) on Tuesday March 21, 2006 @12:40PM (#14964701) Homepage
    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.

  • Pretty Tenuous Argument (Score:5, Insightful)

    by jinxidoru ( 743428 ) on Tuesday March 21, 2006 @12:42PM (#14964718) Homepage
    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.

  • Phil Collins (Score:5, Funny)

    by Jon Luckey ( 7563 ) on Tuesday March 21, 2006 @12:44PM (#14964743)
    Phil Collins probably had fits when this didn't work:

    pcollins$ su su sudio

  • Go check out the main sudo page [courtesan.com] which has tons more info. Also consider making a donation to Todd so he can continue work on this long-time incredibly useful Unix Tool. Or consider helping out with code - my feeble contribution some misc. sudo-tools. [komar.org]

    I'm surprised this article made the front page of /. as it arguably confuses the issue more IMHO.

  • Sudo insecure if same account used for email (Score:5, Insightful)

    by adrenaline_junky ( 243428 ) on Tuesday March 21, 2006 @01:03PM (#14964905)
    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.

    • Re:I, Root (Score:4, Informative)

      by Aranth Brainfire ( 905606 ) on Tuesday March 21, 2006 @02:43PM (#14965823)
      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.

Slashdot Top Deals

A morsel of genuine history is a thing so rare as to be always valuable. -- Thomas Jefferson

Close