Developers without local admin rights

[evarona]

Ok, I've seen a few posts on aspects of this but I'd like to get some feedback from JAMFNation on how they deal with the following requirement.

We are working on a 10.8 deployment for a development project. All of the developers will be using Xcode, Ruby on Rails, Java, Python, MySQL and other tools. Our security team has a number of requirements, the primary 2 being "no local admin rights" and "restrict ALL software installs to Self Service".

So we have a logon script that adds the console user to the _developer group by default. But we keep running into elevation problems. For example, the first time you launch Xcode and create a new project or install the SDKs, you need admin rights to continue. Other examples are Ability to stop/start MySql, change network settings (toggle proxy and modify proxy bypass mostly) and more. I've spent the last couple of days working on understanding the syntax for the sudoers file but have come to realize that it only seems to work from the command line. It seems like I have to modify /private/etc/authorization but that's not well documented. How can I get this to work in the GUI?

Secondly, RVM and some other apps will connect to a marketplace to download plug-ins, frameworks and other goodies. We repackaged but can't keep up with the demand of similar requests. Should I be telling security this isn't completely feasible?

Any feedback or personal experiences are welcome.

Thanks,
--Emil

[talkingmoose · Accepted solution]

Part of managing security is knowing what can't be managed and documenting those risks.

I hate the idea of giving developers admin privileges when they say they need them to do their jobs. Mostly, they want admin privileges to install development software. If this is the only reason they're requesting these privileges then they're no different from any other user. Licensed developer applications should be tracked and managed just like Adobe CS or Microsoft Office. That's for an IT administrator to handle. If developers need faster than normal response times then put those in place.

Rarely have I ever seen them mucking around in the hidden areas of a Mac like the /etc/hosts file or /usr/bin but assuming they do you can choose to open these off-limits places as you discover them or you can decide "they really do need administrator privileges" because they're digging into system areas to do their jobs.

Lots of folks think laws like the Sarbanes-Oxley Act are all about how IT should lock down computers when they're really about documenting your security and performing regular audits. If can't lock down a machine THAT'S OK. You just need to be responsible for documenting these as security risk areas and then auditing these areas on a routine schedule to ensure you still need these exceptions in place. That should be good enough for your security group. If it's not then the folks in that group don't understand their jobs.

[Josh_S]

I've done a bit of research into modifying the authorization file. The following page is a great primer:
http://mattsmacblog.wordpress.com/2012/01/05/making-use-of-the-etcauthorization-file-in-lion-10-7-x/

I haven't played extensively with Xcode, but I think the following two keys are what you're should look at changing: com.apple.docset.install and com.apple.dt.Xcode.MoveToTrashRights

I give everyone _lpadmin (printer admin) access and then just modify this file to change admin to _lpadmin. The following *should* work, assuming they have _lpadmin rights. Please test extensively before deploying in your environment, we don't make changes to this file for Xcode so it's relatively untested. Also, keep in mind that Apple can, and has, regularly made changes to this file. Make sure to re-test this with each new version of the OS and future patches may overwrite changes that you make. It wouldn't be a horrible idea to make an extension attribute that checks the values of specific keys in this file.

#!/bin/sh

authFile='/etc/authorization'
/usr/libexec/PlistBuddy -c 'Set :rights:com.apple.docset.install:group _lpadmin' "${authFile}"
/usr/libexec/PlistBuddy -c 'Set :rights:com.apple.dt.Xcode.MoveToTrashRights:group _lpadmin' "${authFile}"

[donmontalvo]

As some others have suggested, lock down the workstation, and toss a few OS X virtual machines at them to do as they wish. ;)

[alexjdale]

Wow, the "no admin rights" requirement would never fly here, we have thousands of software developers working on a diverse array of projects and there is no way the security team could get away with slowing them down like that (those restrictions would cost us many millions of dollars). Sorry to hear you have to deal with that.

I would push back on the security team. There is no reason that admin rights can't be managed in a sane fashion. Security is critical, but they must have specific concerns that can be addressed some other way (like automated re-installs of software that admins may be tempted to remove, or some other way of managing compliance).

It sounds like a typical security team making easy (for them) blanket policies so they can say they are locked down, but the needs of the business must also be weighed.

[rtrouton]

I'd like to echo what Don said. If the requirement is "no admin rights" on the workstation, the best way to handle that is by moving development into virtual machines and giving the developer admin rights there. That way, it's sandboxed and you can also have a template VM available for quick rebuilds if somebody breaks something.

I'd also recommend pushing back on the security requirements to get clarification on exactly what's being secured against. What you may wind up with is a Rube Goldberg-like configuration which will break every time Apple releases a new OS. Since Apple has switched to an annual OS release cycle, that's a huge burden of work on you, but not on the security team. Lay out the labor and other costs associated with what they're asking for to your management and make the security team justify the mandate they're handing down.

[donmontalvo]

Thanks Rich, and for anyone who hasn't yet read this...

http://derflounder.wordpress.com/2013/01/21/setting-up-esxi-5-1-on-a-2011-mac-mini-server/

You'll want to bookmark Rich's blog page. ;)

Don

[evarona]

Thanks all for the quick responses. I'm spending more time on this issue than expected and it's impacting my other projects so I appreciate the input.

@Don: I meant to include this in my original post but forgot; VMs aren't an option. I had suggested it but the development team told me they could not sandbox the entire dev environment; they would still need to access network resources. With that, the security team consider the VM just another unmanaged system and shot it down. Believe me, I'm pushing back as hard as I can but the fact remains that our security team has the job of securing company assets and the brand. They just won't let us go to prod if they don't approve and this is considered non-negotiable so far. (and the beat goes on...)

@Josh_S: Thanks. I saw that post but moved on because SysPrefs isn't the first order of business. But I'll go back and review it as well as your suggestions. I'm especially glad to see that I can manipulate the auth file with PlistBuddy seeing that I suck at sed!

@Rich: First off thanks for your blog and posts, they've been immensely helpful. I couldn't agree more with your comments. I've pushed back time and again telling them that pulling admin rights is not a requirement, it's a setting. But as I implied above, they've got the bigger hammer and have sold this "best practice" of denying local admin rights to senior management. I've been pushing the cost/benefit model argument but have been told that until ALL possible options have been exhausted, we need to continue down this bumpy, ugly road.

[donmontalvo]

@evarona wrote:

they would still need to access network resources.

...bridge network on the VMs. ;)

Don

[mm2270]

I also work in an environment with lots of developers and I'd agree with alexjdale on this. To lock developers down as standard users, even with playing with /etc/authorization.db, would be a disaster. The fact is, developers really need mostly unfettered access to an OS. It could be virtual like Don and Rich mention, but if you can't do that, then I feel for you. This is going to be painful to get right. I think you'll be playing a game of whack-a-mole as you may need to keep editing the authorization.db to add rights in as they discover things they can't do to get their jobs done. Talk about a productivity killer. I guess your security team doesn't care that they'll be killing company productivity and increasing support costs?

What we essentially do is give them admin rights, but use whatever tools we can to lock down the necessary items. Its just a reverse approach - Give them everything, but lock down what you must as opposed to locking them down and granting them what you think they need. The latter is much harder to predict and get right.

I'd ask your security folks if they could do their own jobs as non admins and see what they think. I believe we all know the answer to that.

[evarona]

@Don: The network resources in question are corporate DBs and the Internet. Is there an OVA in the VMware marketplace for the Internet? ;-)

@Mike:

I think you'll be playing a game of whack-a-mole... Talk about a productivity killer.

Yeah, that's song is getting old as I've been singing it from day one. But the rest of your comment has me thinking if I can spin the reverse approach wheel and have Vanna turn the letters over for me... What if I create a new local group equivalent to Windows "Power Users" and grant it rights based on a subset of admin? I'm assuming that the new groups rights would be controlled from the authorization file, yes? That way I would only have to modify one group rights instead of this-and-that all through the system?

Does anyone have experience setting this up? I'm already seriously behind schedule. It's either this or we look at a third party tool like Quest's QAS (http://www.quest.com/authentication-services/).

[talkingmoose · Accepted solution]

Part of managing security is knowing what can't be managed and documenting those risks.

I hate the idea of giving developers admin privileges when they say they need them to do their jobs. Mostly, they want admin privileges to install development software. If this is the only reason they're requesting these privileges then they're no different from any other user. Licensed developer applications should be tracked and managed just like Adobe CS or Microsoft Office. That's for an IT administrator to handle. If developers need faster than normal response times then put those in place.

Rarely have I ever seen them mucking around in the hidden areas of a Mac like the /etc/hosts file or /usr/bin but assuming they do you can choose to open these off-limits places as you discover them or you can decide "they really do need administrator privileges" because they're digging into system areas to do their jobs.

Lots of folks think laws like the Sarbanes-Oxley Act are all about how IT should lock down computers when they're really about documenting your security and performing regular audits. If can't lock down a machine THAT'S OK. You just need to be responsible for documenting these as security risk areas and then auditing these areas on a routine schedule to ensure you still need these exceptions in place. That should be good enough for your security group. If it's not then the folks in that group don't understand their jobs.

[donmontalvo]

To add to @talkingmoose's points, would it be possible in your case to build an entirely sandboxed staging environment for the developers, one that does not touch the corporate LAN.

[franton · Accepted solution]

Surprised nobody mentioned executing the following commands as root:

DevToolsSecurity -enable
dscl . append /Groups/_developer GroupMembership

That theoretically should be enough for Xcode.

[PeterClarke]

If these are true Developers, then the no admin right policy is frankly daft.

However, I faced a similar problem dealing with Student's at Uni, needing to run Xcode,
-- and we didn't want to give them admin rights.

I solved the problem like this: running this script from a loginhook script

In the login hook script I added the line: Allow_Developer_Tools_if_Available.sh $UserID

And here is that script:

BUT you will note though, that Under OS X 10.8, xcode is NOW located in /Applications
and NOT in /Developer/xcode - so I've just updated the script to support that now too.
(ie supports OS X 10.6.8 and later) (We are just in the process of deploying OS X 10.8 to Labs)

I would be interested to know if this does NOT solve some developer issues.
-- The script, it though ONLY aimed at supporting Xcode and Apple developer tools.

So if users need to install other tools, and unix utilities etc - which is VERY likely..
Then they would still need admin rights, -- Or those other issues would still need to be dealt with separately.

#!/bin/bash
# Program: Allow_Developer_Tools_if_Available.sh
# By: Peter Clarke

# Vn 2: 2013-07-13 # Xcode test modified to support relocated xcode in OSX 10.8.x
# Vn 1: Wed 8th Sept 2010 # Original working Vn
# --------------------------------------------------------------------------------------------------
# Resolves issue of being able to run Compile from Developer Tools from a non-admin account
#
# Otherwise the following message appears:
# "Type the name and password of a user in the 'Developer Tools' group
# to allow Developer Tools Access to make changes"
#
# This is due to developer tools asking for rights to "system.privilege.taskport.debug"
# from the application gdb-i386-apple-darwin.
#
# The Solution is to add THIS User to the LOCAL Group '_developer'
# But dont apply if Xcode is not installed...
# --------------------------------------------------------------------------------------------------
#
echo "Program: Allow_Developer_Tools_if_Available.sh"
echo

UserID=$1

if [[ -d /Applications/xcode.app ]] || [[ -d /Developer/Applications/Xcode.app ]]; then

sudo dscl . append /Groups/_developer GroupMembership $UserID
fi

exit

[PeterClarke]

Actually, I have NOT yet re-qualified this for OS X 10.8

I just noted, in my comments it says: # This is due to developer tools asking for rights to "system.privilege.taskport.debug"
# from the application gdb-i386-apple-darwin.

However LATER versions of Xcode, no longer use gdb,
the newest version of Xcode are now using LLVM

So I am going to have to look at this again, and do further checks.
But while gdb is no longer used, the "Solution" to add the user to the developer group, should still apply.

[evarona]

Thanks all for the feedback. The thing is that I'm tasked to develop an OSX platform for our dev teams without them having local admin rights. Some platforms make this easier than others and I'm just trying to navigate doing this on OSX. I'll add that Apple doesn't make it exactly easy, but that's another topic for another time.

@talkingmoose: You're right in saying that s/w installation is a primary factor. We're addressing this with Self Service as the only AppStore option. But other issues involve those "hidden areas" like modifying the hosts file or changing proxy settings (to redirect a hard-coded server from prod to dev or even to a local instance), restarting daemons (Tomcat or MySQL) and a few other items. Since I've been able to make this work from Terminal by modifying sudoers, that might have to be the way to go. I'd just better not hear from any girly-man coders that want to do it from the GUI or I'll go Hans & Franz on them!) And I couldn't agree more that for every control, there may need to be an exception process and auditing; we have all those processes in place. The thing is that no one is willing to sign off on the risks for these developers, even if it has an impact to the business (or me). I love my job, I love my job...

@donmontalvo: Believe me, isolated VMs was my first suggestion and I'd love to make that work. At this point, I have to go back to the dev teams and get more specific reasons why this won't. I thought it had to do with Internet connectivity, hence my wise-crack about the Internet as an OVA.

@franton: Thanks, that might solve at least the Xcode issues. I'll give it a try and post back. I'm assuming I can run this in a post-flight script, yes?

@PeterClarke: for what it's worth, we have a script that adds console users to the Developer Tools at logon. You still get prompted when you build your first project and at least once more.

[Andrina]

We took a slightly different approach and use a Self Service policy to make the user an admin user for a temporary amount of time (dseditgroup with a launchd timer to undo after a set amount of time). I wrote out a dummy receipt that I use in a smart group to notify of when a user has used the policy, I've also written a web form that opens in the users default browser for them to notify us as to why they are requiring admin at that point in time. I've set it up for laptop users to have access to at all times while desktop users only have the policy available to them in Self Service outside of regular help-desk hours. We found there were a few more instances where admin access was rightfully required than just for our developers, so this killed a few birds with one stone.

[tlarkin]

Hey Everyone,

A long time ago, I did something similar with a customer. They needed local admin access, but only on a once-in-a-while basis. I ended up making a Self Service policy that detected the current user, and created a new user with the ".admin" suffix, then I just dumped the shadowhash of that user into the new ".admin" account. A launchd item was deployed that would delete that account after a certain amount of time. That way, the user used their same exact password, and all they had to do was put ".admin" after their user name. So, for example, I would run the policy in Self Service, it would create an account named "tlarkin.admin" and then dump tlarkin's shadowhash to the ".admin" account so I could use the same password. Then laucnhd would load and run every 60 to 120 minutes and then run a policy that removed that account (manual trigger policy). This way I never actually touched their user account and if anything went wrong and it deleted their .admin account no data was lost. This was back in 10.6, and I know in 10.7/8 the shadowhash has been relocated to a plist file in a different location.

This of course is the hard way to do it, and I would always ask people to reevaluate why they cannot give users admin rights that need them. I figured I would just toss that work flow out here since I worked on that and we did eventually get it to work a long time ago.

Thanks,
Tom

[evarona]

All,
Wanted to thank everyone again for your input and share how I solved this, at least for Xcode.

When packaging Xcode with Composer, I used chmod to change group ownership of the Xcode.app folder to "_developer". But even though we included the Libraries and iOS emulators in the package, neither of these two items showed as installed in Xcode preferences. We fixed both by making the following change in /etc/authorization

# Changed from system default of "root-or-entitled-admin-or-authenticate-admin" to "is-developer". 
/usr/libexec/PlistBuddy -c 'set rights:system.install.apple-software:rule is-developer' /etc/authorization

We also made some changes to /etc/sudoers to allow the _developers group to run specific utilities with sudo, specifically DevToolsSecurity and Xcode itself.

Side note: it appears that the sudoers file processes RunAs rights sequentially and not cumulatively. If you specify rights in this order, ```
%admin ALL=(ALL) ALL
%_developer ALL= NOEXEC: /bin/
``` then members of the admin group will not be allowed to run items in /bin. Reverse the order and it works. Go figure.

I'm sure some of you are thinking that this defeats the purpose of removing admin rights. I prefer to look at this as "reaching a compromise" between security demands and productivity. Maybe it's slightly Machiavellian but it gets me past this hurdle. Interestingly, most of the Unix admins I spoke with (non OSX) agree with @talkingmoose that developers don't need local admin rights by default. Of course, the challenge is making this work. (Hey, it pays the bills!)

@Andrina and @tlarkin: Interesting approaches. I'd like to learn more about how you implemented these solutions, if you don't mind PM'ing me the specifics on LinkedIn. Thanks.

[Bartoo]

@Andrina and @tlarkin: the solutions you presented with the temp admin + the web form would work really well for us technically, legally and "ergonomically" as far as our devs are concerned - If you would be so kind as to share more details I would greatly appreciate the info-

steve.bartoo@macys.com

Thanks again!

[Sean_Ginn]

Has anyone done this using AD authentication. We have an ISD environment and allowing students access with admin privileges is not an option. I am feverishly trying to come up with a solution to allow students access to developer tools without allowing them full access. I have done the following and had success by adding users one at a time, but was wondering if there is a way to do this by creating a group with AD and using this for it's authentication.

"DevToolsSecurity -enable
dscl . append /Groups/_developer GroupMembership"

[gregneagle]

dseditgroup -o edit -a everyone -t group _developer

Adds everyone to the _developer group on that machine.

dseditgroup -o edit -d everyone -t group _developer

Removes the "everyone" group from the _developer group.

-Greg

[lashomb]

For our web developers, we just use sudo. I am getting Casper next week, but I've used puppet to manage sudoers, permissions to things like conf files and hosts, call homebrew to compile php or php extensions like memcache, etc.

I add them to the developers group so that Xcode is happy and give that group access to run apachectl, coldfusion, php, catalina etc. For more complex things, we have some in-house apps that also get added.

These users are AD users, haven't seen that matter for us.

This may be simplistic or "too command line" for some peoples needs, but for us, developers don't have the same fear of Terminal that normal users have, so they are usually in there testing a database connection or debugging Apache with httpd anyway.

Here's a simple sudoers example of allowing the developers group to run Apache without being prompted for an admin password. If they end up needing something else, say Tomcat, I would install it with homebrew and add the path to catalina to the Cmnd Alias and ensure permissions using puppet (or a Casper policy).

# Cmnd alias specification
Cmnd_Alias DEVELOPER = /usr/sbin/apachectl, /usr/sbin/httpd

# User privilege specification
root ALL=(ALL) ALL
%admin ALL=(ALL) ALL
%_developer ALL = (root) NOPASSWD: DEVELOPER

[jimmy-swings]

Hi @evarona,
Have you been able to resolve your issue? We have a similar requirement and would like developer's to download Xcode from the app store and execute as a standard user. Currently a user is requested to enter a admin user when first launching Xcode...
Thanks, James.

[evarona]

@james.stracey So here's the funny thing: This project (as well as my manager's schizophrenic and sociopathic behavior) was a contributing factor in my choosing to leave that company. So while I'm now doing DevOps work on AWS, I still keep in touch with the fellow that replaced me.

I never got to achieve the security's team goal of removing admin rights and I almost consider that a personal victory. But we did manage to get Xcode mostly working with the method I mentioned above. I had to download Xcode, package it and push it out but it did work. I think the last step included modifying /etc/sudoers to allow developers to update the command line tools. Keep in mind that this was Lion and Xcode 5.x. I can only hope for your sake that it's easier now.

So here's the ironic thing: I heard from my contact that they finally decided to pull back on removing admin rights as a requirement because it was too impactful. It delayed updates and deployments so much that it impacted business deliverables. The moral of the story? If you're asked to do something so inane and counterintuitive that it makes the job significantly harder than it needs to be, brush up your resume! ;-)