Should developers have administrator permissions on their PC or is giving them power user access sufficient?
Some comments:
If they want to try out some new
application that would need
installing, then they could try it on
a virtual machine and later get the
network administrator to install it
for them. Do you think that would
work?
Is there anything that a developer
needs to do on their PC that would
require administrator permissions?
We are team of 5 developers and build web applications
The answer is 'Yes'. Developers will need to frig with system configurations to test items, install software (if nothing else, to test the installation process of whatever they happen to be developing), poke about the registry and run software that will not work properly without admin privileges (just to list a few items). There are a host of other tasks integral to development work that require administration privileges to do.
Bearing in mind that development staff do not necessarily have root access to production systems, admin rights on a local PC does not significantly compromise security of production systems. There is almost no legitimate operational reason for restricting admin access to local PCs for staff that need it to do their job.
However, the most important reason to provide administrative access is that setting up a compromised or second rate development environment sends a message to your development staff:
'We value your work so little that we
are prepared to significantly
compromise your ability to do your job
for no good reason. In fact, we are
quite happy to do this to cover our own
arse, pander to the whims of
petty bureaucracy or
because we simply can't be bothered.
That's just the best case. The worst
case is that we're really the
type of control freaks that view it as
our perogative to tell you how to
do your job and what you do or don't
need to do it. Make do with what
you're given and be grateful
that you've got a job at all.'
Generally, providing a second-rate (let alone fundamentally flawed) work environment for development staff is a recipe for the natural consequences of pissing off your staff - inability to retain competent people, high staff turnover, poor morale and poor quality delivery. Going out of your way to do so - particularly if there's an overtone of pandering to bureaucratic whim - is just irresponsible.
Bear in mind that your staff turnover doesn't just incur costs of replacing the staff. The most serious cost of staff turnover is that most of the ones that stick around will be the deadwood that can't get a better job. Over time this degrades the capabilities of the departments affected. If your industry is sufficiently close you can also find yourself getting a reputation.
One point to note is that administrative privileges are far less of an issue for development on unix-oid or mainframe systems than it is on Windows. On these platforms a user can do far more in their own domain without needing system-wide permissions. You will probably still want root or sudo access for developers, but not having this will get underfoot much less often. This flexibility is a significant but lesser known reason for the continuing popularity of unix-derived operating systems in Computer Science schools.
Developers should have full and total control of the machine they are using. Most debugging tools require admin permissions in order to hook into the runtime of the application they are building.
Further, devs frequently download and try new things. Adding additional steps such as needing a network admin to come by and install something for them simply frustrates the dev and will quickly make life hell for the network ops person.
That said, they should be an admin on THEIR box, not the network.
Yes and no.
Yes, it saves lots of time bothering system support.
No, your users don't have it so don't count on it.
We develop with admin permissions and test without. Which works out right.
Local admin yes, for all of the reasons stated above. Network admin no, because they will inevitably be drawn into network administration tasks because "they can". Devs should be developing. Network administration is an entirely different job.
Developers normally need to do things that the average person wouldn't, and so should normally have administrator accounts. Making them hop through awkward hoops wastes their time and demoralizes them. There may be exceptions in high-security situations, but if you can't trust somebody with an admin account you sure can't trust their code.
They should also have an available account of the same permission as their users (more than one account if the pool of users has different permission statuses). Otherwise, they may just develop something cool, deploy it, and then find it won't work for the users.
There are also too many ways to screw up computers with admin accounts (yes, I've done it). The IT department needs a policy that they will re-image a developer's computer if they can't fix it quickly. At one place I contracted at, I had to sign a copy of that policy to get my admin account.
This is a pretty Windows-specific answer. In Linux and other Unix-y systems, developers can more often get by with user accounts only, often don't need another account for test (if they've got an account they can sudo with, they do know when they're using the sudo, but they may need one with the same group permissions), and can do incredible amounts of damage to the OS very easily, so the same IT policy is necessary.
Having endured the pain of having to develop without admin rights on the machine my answer can only be yes, it's essential.
Yes, Half-Life 1 (and all the related mods: counter-strike, day of defeat, etc.) need administrator rights (at least for the 1st run, I think) to work properly in Windows NT, 2000, XP, etc.
And, what kind of developer doesn't play Counter Strike at lunch time? (a crappy one for sure)
Absolutely! How else would I install the download manager to download movies at night?
Sometimes developers really need to install things or change something in the system to test out some idea. It will be impossible if you have to call the admin each time you need to change something.
I also have my personal observation that some admins tend to screw tight all that is possible in order to make even little things depend on them on a daily basis thus... what, securing their job? pissing off the other users? Have no answer. But common sense is not seen here.
Last time there was a problem with my PC I took an active part in restoring the system, making some suggestions working in the team with the admin, or so i thought... Admin turned to be very angry and accused me of trying to teach him or redefine the rules. I suppose it was just his ego as he was not seen that cool in our room among other colleagues.
The answer is, developers should have 2 machines!!
One development one that has admin rights and sufficient power, memory, screen size, and portability, and ADMIN privileges, with corporate antivirus software loaded but configurable by developer when required with autoreset policy..
One corporate one that has corporate load, policies, non-admin user privileges, etc... Developer can use this one for unit testing release mode applications as some developers have the nasty habit of doing all unit testing with administrator privileges.
If you invert the question I think it becomes easier to answer; should we remove administrator permissions from developers? What is the gain?
But actually, I think the answer depends on your context, your environment. Small startup will have a different answer to ISO-certified government agency.
Yes, but they need to be aware of the limitations that their users will face when running software in a more limited environment. Developers should have easy access to "typical" environments with limited resources and permissions. In the past I have incorporated deploying builds to one of these "typical" systems (often a VM on my own workstation) as part of the build process, so that I could always get a quick feel for how the software worked on an end-user's machine.
Programmers also have a responsibility to know the hard-and-fast rules of writing software for non-admin users. They should know exactly which system resources they are always allowed (or forbidden) to access. They should know the APIs that are used to acquire these resources.
"It works on my machine" is never an excuse!
As a systems admin I'm all for developers having local admin rights on their workstations. When possible, it's not a bad idea to do most things with a standard 'user' level account and then use another 'admin' account to make changes, install apps etc. Often you can sudo or runas to accomplish what you want without even logging out. It's also helpful to remind us of what security hurtles the end-users will have to jump through when releasing to production.
On a side note it's also advisable to have a [clean] system or VM(s) so that you can test things properly and not get into the "it looks/works fine on my system" scenario due to system tweaking.
No Power User
First of all, Power User is basically an administrator - so "limiting" a user to Power User does not provide any increase in security to the system - you might as well be administrator.
Log on interactively as a normal user
Second, of course a developer needs administrative access to their developer machine (and servers and second boxes and so on) but of course noone should interactively log on as administrator during normal development or testing. Use a normal user account for this and most applications.
You seriously do not want to run [insert any browser, plugin, IM, E-mail client and so on] as an administrator.
You don't normally log onto your Linux box as root either, even if you likely have root access when you need it.
Use a separate personal administrator account
Provide the developer with a separate personal administrator account to his/her machine (domain account preferably) that is also a valid administrator on other dev/test servers and boxes that person needs administrative access to.
Utilize "run as" and in Vista+ UAC to prompt or request prompt and enter the administrative credentials for tasks and processes only when needed. PKI with smartcards or similar can greatly reduce the strain in entering credentials often.
Everyone is happy (or? ;)
Then audit access. This way there's traceability, and an easy way to find out who is using the terminal services sessions on a particular dev/test server you have to access right now...
Granted, there's definitely development work that will never require local administrator privileges - like most web development where deployment is tested against a separate server or virtual machine and where cassini or whatever is used for local debugging actually runs well as a normal user.
[apologies english is not my mother tongue, doing my best :)]
Well,
Personal experience (I'm a c++/SQL dev):
I used to be admin of my windows machine in my previous job. I also had dbo ( not dba ) rights on databases, including production environment databases. In 2 and a half year with 8 people having these crazy high rights... we never had any trouble. Actually we solved a lot of problems by updating db manually. We could do many things really fast for hot fixes and devs.
Now I changed job. I managed ( crying a lot ) to be admin of my windows machine. But the dev server is a red hat server to which we connect using ssh. Trying to install Qt was a torture, Quota limits, space limits, execution and write rights. We finally gave up and asked the admin to do it for us. 2 weeks later still nothing is installed. I'm getting really fast at newspaper reading and alt+tab hitting.
I asked for admin rights, as only the dev of my soft use this machine.
--> Answer: "If there are processes its for you not to do whatever you want. It has to run fine once in prod".
--> Trying to explain to a non technical manager: "I shall have no admin rights whatsoever in production or UAT environments. But my dev machine is different. If I were to build chairs instead of softwares, would you tell me that I can't put whatever tools I want in my workshop because my workshop needs to look like the place the chair will be used ?
I give an executable package to uat. The libs and tools I used to build them are invisible to the end user or to the dude installing the package."
I'm still waiting today. I found a solution, open a dev environement, go to your favorite online judge, challenge yourself. when somebody look at your screen, he'll be seing you programming. ;)
I work primarily in the *nix world and the standard model there is for developers to work in a normal, non-privileged user account with the ability (via sudo or su) to escalate to admin privileges as/when necessary.
I'm not sure what the equivalent Windows arrangement would be, but this is, in my experience, the ideal setup:
On the one hand, having admin rights available on demand gives the developer full power over his workstation when needed.
On the other, Windows software has a long, long history of assuming that all users have admin rights, to the point that many programs won't run for a non-admin user. Many of Windows' security issues stem directly from this implicit requirement that, in order to be able to reliably use the computer, all users must be admins. This must change and the most effective way to ensure that your software will run for non-admin users is for your developers to be running it themselves as non-admin users.
You can answer this in two ways. Yes and no, or it depends. -- Can I be more vague....
It depends if it is required for them to do their job. If it is then grant them administrative powers over their computer. If not then don't. Not all software development requires an engineer to have admin rights.
Yes and no depends on your view. Some engineers view their computer as their domain and they are the rules of their domain. Others don't want the responsibility.
I have worked at one company where I did not have admin rights and whenever I needed to do something that required admin rights I had to call the help desk and they granted me temp admin rights until I rebooted. This was a pain at times, but that was the way it was so I lived with it. I have also worked at places that I have full admin rights to my computer. This was great except for the time I installed some software that hosed the OS and had to take my computer to the help desk and have them re-image the hard drive....
I personally feel that an engineer should have admin rights to their computer, but with the understanding that if they screw it up then a new baseline image can be reloaded and they will lose anything that was done since the original baseline. I don't believe that everyone in a company should have admin rights to their computer however. Accounting, administrative assistants, and other departments don't really have a need to have those rights so they should not be granted.
https://msdn.microsoft.com/en-us/library/aa302367.aspx
In my experience, a compromise between us (coders) and them (security) is always needed. I admit (though I hate to), there is merit in the Microsoft article above. As I have been a programmer for years, I have experienced the pain where I needed to just install a different debugger, just to get annoyed I can't. It forced me to think creatively in how to get my job done. After years of battling our security team (and several discussions), I understand their job of having to secure all areas, including my desktop. They showed me the daily vulnerabilities that come out, even on the simplest Quicktime app. I can see their frutration everytime I want to install a quick utility or tweak my local IIS that I can cause a serious security problem. I didn't fully understand this until I saw another developer get canned. He was trying to debug and ended up shutting off Symantec only to get (and then GIVE) some virus to hundreds of people. It was a mess. In talking to the one of the "secheads" (security guys) about what happened, I could see he wanted to just say, "told you so...".
I have learned that our secheads (well, at least mine) just want to protect our company. The good news is we did find a compromise, and I can get my job done and the secheads are cool with our secure network!
Creed
Yes if you want the pentesters or some skilled malicious users to get a foothold on compromising your domain.
i.e Compromise low level account > Find where admin -> Mimikatz -> Elevate permissions -> Domain admin.
So no, normal users should not be admins.
Also Microsoft have said UAC is not a security boundary, so don't use it as such. There are various real world bypasses of UAC available.
If they need admin as part of their job role then give out separate domain local admin user accounts used for installing software only (with admin permissions on their own machine only), never for general usage or internet access. This should have a more stringent password policy (eg 15 chars minimum length). Runas functionality should be used for this.
Any environment where normal user accounts are admin is a recipe for a security disaster.
Wow, this question is certainly going to open up to some interesting answers. In reply I quote the oft used - 'It Depends' :)
In small companies this might just be simply a matter of being pragmatic. The developers are also likely to be the most technically adept, so it makes sense for them to adminster their own machines.
Personally, I'm a fan of the "admin account" which can be used when necessary - i.e. "Run As.." (I noticed this approach was very similar in principal to UAC later on).
If you are developing desktop software it's not a bad idea for developers to work within the confines that their end user's will experience - i.e. limited or restricted rights. If you build the software under limited rights, it's a good chance that you'll hit the same problems your target users would face given the same set of permissions.
Having said that, if you have a good testing lab and/or a decent QA team this might be a moot point - especially if you have a half decent ALM practice.
So finally - I develop without UAC, mainly because I trust myself and my skills. In a team environment, I'd put it to a vote. In larger organizations you might not have this freedom.. The Enterprise Admins often have the final say :)
At my company, developers, engineers, and my boss (owner of the company) have local admin privilege. My boss also has network admin privilege, just in case I get hit by that wayward bus (or quit). Everyone else gets locked down.
As sysadmin, this setup has caused me a little grief from time to time, especially when unapproved software gets installed. However, coming from a developer background, I understand the need for power users to have more control over their environment and as such, am willing to put up with the occasional quirk or problem that may surface. I do perform routine backups of their workstations -- just in case.
By the way, I've had more problems with the boss tinkering around with things than with anyone else. Kind of like the old question, "Where does an elephant sit? Anywhere he wants!"
But in a small firm where he is essentially the "backup" sysadmin, there isn't much choice.
It depends on the developer skills and whether s/he is a consultant or not.
I think it's reasonable that a seasoned and trustworthy developer has the rights to do whatever s/he wants with her/his PC as long as it doesn't harm her/his productivity.
No one on Windows XP should be using an administrator account for day-to-day use, and in Vista if you must be an administrator at least have UAC enabled. Especially web developers and other developers who browse the web with Internet Explorer.
What you can do is have developers use their regular user account, but give them a second account that is an administrator on their PC so they can use it as needed (Run As). I know they said web development, but for Windows development your software should be tested using a regular user account, not as an administrator.
Related
I need to develope an ABAP program which does some actions for SAP Basis. This program will be run in test/development systems only and it's not safe to run the program in productive system.
I need any safe way how to prevent the program running in productive. I can read a category field in T000 table and check if the system is a productive or not, but this way is not 100% safe. Any user with debug/variable modification authorizations will be able to avoid this.
A possible solution is not import the ABAP program to productive system at all. At the same time we have a system copy from productive to QA (the Oracle DB is copied from PROD to QA completely and renamed). This means the new program will be erased in QA after each PROD->QA copy and we will need to import it from DEV to QA again. So, this way is not convinient.
Is there any way which is more safe?
There are very few safeguards against someone who maliciously uses the debugger to change values in a running program (and has the permissions to do so). If someone with that permission wants to actively harm your system, he/she/it will be able to do so one way or another.
Manage that risk through strict permissions management.
If that is not sufficient, do not transport the program, however inconvenient that may seem.
Still, you should guard against accidental execution, and for that, the role of the client (can be "productive", "customizing", "test"; via transaction code SCC4; it's stored in table column T000-CCCATEGORY and can be read via function module TR_SYS_PARAMS) should be sufficient.
Anyone with a developer/debug authorization basically can do everything in your system. I mean even you do not ship your program, I myself can create a z-program to make the same thing as your program do if I have a dev role.
so let's focus your statement here: Productive System. How many users can have the dev authorization? I think it should be strictly controlled by your Admin.
In addition to T000 "Productive" check, you can also add authority check, for example, S_ADMI_FCD and logging in your code to restrict and safe the program.
Hope it helps. Thank you!
The solution would be to call an operating system command which could be found only in the test/quality system and not on the productive system.
I have read several articles about creating a Sharepoint Developer VM. They all say to "sysprep" them. Why (exactly) must the sysprep be done? What kind of problems (and why) will we run into if we don't sysprep them?
(I suppose what I am asking is, what would be the difference in doing "sysprep" and just bringing up the VM, changing its Name/IP, reboot then install SP?)
I've had success in the past with just copying Hyper-V vhd's as a method of cloning VM's - however, I now use sysprep when cloning any of my machines as it's been mentioned as a best practice in many places. And, it does some nice things like allowing you to cleaning up a bunch of stuff that I don't want to duplicate and letting me choose a new name for the machine on boot. From MS Sysprep Technical Reference:
Sysprep prepares a computer for disk
imaging or delivery to a customer by
configuring the computer to create a
new computer security identifier (SID)
when the computer is restarted. In
addition, Sysprep cleans up user- and
computer-specific settings and data
that must not be copied to a
destination computer.
And you may want to read Russinovich's post on The Machine SID Duplication Myth (and Why Sysprep Matters) for more good explanation of how SIDs work and the very last paragraph has another reason for going this route:
Note that Sysprep resets other
machine-specific state that, if
duplicated, can cause problems for
certain applications like Windows
Server Update Services (WSUS), so
Microsoft’s support policy will still
require cloned systems to be made
unique with Sysprep.
Good luck!
(I am newbie to tortoise SVN)
I have 2 folders in my tortoise SVN.
Each need a different set of authorization
(I do not want
people who have access to the first folder to have read / write access to the second folder).
How can I accomplish it? I noticed that all permissions are defined in a file in the root level.
This is covered in the Subversion Book section on Path Based Authorization. You can check out the link for more details, but I would just draw your attention to this part:
A lot of administrators setting up Subversion for the first time tend to jump into path-based access control without giving it a lot of thought. The administrator usually knows which teams of people are working on which projects, so it's easy to jump in and grant certain teams access to certain directories and not others. It seems like a natural thing, and it appeases the administrator's desire to maintain tight control of the repository.
Note, though, that there are often invisible (and visible!) costs associated with this feature. In the visible category, the server needs to do a lot more work to ensure that the user has the right to read or write each specific path; in certain situations, there's very noticeable performance loss. In the invisible category, consider the culture you're creating. Most of the time, while certain users shouldn't be committing changes to certain parts of the repository, that social contract doesn't need to be technologically enforced. Teams can sometimes spontaneously collaborate with each other; someone may want to help someone else out by committing to an area she doesn't normally work on. By preventing this sort of thing at the server level, you're setting up barriers to unexpected collaboration. You're also creating a bunch of rules that need to be maintained as projects develop, new users are added, and so on. It's a bunch of extra work to maintain.
Just to round the post of codeka up. You can't set (at least I never have found out how) any permissions for the repo in tortoise as it is the SVN client application. You would have to set the permission on your svn server. If you happen to be running VisualSVN Server (free) you can setup user rights in a windows-easy manner (point and click).
I'm a fan of Trac, and of course when I'm just using it for my own, lone, projects I can just give myself full admin rights.
When there are other developers involved, or a not-very-technical manager (or, for that matter someone that is a designer rather than hard-code developer), that needs to be able to keep up with what is happening - and do things like add/update tickets, but not potentially break anything, then the fine-grained nature of the permissions gets to be a little more complicated as to what is required for someone.
What permissions do you use for those groups of people (and other similar ones)?
I generally avoid giving the *_ADMIN perms to users if I can avoid it. Trac 0.11 makes that a little easier by adding TICKET_EDIT_DESCRIPTION.
Depending on the setup and the culture, I'll grant the *_VIEW permissions to authenticated (everyone who has logged in) or in lax setups, anonymous (everyone, even not logged in).
I will generally create a developer group, grant the various permissions to that group. Then you just add people to the group (or add the group as a permission to the user, same thing). Do the same for designer, manager, tester, etc.
A manager would want the various ROADMAP_* and MILESTONE_* permissions. I'd be cautious about REPORT_ADMIN unless the manager actually knows SQL. My boss is generally happy to give me an example spreadsheet of the report he wants and I'll whip up a report for him. Be sure to point out to them that if they setup a custom query that does what they want, they can bookmark it -- everything is in the URL -- so they can go back to exactly that same query with current data using that bookmark.
You'd probably want to let authenticated file and append to tickets--doesn't usually who notices a bug, you still want to know about it. If you lock down the workflow permissions enough, you may be able to give out TICKET_MODIFY to more people as well, though that route will be a bit more work.
Those you have some trust in can probably be granted TICKET_EDIT_DESCRIPTION so they can fix up their bug report formatting when they forgot to to start with.
If you have a lead developer, that individual user should probably have TICKET_ADMIN to deal with adding versions and such.
I typically turn on all the VIEWs, plus WIKI_CREATE, WIKI_MODIFY, TICKET_CREATE (or TICKET_CREATE_SIMPLE if using the Simple Ticket plugin) and TICKET_APPEND.
For users I trust to have a little more power, I'll also turn on TICKET_MODIFY.
For a non-technical manager, I'll also turn on MILESTONE_ADMIN. For a technical manager, I'm likely to jump to TRAC_ADMIN -- but if that's too far, at least add REPORT_ADMIN.
Typically, I'll go ahead and give the developers TRAC_ADMIN... but if you don't trust them that far, the above permissions through the power user level plus TICKET_ADMIN are probably sufficient.
I'm working on creating a self updating application and one issue I'm running into on Vista and Windows 7 is needing to have admin privileges in order to update the client. I've run into issues with clients that have their users running under restricted permissions and they would have to have IT log onto every machine that needed to update the client since the users were not able to.
A possible work around I'm considering is to have the launcher application installed into Program Files as normal, and having the real application that it updates installed in the users documents somewhere, so that they could update and run new versions without IT becoming involved.
I'm wondering what potential gotchas I'm missing here or what I should be aware of before heading down this path. I'm aware that click-once does something very similar, and I'd be using it, except I need the ability to do silent updates, without any user interaction.
This is how it is supposed to be. The last thing most IT departments want is a user randomly updating a piece of software. This could have all sorts of unintentional side effects such as incompatibility with the older version's files, new and possibly insecure functionality, etc. This is why IT departments disable Windows Update and do their updates manually in a controlled fashion.
If the users want an updated version of the software they should be requesting it from their IT department. Those computers and infrastructure don't belong to them, they're simply borrowing time on them from the company they work for so they can do their job.
Is there an issue with having only one installation of your program? Is it particularly large, for example?
Do you require admin privileges to run your program?
If not, odds are you don't need the Program Files folder.
I suggest you forgo installing to Program Files entirely and just install your program into the user's folder system at <userfolder>\AppData\ProgramName.
If you happen to be using .NET, look into the ClickOnce deployment mechanism. It's got a great self-updating feature that'd probably make your life a lot easier.
Edit: Just saw your last sentence. ClickOnce can force the user to update.
A couple of things:
If you decide to move your app to some place in documents, make sure that your application writes data transparently to where your program is installed, e.g. if there are hard coded paths anywhere in the code that are pointing to bad places. Perhaps this is not an issue for you, but might be something to keep in mind.
We solved this in pretty much the same way when we decided to implement a "live update" feature. But instead we installed a service which is running with administrator rights. This service in turn can run installers once the program needs to be updated. With this type of solution you don't even have to move your applicaton out of program files.
Cheers !
Edit:
Another neat thing with having a service running as administrator. Is that you could create a named pipe communication with it and have it do things for you, like you wouldn't be able to do as a normal user.
A loader stub is a good way to go. The only gotcha is when you have to update the loader; the same initial problem applies (though that should be pretty infrequent).
One problem that I can think of off the top of my head is that you're stepping outside the entire idea of keeping things more "secure." Since your executable exists in a location that should be completely accessible to a non-administrator, it's possible that something else could slam your exe thus subverting security.
You can probably leverage AppLocker. It may only be for Win7 though I'm not running Vista any more. ;)