One of the great things about working at DevelopMentor is access to the internal mailing lists. Being able to send a message off to that particular group of smart people has helped me more than once.
As you might expect, instructors at DM are not just bright people, but highly opinionated. So in addition to just answering each other's questions on the internal lists, we also frequently ("continuously" might be more accurate, actually) debate the merits of issues both technological and social.
One recent debate revolved around whether or not developers should run as administrator. This is something that Keith Brown has been advocating. Since there's been a lot of public discussion around this issue lately on mailing lists and weblogs, I thought it would be interesting to post the discussion here, publicly, to both show people both sides of the argument and to give them a glimpse into the inside of DM.
The debate started when Brian Randell posted the following from the WinTech Off-Topic List:
I'd like to step up, incur the wrath of Keith Brown, and suggest that the whole idea of "devs running as non-admin" is just a cute trick, primarily for folks working on end-user apps... certainly not for folks doing web or database work.
Yes, I'm sure that if more devs ran as non-admin, more software would work better in that context. Dogfood is yummy.
But let's be realistic: even as a developer of end-user apps, there are perhaps a hundred things about my dev environment that are different than my target users' environment -- any one of which could mask a bug.
And that's all we're talking about. Bugs.
Develop as admin. Test as non-admin. Find bugs, and fix them. That's all there is to it. The productivity hit for an entire dev team running as non-admin is just not worth it... especially not for a team of ASP devs, who (by design) need admin rights to do their job, and who won't be directly executing code in their clients' session, anyway!
I'm not subscribed to that list, but feel free to forward this over there for me.
I agree that ASP.NET developers running as non-admin isn't going to directly fix the busted client app problem.
But that's not the only reason to do it.
For those that complain that it's too hard, or that it slows you down too much, might I suggest the reason it's so hard is that we keep ignoring the problem? If nobody is bitching at MS to make their multiuser features easier to use, things aren't going to get better. If nobody notices the plethora of apps that don't run without admin privs, we continue with the pathetic status quo.
I've decided personally to stop burying my head in the sand. And I've found that it's a hell of a lot easier than I thought it would be. It's often just a matter of changing some bad habits. And it often forces you to learn more about how Windows security works.
Security isn't a product. It's not a technology. It's not something you can buy or build. It's more than that - it's a process, an attitude.
Running as admin all the time says something about your stance on security.
I do not agree that writing secure software is the result of a proper attitude, nor do do I think that developing as a non-admin will result in more secure software. I can't even imagine going into client and saying "The first thing we should do is take those admin priv's away from your thirty or so developers, except for special occasions." The only difference I would expect after such a change is lower productivity, not more secure software.
Development tools for windows have never been targeted to run in a non-admin evironment. Most of the issues run into when working as a non-admin developer have to do with system configuration that constantly change and they have nothing to do with writing software or even good software for that matter. I'm sorry, but I see this as a knee-jerk, silver bullet reaction to a serious problem in software development.
Security is like any other feature of a program, it has to be defined, enumerated, implemented, reviewed and tested.
You can't say I am going to protect against all things. You have to pick those threats, events, whatever you want to call them and weight the probability of them happening against the cost of them happening. Then prioritize and protect. Just like you evaluate any other feature of a program.
The principle problem with security in software today is that it is not a feature that product managers will specify, i.e. detail what it means. It is also not a feature that purchasers of software will pay for, though that may be changing. Taking away developers admin priv's will not change this.
Yes, software must be tested in a non-admin environment (unless it is being designed to run in an admin environment). Yes there have to be programming standards.
And you will have to deal with the fact that probably none of the programmers in your department will have the competency level of Kieth. None of these things will be changed by taking away admin priv's from developers.
In fact I think the whole non-admin developer thing is bit of a red herring. Just because you don't have admin priv's doesn't mean you are running in a user environment. The typical developer system is configured in a wildly different way than a user system, and having admin priv's is only a very small part of the difference. So having a developer switch to a non-admin role to do personal unit testing is of value only because it is so easy to do, not because it is particularly effective.
Testing must be done. And it must be done on system configured from scatch (fdisk) to be a user system to be of value. Taking admin priv's away from developers will not change this.
No, security cannot be tested into a program but there are tons of issues that can easily be prevented by testing. The most common "security" issue I have seen in the past is the one that Keith ran into recently, the inablility of a program to read a register in a non-admin environment. This issue, and many, many others like it are trivial to find with even a bare-bones testing program.
I don't know of any studies, not that I would anyhow, that indicate that programmers working without admin priv's produce more secure code. Was Robert Morris Jr. successful because the people who wrote sendmail and fingerd slipped into root to often while they were developing them? Maybe they just weren't competent or had a bad attitude?
I am personally very leary of giving this sort of advice to people. First of all I just don't believe it. Secondly, having managed lots of developers in the past, I know first hand how much it is like hearding cats. And this is just an inviting blind alley for a cat to explore.
I can just imagine my reaction if I went up to a developer in my group at the end of a day to ask how their day went.
If they replied "I've lost a whole day, again, trying to get another developer tool to run in a non-admin environment. You know these tool deveopers just don't have the right attitude."
My response would be something like this "Why is this a problem and why are you trying to do it?" A response from the developer like "You know that big bucks Developmentor course you sent me to last month, they told us this is how you should develop software." would certainly get me to place a call to my Developmentor sales rep'.
just the thoughts of a programmer with a bad attitude,
I do not agree that writing secure software is the result of a proper attitude,
-1
A proper attitude is necessary but insufficient. That is, you will never develop secure software without the right attitude, regardless of how you acquire it.
Running as non-admin is neither necessary nor sufficient. However, it doesn't hurt, since it has a high probability of major attitude impact.
My response to this thread on the OT list was basically, "While I see little utility in continuing to run as non-admin, there was enomous utility in doing it at all."
Here's the deal: I already knew (small 'k') that apps need to pay attention to security and that one shouldn't write to the Program Files directory. But I didn't Know (big 'K') it. There's a huge difference. For me, the day that I "lost" getting stuff to run didn't represent a day of zero productivity - it represented a day of education, wherein I got so annoyed at how much broken, crappy software was out there that I internally vowed not to write that stuff myself.
Here's a metric: I'd say that the experience was far more valuable (in terms of motivating me to do things right) than spending the same day sitting through a seminar by Keith Brown. As illuminating as said seminar would be, it just isn't the same as getting pissed off.
Would you have a problem if the advice was, "You should try this for a week"? That would have 90% of the impact, IMO.
The people who should be running the software as non- admin's are product mangers, not developers. They are the ones who must feel the pain so they will put pain relieving features into the spec for the product. If specific security features are not part of the software requirements then no amount of attitude will make the software secure.
Windows development tools are not targeted at the non-admin environment. It is non-productive to try to re-purpose them to such an environment, not even for a week.
Yes, the developers should test their code, and if they can the product it goes into, in a non-admin environment and this is easy to do in win2k and xp. I never said otherwise. But they should not be trying to run their development tools in a non-admin environment,
You can't create secure software by requiring every developer on the team to be competent in security. Only a few maybe on a big project. Division of labor and competency in a problem space are what is required. There have to be software standards that everyone follows and reviews some general and some specific to the project. Like for C++ programmers "Don't process a string without first checking it's length." sort of thing.
It's not a matter of attitude, it is a matter of implementing the requirements of the software. Attitude will lead a programmer to delve into security issues, and other issues, that either are not likely in the software usage or not costly if they fail. That is why up front analysis of the threats and their costs and probabilty is important, so you don't spend time on the wrong things. This is not a problem that is to be solved by each programmer individually, it must be solved by the leaders of the project and implemented by everyone.
If every programmer was a clone of you and Keith then maybe developing as non-admin would be possible. (Of course there would be other societal issues if this was the case :)). But most programmers are not at your level and at best can apply a language to a couple of problem spaces they are familiar with. We see that in our students. Secure software development is going to have to have a process that takes this into account.
The people who should be running the software as non-admins are product mangers, not developers. They are the ones who must feel the pain so they will put pain relieving features into the spec for the product. If specific security features are not part of the software requirements then no amount of attitude will make the software secure.
And the fact of the matter is that it's not a one-way street. When developers are sitting in a meeting with product managers, and they all say, "Dude, we can't run our own software" that has an impact. Maybe one or two PMs will check it out and see what it means to run as non-admin. Maybe they'll tell their PM buddies.
We at DM influence the developer community. Not the PMs, although we should grab the limited opportunities we have to interact with them.
Windows development tools are not targeted at the non-admin environment. It is non-productive to try to re-purpose them to such an environment, not even for a week.
That's just wrong. I've been developing loads of software as non-admin for months now. It works great. Sure, VB5 or whatever didn't work great, but everything I need to do has worked. Do I have to kick off a session as admin once in a while? Sure. Is it hard? Not even remotely.
Yes, the developers should test their code, and if they can the product it goes into, in a non-admin environment and this is easy to do in win2k and xp. I never said otherwise. But they should not be trying to run their development tools in a non-admin environment,
Why? Because it's too hard? I don't necessarily buy it. Especially if more people were doing it. I've already got a page up on my site that says, "For these tools, these are the fixes that make them work." If you can't use Google, you shouldn't be writing software. And the more people do it, the easier it is to find the info. Not to mention that the more people do it, the better the software gets.
You can't create secure software by requiring every developer on the team to be competent in security. Only a few maybe on a big project. Division of labor and competency in a problem space are what is required. There have to be software standards that everyone follows and reviews some general and some specific to the project. Like for C++ programmers "Don't process a string without first checking it's length." sort of thing.
How about "don't build SQL by appending strings"? "Don't write to the filesystem in certain places"? These are both tasks that in some products will be part of every component. I'm not sure how you think that anyone can escape having to be aware of security issues if you goal is to build a secure product - something you clearly advocate.
It's not a matter of attitude, it is a matter of implementing the requirments of the software. Attitude will lead a programmer to delve into security issues, and other issues, that either are not likely in the softwares usage or not costly if they fail. That is why up front analysis of the threats and their costs and probabilty is important, so you don't spend time on the wrong things. This is not a problem that is to be solved by each programmer individually, it must be solved by the leaders of the project and implemented by everyone.
Amen brother. And how does change come about? By changing the culture - that is the only effective way. Mandate doesn't do it. Shared vision does.
If every programmer was a clone of you and Keith then maybe developing as non-admin would be possible. (Of course there would be other societal issues if this was the case :-)). But most programmers are not at your level and at best can apply a languge to a couple of problem spaces they are familiar with. We see that in our students. Secure software development is going to have to have a process that takes this into account.
I totally agree - especially about the societal issues. Plus, there'd be no women. :)
In any event, I still think you're missing the point. You keep saying that secure software comes from defining a threat model and working to design and test to meet the threats outlined by it. But I think that's only half the story. If you're not also creating a culture that cares about security, then you will fail because developers will meet the goals defined at that coarse grained level and miss all the fine-grainedones that actually cause the problems that we read about. "Oh - I didn't think it was a big deal to reuse that buffer."
Both things are necessary, neither is sufficient. Running as non-admin is one way to incrementally begin to chip away at the culture change required.
Good, we are getting down to the nub of things. Yes, even ordinary programers have to realize that security has an impact on how applications are developed. I totally agree with that.
Note that I didn't say developer tools won't work without admin priv's, I said that they were not targeted to work that way. More work without admin priv's now than used to, but I doubt that this is a goal for most dev products.
BTW when NT first came out I tried to implement the non- admin developer environment for myself. I thought, "Great, now I can work in an environment where I can't hurt myself!". Of course I couldn't get anything done either, almost nothing worked, and the stuff that did still broke things. I tried it couple of more times since then, but not in a long time, and came to the conclusion that it just was not worth the effort. So it may be my own past experiences that color my view.
I agree the average developer would be greatly illuminated by running their code and the product that uses it with no admin priv's. I agree that much would be gained by this.
But most would just be frustrated and diverted when a dev tool failed to work in a non admin environment. I just think that for the average developer running even for a week without admin priv's would not make them a better developer.
Another thing to try would be to run as a developer without admin priv's in a domain rather than a workgroup. This would be a more realistic setting for app's in a corp environment anyhow. This is just another facet of my assertion that admin priv's are only a small part of the difference between a user and a developer environment.
I would guess that the results would be the same, but at least this would mimic the environment that many, maybe most developer find themselves in. Maybe someone has already done this? But making a rec' to a developer without at least trying it out in a typical dev env doesn't seem like a good thing to do.
Just to add my 2 cents worth here.
I do most of my java development on Linux or Mac OS X these days. On those platforms I find that the stricter file permissions and user roles make it crystal clear when I occasionally need to temporarily assume root privilege. It is a pain in the ass sometimes, but it makes for a more secure software design. Running as non-root puts these issues right in your face.
It is kinda like the way the java compiler forces you to deal with exceptions (unlike C#). It is annoying sometimes, but it enforces a kind of discipline that makes for more robust programming.
But the tools you are using were probably targeted at running without root. This isn't the case for a lot of development tools for windows. Up until a not very long ago windows tools were targeted to run on win9x. priv's were was only an afterthought if any thought at all.
And what's the fix for that? To have loads of developers demanding that the tools work in their (nonadmin) environment.
In other words...cultural change. :)
Good, we are getting down to the nub of things. Yes, even ordinary programers have to realize that security has an impact on how applications are developed. I totally agree with that.
Cool. I figured you did. :)
So it may be my own past experiences that color my view.
Right - the tools used to totally blow on this account. We tried to implement it around 1997 at the company I was at, and it didn't fly.
I just think that for the average developer running even for a week without admin priv's would not make them a better developer.
That's not really the question, though. The question is: would it make them worse? If the answer is "no", then what you're saying is that some segment of the market would get better and the rest wouldn't change. Net increase.
Another thing to try would be to run as a developer without admin priv's in a domain rather than a workgroup. This would be a more realistic setting for app's in a corp environment anyhow. This is just another facet of my assertion that admin priv's are only a small part of the difference between a user and a developer environment.
Well, I think it's already overwhelmingly the case that devs run as non-domain admins. Don't you? They're local admins, but domain users.
And I ran my setup as a domain user on my tiny home domain. Worked fine. Admittedly, that's three computers not 200, but that's the problem with testing: you can never match production perfectly.
ok, I think I finally understand what my issue is with dev'ing as non-admin. In general we tell people what the primitives and they figure out how to put them together. This is advice on how to put things together. Under it all what I am worried about is that someone comes to a DM course, tries the style and gets their cohorts to join in. Then their dev manager gets wind of it and asks why they are wasting so much time and gets upset with DM for leading them on a futile path.
I do know of dev mangers who would be absolutely livid if this happened (not me!). Not that they are trogdalites, but actually very capable. This is a learning experience that takes time. In theory that time should have been spent in the class. It's just that most dev managers are under terrific pressure to get things done and some have a good idea on how to accomplish their tasks. They are very much in the camp of "And this helps us how?".
My response:
ok, I think I finally understand what my issue is with dev'ing as non-admin. In general we tell people what the primitives and they figure out how to put them together.
In general this may be true, but there have been dozens of times and whole classes where this hasn't been the case. I'd say that when we do, we provide context, which is the principles on which the advice is based.
I've always assumed instructors would say, "And the reason we're doing this is to make us aware of the gotchas." If people choose to forget this, well, that's their problem. We can't stop them from naming their classes "Foo", either. ;)
I do know of dev mangers who would be absolutely livid if this happened (not me!). Not that they are trogdalites, but actually very capable. This is a learning experience that takes time. In theory that time should have been spent in the class. It's just that most dev managers are under terrific pressure to get things done and some have a good idea on how to accomplish their tasks. They are very much in the camp of "And this helps us how?".
I don't think it's a good idea for devs to implement this policy unilaterally in an organization that's as restrictive as the one you describe. However, hopefully we can make the case to them that it's a good idea, and they can argue the case to their manager. The big difference is that it's a social argument rather than a technical one (say, as opposed to telling them to use StringBuilder rather than string.Concat), but we've already agreed that since security is a process not a product, it is at root a social phenomenon.
I just have a hard time with the concept that DM should not deliver a message that is theoretically right because it might piss someone off.
Hijacking the thread for just a moment....
It is kinda like the way the java compiler forces you to deal with exceptions (unlike C#). It is annoying sometimes, but it enforces a
kind
of discipline that makes for more robust programming.
I don't know if this:
try
{ callCheckedExceptionMethod(); }
catch (Exception x)
{ }
is really considered "robust programming", but that's something I see a lot in Java code--the "catch-to-make-it-compile" syndrome. When used properly, it can create more robust programming, but when abused like this, those are the days I'd prefer C#/.NET's all-unchecked model.
I just have a hard time with the concept that DM should *not* deliver a message that is theoretically right because it might piss someone off.
+10. Speaking the truth to someone is the highest form of respect. And it need not be incompatible with politeness or respecting their right to disagree.
Whatever you may think about the merits of this debate, this is the kind of argument that people want to be exposed to when they encounter DevelopMentor.
Too bad it's on an internal list...
(Ed: Which, of course, is what made me think to post it here. )
I agree with this completely. I just do not believe that encouraging windows developers to run development tools with non-admin priv's will lead to better or more secure code. It will just mean it will take longer to do things.
Yes, testing code without admin-priv's is useful.
I have to say I agree with one point you've made: it won't probably won't lead to significantly more secure code. But I still maintain it will lead to better code: because the greatest motivator is shame, and what's worse that yelling at someone else's crappy product only to discover that you've done the same stupid stuff?
Anyway, I respect your viewpoint, Dan. I will terminate my half of the debate here. You may, if you wish, have the last word. :)
I'll let you have the last word. :)
Which I thought was both amusing and sort of captured the spirit of many of our internal debates: passionate, well-reasoned, but respectful and funny, too.