Agile Gurus: Do you run OS X as Administrators?

Chris100

When I switched to Macs early this year, I used a best practice from the windows world: I log in as a user who is not an administrator.



I've been talking to a lot of mac people who do not do this. I'm wondering what the security guru's at Agile think about this.



I am getting quite tired of typing an administrator's username and password each time OS X wants to check for updates. But this is just like Windows UAC, and I guess that's the whole point, right? To protect from the damage a rogue process might do?



Any thoughts welcome!



Chris

khad

There are a number of scenarios where applications are not designed to be run in non-admin accounts and the number of hassles I encountered eventually drove me back to run as admin. Thankfully in OS X you are not running as root and need to authenticate before doing anything potentially harmful even (especially?) in an admin account.



My guess is the team here is probably split close to 50/50 on this (in terms of actual usage). I don't think anyone would disagree that it is a nice ideal. There are very good reasons to not run as admin regularly, but it also often ends up requiring one to really "administer" which isn't for everyone.

Grum

I prefer to do most of my work with a non-admin account. I really don't mind the username and password prompts when required, but then again I have been doing system administration for 3 decades so it's part of my job.



The last time I asked this very same question I was pointed at the following resources:

[list]

[*][url="http://www.sans.org/score/macosxchecklist.php"]SANS Mac OS X Checklist[/url] (PDF and DOC files available)

[*][url="http://www.sans.org/about/sans.php"]Who are SANS?[/url]

[/list]



On top of that, at least one piece of malware targeted at OS X earlier this year takes different actions depending on whether it arrives in an admin or non-admin account, and that is enough to persuade me that using a non-admin account for general surfing and mail use is justified.



From ZDNet: [url=http://www.zdnet.com/new-mac-malware-spies-on-you-via-adium-firefox-safari-skype-7000001665/]New Mac malware spies on you via Adium, Firefox, Safari, Skype[/url]



[quote]If the dropper runs on a system with Admin permissions, it will drop a rootkit to hide itself. The malware creates 17 files when it's run with Admin permissions, 14 files when it's run without.[/quote]

MikeMcFarlane

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

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.

MikeT

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

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.

MikeT

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

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

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

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

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

Ben

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.