Why shouldn't I use my Mac as an administrator?

[CylonGlitch]

Even if, as GG wants to claim, that there is no good reason to run as user on the system today, it doesn't mean that it will remain that way.

Example. Say you decide to run day to day as administrator; ok, all is good and the years slip by. Then one day some clever hacker figures out how to, using Safari (or some other method of attack) to bypass some security functions remotely and install something into the system that gives him control of your machine. Being that no system is bulletproof, this happens because as administrator you have access to files that are outside the scope of normal user (system files). Thus your machine is now compromised and you don't even know it until something nasty happens.

There are a lot of "what if's here." Lots of things that have to happen before real damage can occur. BUT having those extra permissions (and they exist) just leaves the door open a crack.

Since the user account and the admin account both validate software very similarly; why bother taking the risk and leaving the door open even just a little bit. It isn't like running as user is any more difficult. I've been running as user for years and never even think about it.

It's like locking your house and instead of leaving the key under the rock in the garden, you take it with you. Sure no one knows where the key is hidden so you should be safe; but do you really want to take that little risk when it takes so little effort to be just a bit safer?

Yes, at this point there is little reason to run as user; but there is also little reason to NOT run as user.

 

[macnjack]

The original question was fairly general and didn't get into specifics about probability (likelihood) of a particular scenario but there are cases where not being logged in as an administrator can be beneficial.

For example, in 2011 there was the USB thrumbdrive/Firewire direct memory exploit that allowed someone with physical access to extract passwords directly from memory from a sleeping mac in a matter of minutes. This means any password entered since boot can be extracted.

Yes, this requires firewire. Yes, this requires physical access. But this does satisify a scenario for not being logged in as admin because your admin password is now compromised if you typed it to log in at boot up.

Likelihood is probably small as fewer macs are shipping with firewire and this is some high price gear but just saying....these exploits do exist and we hear about it from time to time.

http://www.informationweek.com/secu...word-vulnerability-sleep-mode/d/d-id/1099261?

 

[bobr1952]

For many users (like me) having to log into a different account to perform admin duties would be a pain--not something I really feel is necessary for the security of my Mac. I am security conscious and do what is necessary as long as it is not overly inconvenient. Strong passwords, using each password uniquely, enabling OS-X firewall, enabling Firevault, require login after sleep. Security should be a pick and choose operation where you use the security measures that fit your needs.

 

[LV426]

For many users (like me) having to log into a different account to perform admin duties would be a pain--not something I really feel is necessary for the security of my Mac. I am security conscious and do what is necessary as long as it is not overly inconvenient. Strong passwords, using each password uniquely, enabling OS-X firewall, enabling Firevault, require login after sleep. Security should be a pick and choose operation where you use the security measures that fit your needs.

All your precautions are very wise but it doesn't change the fact that you are more at risk if you run day-to-day operations using an account with admin privileges than as a standard user. The risk may be very small, but it's an additional risk nonetheless. It's entirely up to you, of course, whether you choose to ignore that risk.

For most users, it's a no-brainier because admin functions are used relatively rarely.

 

[GGJstudios]

All your precautions are very wise but it doesn't change the fact that you are more at risk if you run day-to-day operations using an account with admin privileges than as a standard user. The risk may be very small, but it's an additional risk nonetheless.

No, the risk is non-existent in today's computing environment. The only risk you've demonstrated is a hypothetical risk, based on conditions that do not exist and may never exist. That's akin to trying to protect against an OS X virus that has never existed.

For some users, it's a no-brainier because admin functions are used relatively rarely by those users.

Fixed that for you, since you have no idea what most users prefer or what they do with their computers.

Again, if anyone prefers to run on a standard account, that's their right. It's simply not required for safe computing in today's operating environment, and no one knows if that will ever change in the future.

 

[LV426]

No, the risk is non-existent in today's computing environment. The only risk you've demonstrated is a hypothetical risk, based on conditions that do not exist and may never exist. That's akin to trying to protect against an OS X virus that has never existed.

Fixed that for you, since you have no idea what most users prefer or what they do with their computers.

Again, if anyone prefers to run on a standard account, that's their right. It's simply not required for safe computing in today's operating environment, and no one knows if that will ever change in the future.

Will you give us a break. I'm a software developer and I rarely use admin functions at home on my Mac. My day to day work does not involve installing software on my Mac, creating user accounts etc. Likewise for my many friends who have Macs. And, I am absolutely sure, the great majority of users. If the typical user of a Mac were often required to perform admin functions, it would be far less of a useful tool. There, fixed that for YOU.

You have absolutely no idea at all how safer one might be by running normal operations as a standard user. You arrogantly say there's no difference but conveniently ignore the fact that OS exploits can and do happen and - has often been pointed out - when malware runs in the context of an administrator, you are more at risk.

Instead of repeating your mantra, you might be better served firing off your crazy theories to the security experts who refute your claims.

 

[TheGraphicMac]

Bahhhhh. Run as admin. They're just being cautious.

 

[laurihoefs]

Will you give us a break. I'm a software developer and I rarely use admin functions at home on my Mac. My day to day work does not involve installing software on my Mac, creating user accounts etc. Likewise for my many friends who have Macs. And, I am absolutely sure, the great majority of users. If the typical user of a Mac were often required to perform admin functions, it would be far less of a useful tool.

The document you quoted earlier is mostly about securing the computer and its users from threats caused by user error, and securing users against eachother in a multi-user environment. None of this works, if any single user can easily gain admin priviledges by just entering a known password.

If an admin does something that requires admin priviledges, an admin password is requested.
If a user does something that requires admin priviledges, an admin password is requested.
How is one scenario more secure than the other?

The only thing more secure in a normal user account is, that a user that does not know the admin password can not mess with system settings or install unwanted (and possibly malicious) software. This only works as a security measure, if the user does not know the admin password. If the admin and the user are the same person though...

 

[Alrescha]

The only thing more secure in a normal user account is, that a user that does not know the admin password can not mess with system settings or install unwanted (and possibly malicious) software. This only works as a security measure, if the user does not know the admin password. If the admin and the user are the same person though...

The goal of not running as an admin user is not to protect the system from the user, but to protect the system from the accidental invocation of malicious software. If this happens as an admin user, that malicious software automatically has access to more system resources than if it happened with a non-admin user. That is the whole point of not running as admin.

How you evaluate the risk, or whether you consider these system resources valuable enough to protect, is of course up to the owner of the machine.

A.

 

[laurihoefs]

The goal of not running as an admin user is not to protect the system from the user, but to protect the system from the accidental invocation of malicious software. If this happens as an admin user, that malicious software automatically has access to more system resources than if it happened with a non-admin user. That is the whole point of not running as admin.

How you evaluate the risk, or whether you consider these system resources valuable enough to protect, is of course up to the owner of the machine.

A.

Exactly. Thank you for clarifying this.

I'll try to rephrase the point of my previous post:
If a user can obtain admin privileges, there's nothing stopping that user from accidentally giving malicious software the needed elevation. And this is always the case, where the admin and user are be the same person.

 

[Alrescha]

Exactly. Thank you for clarifying this.

I'll try to rephrase the point of my previous post:
If a user can obtain admin privileges, there's nothing stopping that user from accidentally giving malicious software the needed elevation. And this is always the case, where the admin and user are be the same person.

The difference being that as an admin user this malicious software can have its way without user knowledge or intervention, whereas running as an non-admin user will require the user to type in an admin user and password. In any security-concious environment, that is a big difference.

A.

nb: this was poor phrasing on my part. I meant to say that software running as an admin user has access to those previously-mentioned admin abilities without the knowledge of the user and that difference (user awareness vs no awareness) could be important.

 

[GGJstudios]

You arrogantly say there's no difference but conveniently ignore the fact that OS exploits can and do happen and - has often been pointed out - when malware runs in the context of an administrator, you are more at risk.

No, you are not at more risk, since any software/malware installation that wants access to system files will require the user to enter the admin password, whether they are running as a standard user or as and administrator. The password is required in either case.

No OS X exploit has ever been released in the wild that capitalizes on any difference between running a standard vs admin user account. Just because exploits in general have happened or may happen does not mean they have or will happen with regard to which type of user account is involved.

The goal of not running as an admin user is not to protect the system from the user, but to protect the system from the accidental invocation of malicious software. If this happens as an admin user, that malicious software automatically has access to more system resources than if it happened with a non-admin user.

Not true. As stated above, the admin password is required to access system files, even if the user is logged in as an administrator. There is no additional protection in this regard by running as a standard user.

The difference being that as an admin user this malicious software can have its way without user knowledge or intervention, whereas running as an non-admin user will require the user to type in an admin user and password.

False. See above.

 

[laurihoefs]

The difference being that as an admin user this malicious software can have its way without user knowledge or intervention, whereas running as an non-admin user will require the user to type in an admin user and password. In any security-concious environment, that is a big difference.

A.

Depending what the malicious software is attempting, possibly. And that would still require the software to bypass any admin password prompts and restrictions, by for example using an exploit, which are, at least at this moment, not publicly known. An admin account is still far from the root account.

I should have been more clear, that I was writing from a single user perspective.

I agree, that separate user and admin accounts are a good and an absolutely needed security measure in a multi-user environment. In a security-concious environment that is a big difference, which is what the documents quoted earlier were referencing to. Whether the risk on a personally owned single user computer is high enough to make a separate admin account a sensible option is, like you said, up to the owner to decide.

 

[Alrescha]

Depending what the malicious software is attempting, possibly.

One simple example is that if the software is running as admin, it can write to /Applications. If running as user, it cannot. I can think of a few ways ways of causing problems using that ability

I agree, that separate user and admin accounts are a good and an absolutely needed security measure in a multi-user environment.

...and I do not make this distinction. In my work environment I recommend and personally use a non-admin account - even on single-user machines.

A.

 

[laurihoefs]

One simple example is that if the software is running as admin, it can write to /Applications. If running as user, it cannot. I can think of a few ways ways of causing problems using that ability

But wouldn't elevating any process to admin/higher rights always require a password to be entered? Unless you take the possible exploits into account of course.

 

[GGJstudios]

But wouldn't elevating any process to admin/higher rights always require a password to be entered? Unless you take the possible exploits into account of course.

Yes. No software can gain elevated access without the user entering the admin password, even if they're logged in as an administrator. There are some here who are trying to invent a risk that doesn't exist.

 

[Alrescha]

But wouldn't elevating any process to admin/higher rights always require a password to be entered? Unless you take the possible exploits into account of course.

By the sheer fact that you are admin, you have elevated rights. You are not root, but you can do more than a normal user. e.g.: In Terminal, as 'user':

$ cd /applications
$ mkdir somebadapplication
mkdir: somebadapplication: Permission denied
$

as 'admin':

$ cd /applications
$ mkdir somebadapplication
$


A.

 

[GGJstudios]

By the sheer fact that you are admin, you have elevated rights. You are not root, but you can do more than a normal user. e.g.: In Terminal, as 'user':

Simply accessing the /Applications folder is not the same as accessing system files and folders, such as library folders or /System. There has never been a single OS X exploit in the wild that can affect admin users that wouldn't also affect standard users. None.

 

[laurihoefs]

By the sheer fact that you are admin, you have elevated rights. You are not root, but you can do more than a normal user. e.g.: In Terminal, as 'user':

$ cd /applications
$ mkdir somebadapplication
mkdir: somebadapplication: Permission denied
$

as 'admin':

$ cd /applications
$ mkdir somebadapplication
$


A.

But file system permissions are not the same thing as process privileges. Any process a user, or even an admin starts, will run with limited rights, and any elevation will require a password. Even if the process spawns another one, elevation will still require a password.

 

[Alrescha]

But file permissions are not the same thing as process privileges. Any process a user, or even an admin starts, will run with limited rights, and any elevation will require a password. Even if the process spawns another one, elevation will still require a password.

Is a security discussion limited to process privilege? If, for example, a malicious person can replace applications that you trust with his own applications without your knowledge, that is probably a bad thing, no?

A.

 

[GGJstudios]

Is a security discussion limited to process privilege? If, for example, a malicious person can replace applications that you trust with his own applications without your knowledge, that is probably a bad thing, no?

Not without you giving that person access to your computer, which is the most basic step in computer security: restricting physical access to your computer by others.

 

[laurihoefs]

Is a security discussion limited to process privilege? If, for example, a malicious person can replace applications that you trust with his own applications without your knowledge, that is probably a bad thing, no?

A.

Yes, but how does the replacement happen in the first place, without the user intervening? Are we now assuming the malicious person is in possession of the admin password, and sneaks the software in by accessing the computer physically? That is an entirely different scenario, and separating admins and users would not even make a difference there, would it?

What was discussed (or at least I thought so), was if it makes it any easier for a malicious piece of software to install itself and do any damage whether the user is logged in as a user, or as an admin. And unless an unknown exploit is used, there is no way that I'm aware of for a process to gain elevated rights without the user giving it permission to do so. And this goes both for user and admin accounts.

 

[GGJstudios]

What was discussed (or at least I thought so), was if it makes it any easier for a malicious piece of software to install itself and do any damage whether the user is logged in as a user, or as an admin. And unless an unknown exploit is used, there is no way that I'm aware of for a process to gain elevated rights without the user giving it permission to do so. And this goes both for user and admin accounts.

That is absolutely correct.

 

[Alrescha]

What was discussed (or at least I thought so), was if it makes it any easier for a malicious piece of software to install itself and do any damage whether the user is logged in as a user, or as an admin. And unless an unknown exploit is used, there is no way that I'm aware of for a process to gain elevated rights without the user giving it permission to do so. And this goes both for user and admin accounts.

Are you saying the ability to write (and in some cases delete) from more directories without additional user interaction does not qualify as "more damage"?

e.g.: poor unsuspecting user runs a malicious script: if our user is admin the script has write access to /Applications automatically. If the user is not admin, the script does not. The example is beaten to death, but there it is.

To me, the whole point is that admin, by the sheer fact of being admin, has more abilities than non-admin. The reason to not run as admin is to keep those abilities away from malicious software and hence reduce the ability of that software to do damage.

A.

 

[laurihoefs]

Are you saying the ability to write (and in some cases delete) from more directories without additional user interaction does not qualify as "more damage"?

e.g.: poor unsuspecting user runs a malicious script: if our user is admin the script has write access to /Applications automatically. If the user is not admin, the script does not. The example is beaten to death, but there it is.

To me, the whole point is that admin, by the sheer fact of being admin, has more abilities than non-admin. The reason to not run as admin is to keeps those abilities away from malicious software and hence reduce the ability of that software to do damage.

A.

If you know the admin password, and run scripts without reading them, it does not matter what type your account is. Pretty much the only folders an admin can change without being prompted for a password are in /Users/"admin user name" and /Applications. Writing anywhere else is not automatically allowed.

If you run a script without knowing what it does, and give it elevation by entering an admin password, a limited user account is not going to protect you.

I'll repeat the point again: if you know the admin password, and enter it when prompted for, it does not matter if you are running as a limited user, or as an admin. The script you are running gains the elevation in both cases. And in either case it requires the user/admin to enter the admin password before anything happens.

EDIT: What's also important to note, that once again, we are talking about an action the user is actively involved with. It does not happen by itself.