Vista's Troublesome UAC is Developer's Fault? 228
MythMoth wonders: "We've heard all about the pain and discomfort of working with Windows' User Account Control (UAC) switched on, but now Ian Griffiths is explaining that the developers are the problem — they brought it on themselves. In earlier articles we have heard that Microsoft think that everyone should do it like this — Ian does acknowledge that things are better in the Unix world, but is he right? Is the onus now on the developers to help fix a problem that they did not cause?"
Rather than ask the user for permission on every operation, what other ways could Microsoft have improved Vista's security?
No chicken and the Egg problem here. (Score:4, Insightful)
I kinda like the concept (Score:5, Insightful)
I kind of like the concept of UAC. I mean the messages are so annoying that hopefully developers will start to avoid getting them pop up.
Hopefully this will cause applications to stay the hell out of the Windows directory, the registry and wherever else they seem to think would be a good place to sprinkle data randomly. I pine for the days of being able to uninstall a program fully from my system by deleting its folder. Or being able to simply copy a configuration file from one computer to the next and having all my settings preserved.
Perhaps I'm forgetting how bad that system was in the DOS days, and I'd welcome people reminding me, but it is looking pretty good at the moment.
Re:Admin-level privileges (Score:2, Insightful)
In theory, that already exists [msdn.com]. In order to use the "Certified for Windows Vista" logo on your software, you have to play nicely with UAC.
Re:I saw a different problem (Score:4, Insightful)
Who is a developer supposed to listen to -- Microsoft or Ian Griffiths? It seems to me that Griffiths has a lot of nerve blaming developers for following Microsoft's recommendations.
They're half-right (Score:3, Insightful)
Microsoft should've deprecated UAC heuristics and put a time limit on them. They should've given developers a year (or so) to update their applications to be aware of privileges, and then simply remove the UAC heuristic features that "guess" whether an application needs privileges. So if you run an installer built for Windows XP, it doesn't get the right privileges without you explicitly launching it with admin rights.
UAC is generally a good thing. (Score:3, Insightful)
a) run old software designed for prior windows versions.
and
b) be secure.
You might want to allow, for example, an online game to delete files IF those files belong to the game, and only to the game, like obselete maps, sound files, etc. But you don't want someone to exploit a bug in the game online to hose your system; like the bug I found in Counterstrike (old version, long fixed) where putting "%D%D%D%D%D%D%D" as your playername would crash it out (classic printf issue).
You could possibly run an app in a VM 'sandbox', but that idea breaks down as soon as you try to cut-n-paste from one app to another, or two apps want to write files in the same directory... what should it do then, prompt for Cancel/Allow for each breach of the sandbox? or have the user define complex sets of which applications are allowed to talk to each other? I did that for a Linux setup, I made seperate accounts for each service, one for the Fax receiving, one for Apache, one for each instance of the DVR simulator, one for DistCC, one for web browsing... and configured them for exactly, and only what access each needed; the Fax could put files into a directory to be served by Apache, but could not touch the templates and other pages, and nothing Apache did could touch the Fax archive and configuration, each simulated DVR had its own IP address, and couldn't see the others except via network packets. It was terribly complex, and done as a learning experiance. because everything worked perfectly when run as one user, or if p[ermissions were opened up, but it took months of spare time to get all the permissions exactly right as seperate users.
Unless you can be absolutly sure that EVERY action a program may take is approved, it needs to be controlled. As apps get fixed up, and Vista gets service packs or whatever to improve support for specific apps, the issue will fade, but never be completely gone, because sometimes, it'll save the users ass.
Won't work (Score:5, Insightful)
It's too much trouble.
I believe this is one of the main reasons why UNIX applications generally do not play fast and loose with permissions. The security model is very simple. A process is owned by the account most suitable for the role it will perform. There's no need for complicated LPSECURITY_ATTRIBUTES structures. (And yes, I do think that even those are too complicated for most purposes, so you can guess what I think of the more esoteric aspects of Windows security tokens.)
Be honest, if you program for Win32, how many times have you just passed NULL as the first parameter of CreateEvent()?
If you want to make people do the Right Thing, make the Right Thing easier to do than the Wrong Thing.
Re:I kinda like the concept (Score:2, Insightful)
Now you're kidding. Please explain how do I remove Apache by removing a single directory? Or even something simpler, say, vi?
UAC is cosmetics (Score:5, Insightful)
And that does not only apply to "clueless" users. Of course, someone who has no idea what the computer does and just why an application like explorer.exe has no business beyond the local net, will click yes on the "when in doubt, click yes or it won't work" presumption. The problem is that many Windows-Services are started in ways that make it impossible to determine whether a given program is supposed to do this or that, because there are many started using wrapper programs.
Many services are started using an application to start services. And you ONLY see that application, not (necessarily) the drivers it aktually loads. Some of them need to get access to very core deep functionality. And, unfortunately, can be abused to start trojans.
Generally, the problem lies in the untidy separation between system and user. As has been pointed out before, too, one of the problems is that developers didn't care too much about access rights so far, because you could readily assume that the user had administrator privileges, so key hives like HKLM were overused, even when unnecessary.
Another problem is that UAC is an "all or nothing" privilege mechanism, at least when it comes to installers. You either unlock the whole system or nothing. And this is even for a user with some knowledge no trivial matter to decide. You download a game from some demo page and it requests elevated privileges. Is it because it needs to set a key in HKLM, which is maybe unneeded but not critical, or is it because it comes bundled with some spyware that wants to root itself deeply in your system?
Basically, to me it seems that UAC is MSs way to shift the blame for infections away from them, and (mostly) towards the user. You allowed it to happen, we warned you, you clicked yes.
Re:Why is Microsoft asking questions on Slahsdot? (Score:3, Insightful)
I don't think Microsoft are asking. I wrote the blog entry the question refers to, and I don't work for Microsoft, nor was I acting on their behalf. (And I don't imagine I've made myself any friends in Microsoft with that blog entry.) I know the guy who submitted the question to Ask /. (MythMoth) - he doesn't work for Microsoft either. In fact as far as I know he mainly runs Ubuntu these days, and he's been a Java developer for years.
My motivation is pretty simple: I think it sucks that lots of apps have problems if you run as a non-admin user. As an application developer myself, I know that if applications are broken in this way, there is basically nothing Windows can do to fix that. (The same would be true of Linux - it would be trivial to write an application that refuses to run properly unless it's running as root. It wouldn't be Linux's job to fix that apps problems would it?) Yes, the fact that the culture grew up this way is Microsoft's fault. But I want the culture to get better. So my goal was to encourage developers write apps that work properly for non-admin users.
On another note, you've said something that doesn't seem to apply to any version of Windows I'm familiar with:
The user is boss in Windows. If you're the admin of a Windows box, it'll let you do anything, including shooting yourself repeatedly in the foot if you so choose. To give an example that's relevant to the point at hand: an admin can choose to turn off UAC. (A bad choice, IMO, but Windows certainly won't stop you making that choice.) That's just one tiny example of course - one amongst thousands. The admin is in complete control of his or her machine.
(Of course, if the admin doesn't know what he or she is doing, then this 'control' will be purely hypothetical. Being an admin merely makes it possible to control everything, but to achieve that in practice does require you to know how to achieve what you're trying to achieve. And Windows does put up the odd road block to discourage you from doing certain particularly egregious forms of damage to your machine, so if you're not an expert user, you might mistakenly conclude that you're not in control. But the bottom line is: if you're the admin, you can circumvent any of these because you are, ultimately, in complete control of your machine.)
Can you point to a single concrete example of where Windows "thinks it is better, wiser and more powerful than the user"? I've been using Windows for almost as long as I've been using Linux. (12 years and 15 years respectively.) I can't think what you might be referring to - could you be specific please?
One could make a case that Windows should behave as you're suggesting it does. (I personally don't think it should, but I can see there's an argument.) After all, the vast majority of home users are entirely unqualified to "examine every single running process themselves". But for better or worse, if someone walks into a shop and buys a PC they are the de facto administrator of that box, whatever OS it might be running, and regardless of how well qualified they might be for that task. You could argue that if Windows was as authoritarian as you are suggesting that we might have fewer zombie Windows boxes out there, because end users wouldn't be empowered to hand over control of their machines to botnets. (It's pretty well documented that enterprise that don't let end users run as admin just don't have the security problems Windows is famed for.)
I wouldn't actually want it to work that way though. While I don't run as root most of the time, it's important to me to be able to control my box. Which is exactly how it is. So I'm surprised by what you've written.
Re:I saw a different problem (Score:5, Insightful)
That's not fair, to expect Office 97 to run fine on Vista. Well actually it is. If you had followed all of Microsoft's best practices, and work the platform as designed....you end up right where we are at today.
Were Microsoft programs ever written to be run as a low privileged user working only with the users folder in "Documents and Settings" and only writing to HKCU. With the installer designed to be run once as an Administrator to write files to "Program Files" and HKLM?
Yes, you could always run a low privileged account and change permissions on certain registry keys. But face it, these are a hack. Until recently, Microsoft never wrote software that way. They never seriously advocated it either. If they did, professional software such as Quickbooks 2001 or 2005 would run just fine on Vista.
Hell, the whole registry thing was a bad idea. In the Linux world, when you move to a new box, you can copy an rc file or folder from /etc and your rc file from your home directory and the program is configured to run properly on the new machine. Bash_rc for example. Most well behaved programs make few if any changes to other programs rc files. Very few of those even need any files from /etc, usually just one file or folder from your user directory is enough.
Most of the time in Windows you can not even copy out the relevant section from HKLM and HKCU because of the shoddy programing practices as taught and evangelized by Microsoft. So many entries in the registry are spread out over so many places, the program won't run if you copy just one section from the registry. A good example is Outlook Express. You cant just copy out "Outlook Express" keys from HKCU and the data files and expect it to run.
If I had to point my finger at developers for bad practices. I will be pointing my finger towards Redmond Washington.
Re:Admin-level privileges (Score:3, Insightful)
That's great and all, but they already do something similar. Ever see a shrink-wrapped box at the store with the "Designed for Windows" logo on it? Part of the logo testing is that the app is supposed to work with limited user rights. The problem is, the overwhelming majority of Windows software isn't sold in a shrink-wrapped box, so most software vendors don't bother with logo certification.
Hmm, I'd say he's got a good point - there's simply not a culture of privilege awareness in Windows developers.
Absolutely. It is nearly 100% the developers fault. Though I suppose some share of blame goes to IT departments for not making it clear to their software vendors that applications shouldn't require admin rights to run.
Waiting PASSIVELY is not a good solution. (Score:5, Insightful)
As you state those problems stems from bad programming habits. Developers that have taken the habit of writing critical data just like in the old DOS days : wherever it pleases them, ignoring the fact that some place are supposed to be reserved for admins only.
It has worked up to WinXP because either there wasn't any protection (older DOS based Windowses) or all users did run as admins by default (newer NT based Windowses). Now that VISTA finally tries to correct this and approach something that looks like Unix' habits - using admin-level privileges for doing
BUT THEY'VE TAKEN THE WRONG ROUTE AROUND THE PROBLEM !!!
With such problems you have three solutions
- IGNORE THEM. Let the bad-behaving software just crash or display error message. That would attract attention to the fact that those software are broken. BUT ! Most users will believe that errors appear because Vista is buggy. The new version will get a bad reputation (as if the rest wasn't enough) and no users would like to switch. Microsoft would loose valuable market shares.
-> So that's why microsoft doesn't do it.
This behavious only works on Unices because most of the other software function correctly and users guess that the problems comes from the badly-behaving software and they try to download a corrected newer version or a better alternative.
- ASK USER'S PERMISSION. Do some 'sudo'-style privilege escalation for every single action that would require admin rights. And hope that developer will notice and produce more Vista-compatible softwares.
-> This is what microsoft has done, BUT THIS IS FUNDAMENTALLY WRONG.
Because concerning users
- It floods them with a mass of annoying blocking popups asking for privileges. The users ends-up first answering OK to everything (and the Unix style protection is completly lost) and then they disable the whole UAC to stop the flow of popups. So it is as if it wasn't introduced in vista in the first place.
And concerning developers
- As pointed by other
- Changing may be difficult for them, because it would require re-doing the whole program architecture. Or it could pose problem to migration between the older bad-behaving version and the newer vista-compatible version, and there's a huge users pool that the developpers want to avoid pissing because of a non-trivial migration.
- And finally, they aren't compelled to change this, because users are running with UAC disabled anyway.
The last solution would be
- VIRTUALIZE IT. Put all old-world (pre-Vista) software in a sandbox, a chroot jail, or whatever it is called in Windows. Whenever some pre-Vista software tries to access stuff it shouldn't in a normal user context, just do it - but on a dummy local copy to both avoid damaging the system and avoid annoying the user. That's the route that Apple has went were pre-OSX apps are ran inside some kind of emulator. But that is easier for them because of the radical shift in architecture : older software rely on a such different API, that it had to be emulated anyway, throwing a sandbox in the mix was only an added bonus.
Microsoft could do it as easily, because, fundamentally, Vista is XP with a shiny interface and some DRM thrown in. It would have annoyed users : They used to ran perfectly well behaving software writen for NT-Kernel under XP and suddenly, under Vista which uses mostly the same internal structure they have to run the same software inside a sandbox.
Microsoft SHOULD have spent a lot of time planning well the transit
Re:I saw a different problem (Score:5, Insightful)
Re:I saw a different problem (Score:3, Insightful)
Re:Mod Parent up please (Score:2, Insightful)
Also, apart from that, Microsoft is a very visible and controversial company, so owning up to being part of it is fine (in my book). That gives you a chance to weigh that onto what he has written and evaluate it in that context.
Whether it belongs under every post is debatable, but the fact of the matter is that it is relevant in many cases where he talks about MS.
---
Sorry if the post is messy, I got 4 phone calls while I was typing this. It's as if my employer expects me to be working just because I'm present.
A Brief History of the Admin Problem (Score:4, Insightful)
The admin problem really comes about with Windows 9x, which was released a couple years after Windows NT. Windows 9x is not an isolating multi-user system; in fact, it basically has "multi-user" capabilities strapped on to Windows 3.1. There's no file system or registry permissions, nor is there a distinction between admin and vanilla user. Windows 9x quickly became popular, as it had fairly good backward compatibility with DOS and Windows 3.1 programs, and was significantly better than Windows 3.1 in general (though nowhere near comparable to NT). So, developers everywhere started writing programs for Windows 9x. Most of these programs didn't need to run on NT (as it was a niche market for some 7 years after release), so they didn't. Dealing with limited access was more difficult, and programmers were lazy.
Consequently, by the time NT finally overthrew 9x (with Windows XP), you had a huge number of existing programs that assumed full access of the computer (for one particularly bad example, the Mechwarrior: 2 Mercenaries installer used CLI and STI for something or other - kernel mode instructions; this blew up very badly on NT, so I did some debugging). But much worse, you had an entire generation of programmers that didn't know how to work with limited user. And since most users were forced to run in admin so that they could run legacy programs in XP, the developers figured that they didn't need to learn, and the problem became self-perpetuating.
In conclusion, YES, developers are 100% to blame for the admin problem. Granted some of those developers are in MS, but in general I've found MS programs to work FAR better than third-party programs, with regard to requiring admin. I'm speaking as someone who has been running as limited user for several years and runs MS programs like Visual Studio and Office very frequently.
As a footnote, I really wish NT offered a service to allow programs to temporarily elevate their privileges (such as getting write access to their program directory) to install patches without requiring admin (once the service verifies that the patches are properly signed). Myself and a friend are considering making such a service ourselves, actually.
Re:Mod Parent up please (Score:3, Insightful)
Re:I saw a different problem (Score:3, Insightful)
Beside that, running a debugger is also far from the easiest way to get someone's passwords if you have the ability to launch programs.
Developers vs. Windows Logo Standards for Software (Score:2, Insightful)
Now, I also know that Microsoft themselves haven't followed their own rules, and some applications still require administrative rights (and some stupid design decisions such as IE's Code Store Database). Combine that with the fact that they have to support an existing installation base of applications that don't follow those practices and what else can they do? Ever tell have to tell a business user that they can't use their mission critical application anymore because it doesn't work with a proper security implementation? How about telling a Grandparent that have to go buy a new version of some application that they've been using for 10 years because it doesn't work on their new PC? UAC is Microsoft's bridge to go from the old way of everyone running as Admins to the way everyone else has been saying to run, as a "Limited User". It's either that or the proliferation of the fallacy that on Windows you must run as Root.
So, UAC sucks, but can anyone actually recommend a better solution that will work for the install base Windows has? I'm not talking about the "Windows has more users than Unix/Linux/Mac", I'm say that Windows user's and developers are DUMBER than Unix/Linux/Mac users/developers. Now, don't get me wrong, there are extemes on both sides of the fence, but if we looked at percentages, the percentage of dumb users and developers on the Windows side will probably far outweigh those on the other platforms. (Queue the "well switch stupid" comments. And I will, once the industry does as well, it's all about critical mass people.)
Here's some more information on the Vista Logo requirements:
http://microsoft.mrmpslc.com/InnovateOnWindowsVis
Here's the "Requirements for the Windows Vista Logo Program for Software document":
http://download.microsoft.com/download/8/e/4/8e4c