Admin Rights Justification

@Chuey

elevated access on a production network

As you mentioned, context is key. This, I believe is the key piece.

An administrative account on macOS ≠ elevated network access.

If the two are linked in a vulnerable fashion, as can happen in some AD bound scenarios, then there can be (but is not in itself) valid cause for the conflation. This is one of the many reasons that I strongly advise against AD bind.

Device is not the same as network, application, or data source. In this type of discussion, many conflate these. I hold that it is not the device’s job to make up for poor security/workflow in a network, application, or data source. Proper access controls, auditing, and behavioral modeling can prevent and/or identify undesirable behavior and access to sensitive applications and data.

For example: If one has a good personal security posture, one accesses internet banking with multi-factor authentication. The banking data and the bank’s web app do not reside on the device. So long as one has reasonable certainty of the device’s privacy (we should have a high level of certainty in privacy on Apple devices), the risk is minimal regardless of device used. Further, and to the point of the thread, that risk is not affected by the presence or absence of an administrative account.

This all assumes a 1:1 deployment. The threat model is absolutely different in a shared computer context.

In a rough sketch, without examining particular workflows or needs, some options that come to mind for a shared computer model:
- Don’t use shared computers for sensitive operations/data.
- Users do not get administrative accounts on shared computers.
- Don’t have persistent end user accounts or data on shared computers. What does not exist cannot be compromised. A “guest-only” model.

@milesleacy

An administrative account on macOS ≠ elevated network access.

LOL, I was not saying because you have admin rights on a macOS device means you have elevated network access. I understand how it works and I believe my statement was mis-interpreted.

I'm network certified, security certified, data center certified, ACMT certified, and the list can go on.

My point is -- your reasoning is only justifying why you hand out admin rights. Based on culture, environment, educating, etc. Also, this isn't a "windows" mentality thing. It's a "security" mentality @rhoward . . . I keep hearing that and operating systems are not boundaries in InfoSec.

If you hand out admin rights that's fine -- but justifying it with your reasoning doesn't make it right.

It's not wrong because I say it's wrong.....It's wrong because it doesn't follow basic Information Security protocols and guidelines. Simple as that. I've read the books. Taken the certifications. Attended the conferences. Least permissions is all I can say.

Like @donmontalvo said

...to each his/her own, as everyone has to deal with a different set of responsibilities, different requirements, etc.

All I'm trying to do is let OP @landon_Starr know that he should not hand out administrative rights on his macOS devices based on Security Protocols and Guidelines in the InfoSec world. Especially if he wants to help mitigate risk everywhere he can. Just because you do it over there and he does it over here ... you have all these justifications on why ... doesn't make it right.

That's all.

operating systems are not boundaries in InfoSec

Perhaps, but fact must apply. I’m left to wonder if the argument against administrative accounts would have legs if group 80 had a different label.

admin@macOS ≠ admin@Windows I think everybody agrees there. But admin@macOSMojave isn’t even as powerful as admin@macOSEarlierVersions.

With recent versions of macOS and Mac hardware, even root isn’t really what most people understand root to be any longer.

In an MDM-managed fleet, MDM is the only “true admin” by traditional “administrative” capabilities.

hand out admin rights

It’s not a matter of granting. It’s a matter of not interfering with defaults.

Least permission is a great tenet of infosec. So is usability. The primary use cases that Apple and other major vendors such as Adobe provide assume an administrative account is used. Modifying this default and the expectations of vendor workflows and user experience to revoke administrative privileges has a high usability cost.

I have yet to see a threat that local administrative accounts introduce and isn’t mitigated by compensating controls, either built-in to macOS or implemented as part of best-practice deployment strategies (for non-exhaustive example: Gatekeeper, SIP, Secure Boot, MDM, 3rd party security tools). I’m not saying such a threat doesn’t exist or couldn’t in the future, just that I have not seen one presented here or elsewhere.

This leads me to the decision point of: “Is the degradation in usability associated with loss of administrative accounts an acceptable cost to provide a theoretical benefit that cannot be quantified in practice?”

As a Mac administrator and a certified security professional, I definitely agree with @Chuey and @jhuls , they make some fantastic points. @milesleacy I would like to address the following point, "What company or personal data is placed at greater risk when the user has an administrative account instead of a standard account?"

When a user has administrative right to their account, that obviously gives them the ability to install third party applications at will. This also makes them susceptible of installing malware and viruses. Threats like Remote Access Trojans, Keyloggers, and remote backdoors can all lead to data leaks on client machines that go unrecognized by the user. Many of these threats even operate at a level where they are unnoticed not only the user or support staff, but by the computer's antivirus or MDM. Down the road these threats can lead to network breaches or larger security concerns. Sure, you can do your best to blacklist or restrict the software installed on the computer, but thousands of new threats are surfacing daily.

The concept of least permissions is not a suggestion, but more a standard for protecting your data, end users, and organization.

@ChrisMike wrote:

When a user has administrative right to their account, that obviously gives them the ability to install third party applications at will.

This opens the door to interoperability and compatibility issues can result in critical deadlines being missed.

Missing a critical deadline can be quite costly to the company.

Giving a user admin rights increases risk beyond data loss and access.

install third party applications at will. This also makes them susceptible of installing malware and viruses.

The compensating controls for user-installed software are Gatekeeper and code signing, the built-in malware protection in macOS, SIP, T2, and any 3rd-party product(s) the organization may be using.

So what if someone can install Angry Birds? Apple have provided systems, tools, and a platform that can give us confidence that, so long as we retain and enforce defaults, that they can only install software from reputable sources, and If a bad actor sneaks in, the system is well protected and Apple have a kill switch. All of this is before we add any 3rd-party tools that may provide additional intelligence, protection, and response options.

Anyone who has worked with a DISA STIG knows that implementing every recommendation in the STIG will likely result in an unusable system. An organization must take these lists of ‘most secure states’ of each feature and setting and decide which are necessary in a given deployment and which represent necessary or acceptable risks given the nature of the work to be done on that system.

We als need to consider duplicate controls. If we have, for the sake of argument, ten controls against a particular threat, but each of those controls inflicts a 10% usability cost, simple math says we can’t use all ten. So how many do we use? Is two too few? Is seven too many? This is the conversation and decision each organization must make.

Least permission, on its own, is a desirable ideal. It must be weighed and considered as part of a well-reasoned security posture, not dogmatically adhered to regardless of impact and compensating controls.

I’m not telling anyone what their organization’s position on administrative accounts ought to be. I am saying that coming up with that position requires a thorough examination of real factors rather than dogmatic adherence to an abstract ideal. There may be (and I would argue, should be) several answers for different populations in an organization. I believe I’ve made clear that in my own view for general user populations, having administrative accounts tends to be the best choice. However, when considering computers that will work with PCI data, the determination is obviously different, but only for that specific set of computers based on their unique needs and requirements.

In general, my advice is:
- don’t be dogmatic - use established tenets of security as a guide
- customize posture and policy to the needs & requirements of specific groups
- don’t forget the tenet of usability
- consider compensating controls
- determine when there are enough controls
- define acceptable risks

@ChrisMike wrote:

The concept of least permissions is not a suggestion, but more a standard for protecting your data, end users, and organization.

+1

In my last (solo) Jamf admin role I had 200ish managed devices and up to 150 users including freelancers and contractors, multiple offices and timezones, plenty of senior sales people working from home, and from the start I decided to not grant admin rights at the account level, but instead to grant admin rights via Self Service on a part-time, as needed basis.

My primary justification for this was not to lock users out, but to slow down potential malware and to force anyone making any change significant enough to require admin rights to have their machine check in (recon).

This policy meant that all I had to do was teach a user for to use the 'Grant Admin Rights' task in Self Service - the trick being teaching an understanding of the timing, run the task before starting an installer or trying to unlock a preference pane - rather than keep up with software engineers wanting their own IDE, salesfolks installing who-knows-what webinar software, home users needing to connect their own personal printers, etc.

By occasionally reviewing the logs of that Grant Admin Rights policy I could get a sense of who was constantly installing software or doing anything that require those rights, and either follow up with them individually, write and share documentation, or add policies to Self Service for items that were being installed regularly.

In any case, the key to this type of policy decision is to explain and sell the justification: what is the actual need - not simply the emotional idea of 'owning' an organizational device - balanced against the environment and the available support resources.

The SAP team released this https://github.com/SAP/macOS-enterprise-privileges although I've never used it - it's probably a better solution than mine:

promote_to_admin.sh

#!/bin/sh

# dseditgroup to promote the currently logged in user to admin rights

if [[ `/usr/bin/dscl . read /Groups/admin GroupMembership | /usr/bin/grep -c $3` == 1 ]]
    then /bin/echo "$3 is in the admin group, exiting"
        exit 0
    else /bin/echo "$3 is not an admin, promoting.." 
fi    

/usr/sbin/dseditgroup -o edit -a $3 -t user admin

demote_from_admin.sh:

#!/bin/sh

# dseditgroup to demote the currently logged in user to standard account

/usr/sbin/dseditgroup -o edit -d $3 -t user admin

Then from a Self Service task, run Promote as a script set to Before, use jamfHelper etc to notify the user to proceed, then from Files and processes run something like:

sleep 300 && /usr/local/bin/jamf policy -trigger demote && /usr/local/bin/jamf recon

This could obviously be a lot more graceful, but it worked well for being able to quickly clone the policy and change the sleep value to allow, say, a member of the Engineering dept. 30min of 'admin' time instead of 5min. Having the scripts broken out separately also provided some flexibility to handle one-off edge cases, like permanently promoting someone who had shown themselves trustworthy.

@pete_c something similar to the two scripts I posted here to temporarily elevate non admin users trying to update/upgrade/reinstall 10.13.6.

Scroll tdown to bottom...

https://github.com/kc9wwh/macOSUpgrade/issues/56

Hi everyone, my secadmin team wants to remove admin rights for all of my users. I initially thought that the Jamf Connect Login P.A.M module was able to do this, but I was mistaken. the P.A.M module only allows you to run sudo commands and use a cloud identity provider to enter your password. Since I couldn't use P.A.M, I created a simple script that would make it possible to run sudo commands without an admin account based on all of the information you all provided. Thanks to everyone for pointing me in the right direction.

1. Make sure to run this script with a Jamf policy
2. I've included security features to prevent users from editing System Preferences, attempting to remove the Jamf Binary, and editing the sudoers file.
3. After you've removed admin rights, work with your users to determine standard software to keep in Self-Service for installation.

#!/bin/bash

# Identify the username of the logged-in user

currentUser=`python -c 'from SystemConfiguration import SCDynamicStoreCopyConsoleUser; import sys; username = (SCDynamicStoreCopyConsoleUser(None, None, None) or [None])[0]; username = [username,""][username in [u"loginwindow", None, u""]]; sys.stdout.write(username + "
");'`

# Create file named "standard" and place in /private/tmp/

touch /private/tmp/standard 

# Populate "standard" file with desired permissions

echo "$currentUser ALL= (ALL) ALL
$currentUser    ALL= !/usr/bin/passwd root, !/usr/bin/defaults, !/usr/sbin/visudo, !/usr/bin/vi /etc/sudoers, !/usr/bin/vi /private/etc/sudoers, !/usr/bin/sudo -e /etc/sudoers, !/usr/bin/sudo -e /private/etc/sudoers, !/usr/local/bin/jamf" >> /private/tmp/standard

# Move "standard" file to /etc/sudoers.d

mv /private/tmp/standard /etc/sudoers.d

# Change permissions for "standard" file

chmod 644 /etc/sudoers.d/standard

exit 0;     ## Sucess
exit 1;     ## Failure

@bwoods

Many including myself have been doing this with Puppet,Ansible,Salt or pick you CM tool, which offers better control. I have seen strange things happen sometimes when trying to grab the user from the console