Agile Gurus: Do you run OS X as Administrators?

Chris100
Chris100
Community Member
Warning No formatter is installed for the format ipb

Comments

  • khad
    khad
    1Password Alumni
    edited December 2012
    Warning No formatter is installed for the format ipb
  • Grum
    Grum
    Community Member
    Warning No formatter is installed for the format ipb
  • MikeMcFarlane
    MikeMcFarlane
    Community Member
    edited February 2013

    I've tried running as both, and running non-admin just seemed a hassle, for example the automatic update process doesn't run so I needed to remember to run it every day to ensure my OS and apps were all patched (yes, I could have run a script at logon etc). I'd rather keep my OS and apps fully patched, as from what I have read before that is one of the most important ways to keep your system safe (as well as staying away from porn sites, although plenty reputable sites now carry malware) than run the other risks.

    The links are interesting thanks.

    I think most Linux versions are now like this, at least Ubuntu is, the default account is an admin but a password is still required for anything that effects the OS. This doesn't make it right, but it seems an acceptable risk.

  • Chris100
    Chris100
    Community Member
    edited February 2013

    I've wavered too, but now settled on non-admin. I agree it a hassle. So is NoScript, but I continue to use that as well (its the main reason I still use firefox.)

    To make my life easier, I created an administrative user with a short username. So the extra typing (UN+PW instead of just PW) is not such a big deal.

  • Hi guys,

    Loving this discussion.

    Security on Windows has massively improved since Windows Vista, they've learned from their mistakes and are heading in the right direction. Everybody benefits from a secure Windows platform and of course, the rest. There are still many things they can do to improve the platform but so can OS X.

    The old days when Windows users are running as admins, is pretty much the same as running as root on *nix including OS X, it was just too much power that shouldn't granted by default in the first place. Admins on OS X is still a bit too much but it's much less serious than running as root. In addition, the OS X (and *nix) is smartly designed to do its own checks and balances by prompting to make sure you're doing the right things.

    The latest additions of GateKeeper and sandboxing made this even more clear that while OS X is strong, there are still many areas it can definitely improve and security will just keep getting better from now if Apple keeps focusing in this area. I believe the GateKeeper is a way to also make sure the admins a bit more restrictive but it doesn't block you completely from doing what you want. They're doing what they can to improve the checks and balances with the admin accounts.

    For power users, there are too many tools that'd require admin rights, it quickly gets annoying, and they'll probably stick with admin accounts. Usually, those are the same type of folks that know what they're doing and always take steps to protect their data.

    For regular or casual folks, they should be standard accounts and while it can be annoying, they may benefit the most from the restrictions.

    For me, I'm a power user and do take some steps to protect myself (using 1Password, no automatic login, knox secure vaults, restrict downloads from unknown sites and if known sites > virtual images, little snitch to filter connections).

  • slessard
    slessard
    Community Member

    I have used a non-admin account on OS X for many, many years. I do agree that there are some hassles, but overall I do feel that the hassles are minimal/tolerable, especially when combined with Path Finder.app and a properly configured /etc/sudoers file. Path Finder.app has a powerful feature that allows you to run a GUI process as "root". The /etc/sudoers file does so much more than control which user can run as "root." It controls which user(s) can run as any other user and what that user can run when running as that other user. (Read on for the explanation.)

    For me there are two main pain points to running as a non-admin user: 1) GUI apps that expect to be run as administrator, 2) Shell commands that need to be run via sudo.

    GUI apps that expect to be run as administrator

    In my experience these apps break down into two sub-categories: 1) apps that justifiably expect to be run as admin, 2) poorly written apps that assume everyone runs as admin. An example of an app that justifiably expects to be run as admin is OS X's Console.app. Certain log files can only be read when Console.app is run as admin. In a case like this I usually use Path Finder.app to run Console.app (or other app) as "root." That being said, there is still a difference between running as admin and running as root. If the app justifiably expects to be run as admin, but I don't have a high degree of trust, or the app is poorly written and assumes it will be run as "root" I use Fast User Switching to login to my admin account and run the app in question. Fortunately I have run across few such poorly written apps so dealing with them has been only a minor nuisance.

    Shell commands that need to be run via sudo.

    The average OS X user probably never needs to run Terminal.app in which case the need to run something via sudo will never be an issue. But power users, and especially software developers, this is an issue that comes up many times a day, every day. In this case I used to run su - adminuser (where "adminuser" is the name of my admin account) to switch the shell session to run under my admin account. The problem with this solution was that the context was never quite right. Sure the shell was now running under my admin account and I could sudo all I wanted, but accessing things that were owned by my non-admin account was still a pain.

    What I needed was something akin to user escalation in the GUI world where even a non-admin user can run an app that requires admin privs. That user escalation in the GUI world is essentially the same as a non-admin user telling the OS, "Please run this GUI app via sudo using this admin account username/password." The problem is that by default OS X has no similar user escalation for shell commands. By default sudo can only be run by admin accounts. By default there is no way for a non-admin user to tell the OS, "Please run this shell command via sudo using this admin account username/password." Thankfully OS X does have the ability to make this type of user escalation possible by careful configuration of the /etc/sudoers file. I strongly recommend you run man sudoers to read the documentation for this file.
    I made a small and very restrictive addition to the default configuration. I added my non-admin account (regularuser) to the User privilege specification section as shown in the snippet below. (The other three lines in the snippet are all there by default.)

    # User privilege specification
    root    ALL=(ALL) ALL
    regularuser ALL=(adminuser) /usr/bin/sudo
    %admin  ALL=(ALL) ALL
    

    The gist of my addition to this file is that "regularuser" is allowed to run the sudo command for the sole purpose of running a command as "adminuser" AND the only command that "regularuser" can run as "adminuser" is /usr/bin/sudo. The only remaining question is how does a non-admin user invoke sudo in such a manner? The answer is fairly simple: sudo -u adminuser sudo. Here's an example:

    A non-admin user cannot read the /etc/sudoers file:

    $cat /etc/sudoers
    cat: /etc/sudoers: Permission denied
    

    And a non-admin user cannot run plain old sudo to read the /etc/sudoers file:

    $sudo cat /etc/sudoers
    Password:
    Sorry, user regularuser is not allowed to execute '/bin/cat /etc/sudoers' as root on macbook.
    

    But with the above configuration "regularuser" is the only non-admin user that can run sudo as the "adminuser" to read the /etc/sudoers file:

    $sudo -u adminuser sudo cat /etc/sudoers
    Password:
    Password:
    # sudoers file.
    #
    # This file MUST be edited with the 'visudo' command as root.
    # Failure to use 'visudo' may result in syntax or file permission errors
    # that prevent sudo from running.
    #
    # See the sudoers man page for the details on how to write a sudoers file.
    #
    

    In this last example you will notice that the password prompt appears twice. That's not because I entered the password incorrectly on the first try. That's because I need to enter two passwords, the first is the password for the "regularuser" account and the second is for the "adminuser" account.

    Conclusion

    I am a big advocate of using a non-admin account for everything possible. I hardly ever have to login to my admin account. I hope that these two tips (Path Finder.app and the sudoers configuration) help make it easier for you to use a non-admin account for everything as well.

  • Hi @slessard,

    Thank you for writing it down, that's a great idea. It would be interesting to see if there's a way to make this easier to use via GUI for some folks.

    I could imagine like an OS X app in the standard account that you open up, drag certain apps that needs admin rights into this app and you give it your admin rights to authorize the apps into the sudoers list for this account or adjust it to allow other accounts as well. After that, it'll automatically run in the admin sandbox for certain standard accounts without prompting for the admin rights.

  • slessard
    slessard
    Community Member
    edited February 2013

    It would be interesting to see if there's a way to make this easier to use via GUI for some folks.

    Ask and ye shall receive. :-) cocoasudo: A graphical Cocoa based alternative to sudo

    I could imagine like an OS X app in the standard account that you open up, drag certain apps that needs admin rights into this app

    I used to use Pseudo.app for this, but it is a PPC-only app. :-( It appears there is now also LaunchAsRoot.app for 10.6.6 or later, but I've never tried it. Since I already have Path Finder.app I'll stick with it. These three options may not do the sandboxing in the way you imagined, but they are better than nothing at all.

  • slessard
    slessard
    Community Member

    p.s. If this comment in the /etc/sudoers file scares you

    # This file MUST be edited with the 'visudo' command as root.
    

    Don't worry. You can use TextWrangler.app to edit the file. And TextWrangler will even prompt you for an admin username/password to get permission to edit and save changes to that file.

  • Chris100
    Chris100
    Community Member

    Slessard, thanks for the suggested tweak to the sudoers file. I can see where this will occasionally be quite useful.

    I'm sticking with non-admin, so every little trick helps.

  • benfdc
    benfdc
    Community Member

    Thought I'd add my thoughts here, but Chris100 already covered them in #5. I very much appreciate the other tips in this thread.

  • Personally I do run logged into an admin account most of the time (unless I'm testing something specific). I agree ideally I wouldn't have to do this, and I don't know of anything specific off the top of my head that requires that I do run as an admin. Force of habit more than anything I guess. I was a sys admin in a previous life.

  • jpgoldberg
    jpgoldberg
    1Password Alumni

    From the time I got my first Mac (2002) until just a few months ago, I ran as non-admin. And it is what I recommend. My reasons for changing are pretty idiosyncratic, and don't make me too much of a hypocrite in my "do as I say, not as I do" stance.

    I've also been using /etc/sudoers in the way that @slessard describes above. That has made it much easier to run as a non-administrator.

    With Gatekeeper in Mountain Lion the need to run non-admin is reduced, but by using the sudoers mechanism, there really isn't a lot of difficulty with running non-admin.

    Cheers,

    -j

    –-
    Jeffrey Goldberg
    Chief Defender Against the Dark Arts @ AgileBits
    http://agilebits.com

This discussion has been closed.