Do Your Developers Have Local Admin Rights? 605
Posted
by
CmdrTaco
from the that's-why-god-invented-sandboxes dept.
from the that's-why-god-invented-sandboxes dept.
plover writes "I work as a developer for a Very Large American Corporation. We are not an IT company, but have a large IT organization that does a lot of internal development. In my area, we do Windows development, which includes writing and maintaining code for various services and executables. A few years ago the Info Security group removed local administrator rights from most accounts and machines, but our area was granted exceptions for developers. My question is: do other developers in other large companies have local admin rights to their development environment? If not, how do you handle tasks like debugging, testing installations, or installing updated development tools that aren't a part of the standard corporate workstation?"
Local Admin (Score:1, Interesting)
In previous places I have worked, the developers did not have local admin privileges on the machines on the network. We used virtual machines and test boxes that are disassociated from the network for testing and debugging, and the developers had full permissions for those machines.
Yes (Score:4, Interesting)
We maintain a development network and a QA network. The dev and QA teams have admin on the server machines in these networks. This is useful/necessary because we are constantly spinning up and tearing down virtual machines for various scenarios. Devs have local admin on their workstations. In general this has worked fine, except for one moron who used the privilege to turn off her virus scanning.
Production is subject to more structured control in theory, but in practice, I and another couple of guys have /sudo/root on the prod machines, because our corporate admins don't want to learn enough about the software to be useful. So much for PCI...
Re:You damn well should (Score:3, Interesting)
I would disagree -- the more years I spend programming the less I remember about system administration. I can do basic setup tasks, but fiddling with Active Directories and stuff like that is beyond what I care to learn and has been for what, a decade now?
At an Ancient Telecom company most folks don't have admin rights (and shouldn't) but there is an exception process developers follow, and otherwise the Company-approved packages don't need admin rights to install, plus the help desk has powers.
Virtualization is your Friend (Score:5, Interesting)
In modern times, I would give them no admin rights on the box itself, but you could provide virtual machines for them on which they can do whatever they want. The argument that they need to do things that "really, really" :-) require access to the bare metal, doesn't hold anymore, because the applications they are building will anyway need to be able to run in a virtualized environment.
I've done many audits and project plans on this topic in the past, and the issue is always that developers are split personalities: on the one hand they are standard corporate citizens that need email, calendar and word, which must be rock solid and therefore IT controlled, on the other hand they do their development work that requires freedom over their box. In the past the best solution was always to give them two PCs (or a thin client for the standard desktop work), but today I would solve this all through virtual machines.
I'm of two minds (Score:3, Interesting)
On one hand, yeah, of course developers should have admin rights on the machine (i.e. local).
On the other hand, I think Windows developers should have to operate as non-admin users as much as possible so that they will realize their software won't work properly when run as a limited user. It's a perennial problem with Windows software, although it is getting better.
So, yes, they should have access to it, but discourage its use except when necessary. No running as admin all the time.
It's Target. (Score:5, Interesting)
I'm going to end some mystery here: I am guessing the "very large corporation" is Target, a massive US-retail chain. I only know because I used to work on support there, and they tried this crap with trying to delete local admin rights for everyone so nobody could administer their own boxes. Even Microsoft told them this was a bad idea, and you can't remove local admin from a system because it's fundamental to the security model. It was so painful watching the daily e-mails come back from amongst IT and then once every week or two see a management e-mail so loaded in buzzwords I printed it off and hung it on my cube wall next to a train wreck picture and left my coworkers to do the math. They went ahead and tried it anyway -- I've watched whole stores, departments, and even divisions just drop off the network because they rammed some security change through, didn't test it thoroughly -- and now some application is seriously wedged. The days and days of downtime are due to convincing infosecurity that there's a problem and then fixing it -- because they're autonomous to the rest of support and report directly to the board. Which means, no matter how bad they f*** up, it's your fault, not theirs, because they each think they're Agent Smith, saving the corporation from the disorder of computational devices. *face palm*
I feel your pain. I do.
The sad part is, this isn't just that corporation: It's most Fortune 500 companies. Management is so far removed from the IT process that the only input they get is from external sources: Trade magazines and consultants. This, of course, ends in tears. These are the kind of people that read that pen drives are the source of all evil on their network and if you just delete the USB mass storage driver from the system, your problem is solved. I don't know which trade magazine published this idea -- but when I find him, I'm going to end him. Again, not a problem specific to that company -- it's representative of what everyone finds in the field today.
Since corporations with this level of brain damage inevitably give developers underpowered systems, here's your solution: Cannibalize another system, make sure you've got a few extra GB of RAM, and install an virtual machine, then do all your development within that environment. Site licensing is a wonderful thing. Just don't ever join it to the domain and shuffle your test files in and out via a temporary share. Even better, find a standalone system and use that for development so corporate can have their ridiculous security on one system, and you have an unencumbered development platform to develop for and transfer completed work back to the main system.
It's stupid, and you should never have had to do it. But then, what about working for a large corporation is ever simple? So many people trying to ensure they're a crucial part of the business, so few who actually give a damn about it...
Re:You damn well should (Score:5, Interesting)
Any developer who can't competently administer his own machine is incompetent
As an IT person who has supported developers, that makes me think that I've only met... like... 2 competent developers ever. Almost every developer thought he could administer his own machine, but very few did a good job at it.
As I see it (and maybe this is BS, but I'm saying it anyway), part of the problem is an issue of mentality. Developers seem to want to think about what *should* happen. Like "Oh, well installing this *shouldn't* make a difference. Changing this setting *shouldn't* make a difference." As though computers all make sense and work the way they're supposed to. In my years of doing support, I've come to the opinion that this is a very bad support mindset. Computers almost need to be treated as magical boxes possessed by evil spirits which might stop working if you anger the computer gods.
And I know, if you're a developer that probably sounds utterly silly and you think I'm a bad support guy. But you see, that's my whole point. Developers tend to have a different mindset. Computer stuff breaks all the time for no reason. Hard drives die, motherboards get fried, and monitors burn out. Sometimes enabling a setting will break your computer in some completely unrelated way. Yeah, yeah, there's a valid scientific reason. If I had access to the source code and I was a master programmer and I had all the time in the world, I could probably figure out exactly what was going on and fix it for real. But for my purposes, I just need the thing to work right now so my user can get back to work. For my purposes, for right now, it's good enough to assume that enabling the setting upsets evil spirits and angers the computer gods. It means "leave that setting alone."
It seems like every developer/administrator I've met wants to ague with that. They want to say, "But that setting *shouldn't* make a difference. Computers only do what they're programmed to do, so I just have to reprogram it right now." All that may be true, but as the support guy, you don't always have time like that. Sometimes you just have to blame the computer gods and move on.
Local admin rights? (Score:3, Interesting)
Why not simply work on virtual machines? Then you know they are clean and you can have all the rights you want and still have comply with company rules.
In a lot of environments, setting up a good seperation is simply to costly in time, so you either end up with dev's with not enough rights to do their job or to many where they can endanger systems they shouldn't.
So it should not be needed to have local admin rights, but then the sysadmins got a hell of a job to setup everything so that it is not needed. Most sysadmins simply ain't capable of that, or if they are, are not given the time.
Development machines are not mission critical (Score:5, Interesting)
You should treat your development machines as "hostile" and put them on their own network.
You should do this regardless of security issues because developers can also do stuff like saturate your network.
And what a great administrator, bashing people over the head because of your own limitations.
I'm glad you don't administer my development systems.
Worked in Both Worlds... (Score:4, Interesting)
In order for it to work smoothly, an exact development copy of the production server is required. This is pretty resource intensive in both servers and admins. Second, the deployment of new applications needs to be communicated to the administrators. This took some time depending on the difficulty of the change. Finally, any issues that popped up in the production server that wasn't seen in the development server required "emergency admin access". It usually meant that a server admin and developer sitting at the same terminal working out an issue.
This method, while not being efficient, forced a couple of best practices. First, because development had to be done a replica of the server, the code was already tested on a server that was identical(as possible) to the original server. Second, because the deployment had to be done by server admins, the developer had to document all the steps required to deploy their application. It let the admins know the changes being made, allowed auditors to see the change, and forced the developer to make an application that was reasonably easy to deploy.
Overall, I think it lead to a pretty clean production environment with much fewer "surprises". However, any code you want to put into production takes twice as long and cost twice as much (approximately). To truly evaluate if it monetarily makes sense, the cost of a failure/fraud in a production environment needs to be calculated. I don't think it is always better one way or another. Although, as a developer it sure was a pain in the ass.
admin rights define corporate culture (Score:2, Interesting)
I've worked in a variety of situations ranging from developers having root access to all workstations and production servers to having no admin rights on the workstation at all. There's a definite connection between developer's admin privileges and overall corporate culture. The less permissive the workstation environment is for the developer, the less creativity and innovation flows from the organization. I've especially seen this in banks where you're not allowed to install any software without a security officer's blessing. Contrast this with my current company, where each developer is fully responsible for maintaining their machine.
By depending on each other to understand the OS and learn the best tips and tricks for choosing which tools to use, every developer becomes capable of troubleshooting issues on the production machines. As a result, we takes just one operations / sysadmin person to manage the systems for a 20 person company. Of course, granting that level of permission requires a high level of trust that is often earned over time.
Re:You damn well should (Score:3, Interesting)
There's really two different issues. Reboot (or do anything to) a production server? Change ticket with approvals. Although in the best case developers should have no access to production. Updates should be packaged and passed off to a deployment team. (After QA and testing of course.) Reboots are handled by the infrastructure team managing the servers.
But for my personal workstation and sandbox servers outside of the formal path of changes from test to prod? If I needed any sort of approvals to make changes in those systems, I'd never get anything done.
Re:You damn well should (Score:3, Interesting)
As a developer, the only things I pester IT support for are things that I literally cannot influence, like permissions on servers I don't administer, poking holes through the firewall, etc.
Developers probably get into worse scrapes than the average user. Recently I had to have my Master Boot Record restored by IT support because policy forces us to use a full-disk encryption product that has a custom MBR. The average user would not have been booting Linux from an external drive and would not have run a badly-designed update that hosed the MBR on the main system disk instead of the disk the OS booted from.
On the other hand, the amount of time I've saved IT support by advising users, fixing my own problems, and fixing things they just plain broke in the first place, more than makes up for the odd difficult support incident I cause. Hell, I like to think dealing with my problems is a break from the old routine of "Uh, yeah, I forgot my password."
I think a certain proportion of the bad reputation they get is having to enforce the bone-headed policy that the upper echelons think up. But a certain proportion is due to them hiring part-time graduate chair-warmers to man the lines and provide a human interface to the "support script".
Re: Unauthorized Production Changes (Score:3, Interesting)
If your devs had access to make changes to the production servers, then the failure was not with them -- the failure was on the system administrator.
As a developer, I try to have *no* access to any production system. If you're connected to the prod database server to, say, look something up for a customer (which shouldn't happen -- you should have tools for this -- but it does), it's far too easy to forget that you're connected to prod when you go back to dev-related tasks and accidentally wipe out a table.
I hate having to be extra-careful to make sure that I'm not in prod. I'd much rather just know that I have no access to production so that I couldn't make changes, intentional or otherwise, at all.
--Jeremy
Re:You damn well should (Score:3, Interesting)
As a developer I totally disagree with your mindset, but I love the conclusion. Don't waste time on problems you don't have time to solve.
Btw. I think many young developers share your viewpoint: At the university I tought kernel programming. The rack that contained the test machines, was over the years slowly transformed by the students to a shrine for the Alpha gods (they were Alpha PCs). The students for many years had to walk up to the rack to reset a machine if they had fucked the machine up beyond remote control, and when they did they left sacrifices to the Alpha gods, in hope their next kernel wouldn't FUBAR nearly as bad. Still it was their assignment, they had to figure out what went wrong sooner or later, but sacrifices was the first step.
Been there, never going back... (Score:2, Interesting)
With these bozos calling the shots, it took less than a year to turn a world-class development shop into a ghost town.
Like it or not IT pals, developers have to do things on their boxes that normal users should not be able to. If you try and prevent them you will force them to come up with even more dangerous workarounds (tunnels to home boxes, dark nets, etc). If you're worried about security isolate their network, but don't make it impossible to do their jobs.
Re:Worked in Both Worlds... (Score:1, Interesting)
I work in a similar environment. We dont really have a choice regarding the way of doing things.
While we have full admin access to the production system getting to it requires a helicopter trip to the oil rig, a trip to the server room, and a permit from the owner ;)
Right now we use a system of vmware virtual servers for most testing on system functionality with exceptions on the "safety" parts which require testing on identical hardware (down to the bios revision of each network adapter.. anal but needed).
I personally like it that way. I've made some fuckups and had they been done on the real system I could have caused a multi-million dollar shutdown. I really dont want to do that for obvous reasons :-p
Most of the software developed require admin rights to even start... so all workstations have local admin unless you ask for a lesser account or make one yourself (some manageres prefer it).
I dont find the system a pain in the ass. The IT Security people though..... god I hate them. "Firefox is classified as dangerous software due to it being open source. All open source software is by definition not secure due to the open nature of the product. We will not validate any form of open software for use in ***** due to the lack of accountability and control." (not quite the wording, but yeah.... kill me/them now?)
*goes back to being grumpy*