January 11, 2007
Secure software education. Does it start with our tools?
I recently posted something to SC-L that I thought I would share with my readers.
Last month I blogged (http://silverstr.ufies.org/blog/archives/000989.html) about my disappointment with the fact that the new service pack for Visual Studio 2005, on Vista, suggests with a specific dialog box that you run the IDE as Administrator. (http://msdn2.microsoft.com/en-us/vstudio/aa972193.aspx).
The actual dialog box is alarming and misleading, because it really gives poor advice and the false impression that developers HAVE to be building software as Administrator. Am I being selfish in believing that this is the LAST thing we want to do when trying to educate developers to not write code with administrative privileges? I know you can simply uncheck the thing and move on, (as recommended by Michael Howard at http://blogs.msdn.com/michael_howard/archive/2007/01/04/my-take-on-visual-studio-2005-sp1-and-windows-vista.aspx), but the reality is that this guidance isn't helping us as we try to educate developers to write software requiring less privileges, when the tools we use suggest that it doesn't adhere to that!
For years we have been trying to educate developers to run with least privilege so they can build safer software in a more restricted environment. Particularly important in a Windows environment where quite a few attack vectors would be significantly lessened if the software would have simply required less privileges at design time. I fear that when developers see such guidance they will simply run all their tools in an elevated context, or worse yet turn off things like UAC altogether so they can go about their "daily business". Now, I am pretty sure that a lot of us on this list have been building software in least privilege environments for years. But what does this say to those that don't know any better when they see such dialog boxes when they start their tools?
Microsoft has even written a Vista "Issue list" for when you run Visual Studio as a Standard User. (http://msdn2.microsoft.com/en-us/vstudio/aa972193.aspx). There are plenty of examples there where the work around is "Run Visual Studio with elevated administrator permissions" when it doesn't have to be. So its clear they know this is an issue.
Am I wrong for being disappointed in Microsoft's approach at this stage of the game? We aren't talking about an old IDE written for Windows95. This was built FOR and ON Vista. With Microsoft's great strides in their SDLC process to date, should we be expecting them to lead the charge in educating developers to run as Standard Users? What are your thoughts on this?
Posted by SilverStr at January 11, 2007 08:55 AM
No, Dana, you're completely right. I keep having to tell people here that developers don't actually need to be administrators, because they're not actually doing anything administrative, and nor are their applications.
My take is that most lines of code are never run by anyone other than the developer until they reach the user. As a result, if the developer is an administrator, then so must the user. If we want the user to be non-administrator, then the developer must also be non-administrator. Testing and QA isn't sufficient.
I third that emotion. There is no excuse for this.
I just obtained a consumer product, a Microsoft LifeCam. I elevated my user account to administrator and installed it there, ran it a while to get through all of the setup that might require firewall permissions (there were some, including wanting to download a software update), and restored my user account to limited user.
Before I lowered my privileges I also moved anything in the all users account to my personal, ordinary-user profile.
And, everytime I log into my administrator account, the bloody webcam software pops up to take me through the setup. I don't want the camera there -- I only do administration in the administrator account. And I can't find where it is being triggered to shut the silly thing off.
This is getting discouraging.
The funny thing is, I installed a Logitech webcam on my wife's new Media Center PC and I got it to behave properly there without much difficulty. I was impressed by her enthusiasm for it and figured that it would be cool to get a Microsoft webcam for my system. The Logitech operability is better. (I was avoiding them because I have become tired of their nag screens and use of adware. Now I have to reconsider.)
On-Target and timely. Over 20 years ago, I developed applications on a Digital VMS (OpenVMS) system.
The concept was simple, write code without privileges; it'll run without privileges.
When necessary, mechanisms existed for enabling code to run with privileges - without giving this privileges to users. When a process did need privileges the SysAdmin had to grant those rights and configure the application to run with them.
Shared libraries (like DLLs) were controlled as well. Libraries had to be installed by the SysAdmin; not by every user on the system.
Systems stayed up for Months and Years - not days. When an application failed it didn't take down the entire system (unless it was REALLY poorly written and installed with privileges - I wrote a few...)
The concept is not new - it has decades of real life practical experience. But the model depended on a OS that facilitated these capabilities.
I disagree - the model depends not just on an OS that facilitates the capabilities, but also on a culture that lives it.
After all, NT was designed by the same guy from digital who did much of the Vax design work. That's why a lot of its concepts are similar.
But there was an uphill struggle based on the presence of so many Windows 3.1-era tools that assumed first that there was no user model, and second, that if there was a user model, "the" user had all possible rights and privileges.
And developers loved this, because it pandered to our egos, telling us that we are the most powerful people on this machine - we're not just able to tell the computer what to do, but there's also noone on the computer who can tell us "no!"
I think all "powerful" terms like "administrator" and "super user" should be removed, and replaced with "janitor", "mechanic", or "grease monkey". Maybe then, fewer people would desire that level of access just because they somehow feel that they need it. I've seen company executives demand administrator privileges on the basis that they should be the most powerful user of the system.