Vista's Troublesome UAC is Developer's Fault?

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?

Admin-level privileges

[Xiroth]

Hmm, I'd say he's got a good point - there's simply not a culture of privilege awareness in Windows developers.

Perhaps Microsoft should set up an audit unit and start giving software a 'UAC-compatible' tick if a piece of software has minimised how much UAC approval is required if its turned on, allowing the publisher to put it on their box so that the customers can tell. Who knows, perhaps one day the UAC system might actually be viable.

Re:I saw a different problem

[280Z28]

It will be interesting to see if developers actually pay attention. Just think about how many poor programming practices you see today*. Books have been out for 10 years about good coding... UAC is but 1 year old. I hope we're not in for the long haul, and yet I know we are...


* Today I ran across a stack class that used for its push function... an overloaded operator new...

Re:Admin-level privileges

[280Z28]

Hmm, I'd say he's got a good point - there's simply not a culture of privilege awareness in Windows developers.

Perhaps Microsoft should set up an audit unit and start giving software a 'UAC-compatible' tick if a piece of software has minimised how much UAC approval is required if its turned on, allowing the publisher to put it on their box so that the customers can tell. Who knows, perhaps one day the UAC system might actually be viable.

That is actually THE first requirement listed in the Certified for Windows Vista Logo Technical Requirements [microsoft.com]

The security model is all wrong..

[QuantumG]

on Windows, on Unix and on OS X.

The problem on Windows is that it is a single user operating system with delusions of being a multi-user operating system.

The problem on Unix is that it is a time sharing operating system which people inexplicably use as a workstation operating system.

The problem on OS X is that there are no serious threats, so no-one has any idea if their security model does anything because it never gets tested.

And the problem with all three of them is that they assume that the program will always do what the user wants and therefore the program should inherit permissions from the user. On Windows that was never true. On Unix it was only true back when all users were developers and had enough time to read the source code to all the programs they ran and thus felt they could trust them. On OS X it was actually true because, again, no-one writes malware for OS X.

The security model should be, quite simply: the program has a manifest that declares what permissions it needs with a fine granularity. The permissions should be placed into a hierarchy. For example: writes to disk -> writes to user files -> writes to user files of type X. The user should be able to inspect these permissions to determine if they are acceptable. If they are not, then the user should be free to uncheck "required" permissions.. the program should still run but those functions of the program which invoke a required permission should cause a prompt. The prompt should give the option to deny the request, or fake the request so it appears to the program that it completed successfully.

And yes, developers should use this mode.. and they would, because it is actually useful instead of just being a pain.

A bit of ridicule

[earnest murderer]

Indeed, and I would take it one step further. I'd append to each UAC a description of why it's bad practice. Something like....

Application X is trying to do X. This is behavior typical of malware or virus activity, but can be a product of poor developmet practices.

It isn't going to win any friends, but will certainly bring their ego's into play. Of course if MS really had some balls they'd just make developers live within their install directory. Nothing gets in or out without a open/save dialog, provided by the system of course.

But I also think it's awesome that MS basically absorbed the audio stack. But only because I hate Creative even more than MS. It took 15 years, but incompetent and destructive finally caught up with them.

I suppose, like the US, Microsoft will do the right thing. Once all of the other options have been exhausted.

UAC is good - if you understand it!

[hexed_2050]

Once people start to understand UAC and how it works, people will begin to harness it and accept it rather than shun away from it.

UAC allows administrators to be logged in 24/7 without having 20+ privileges until the actually need that power. 99% of the time UAC will strip the administrator privileges away from the administrator and grant them with 6 SeXXX privileges to work with. It does this by using two different tokens instead of one. The first is a normal user token, and the second is the real administrator token. When you see that screen where UAC asks for elevation, that's when Vista will grant you the administrator token. Don't believe me? Type "whoami /priv" in a normal shell under the administrator logon. Now open up a shell using "Run as administrator" and type "whoami /priv".

Vista isn't the shining example of everything secure, but it sure is lightyears ahead of XP and a real good step in the correct direction. Windows users will whine and gripe about it, but they will eventually have to go through the same stuff the *nix crowd did along time ago when people were logged in with root 24/7.

If you require Vista to elevate you with certain apps, then create a .manifest file and place it in the same directory as the .exe. The manifest file is just an xml file that tells Vista that the .exe will require administrator privileges to run (queue UAC.) Google "vista manifest" or check this out for more information: http://channel9.msdn.com/Showpost.aspx?postid=2112 71 [msdn.com]

Enjoy..

h

I like UAC, personally

[Anonymous Coward]

I've spent the last eight years of my life packaging and deploying apps for Corporate environments.

In none of those environments were the users Administrators (or even Power Users). I have written a few scripts and applications to work around some issues, but in general, it is a case of setting the appropriate permissions in HKLM and \Program Files\. It takes some work, but I have only ever had one seriously intractable application.

For the past 4 years I (and my family) have run primarily as users on our home PCs. Its a bit of a pain in XP, and I wrote my own Privilege escalation tool to make some things easier, but again, it is now pretty smooth. Even games work as users, with the appropriate settings. Vista (on my new laptop) is far easier, and no less frustrating than Kubuntu, which is always asking me to sudo an elevated operation.

UAC is a good thing - it's smart, and as developers get with the program, will add protection (not frustration) for users.

Another non-issue

[alphamugwump]

Rather than ask the user for permission on every operation, what other ways could Microsoft have improved Vista's security?

What's wrong with asking the user for permission on every operation? That's what my linux box does. It's called "su", and it makes me type in my password to make system changes. In fact, that's what every real operating system has ever done. Welcome to the real world.

A major reason for the "insecurity" of windows, IMHO, is the culture of its users. You get people who still remember 95 and 98, (and DOS) and who like to run everything as root. They don't want to be bothered with those nag boxes. But nag boxes are what it takes to secure a system. Security requires some effort on the part of the user, too. Funny how things work like that, isn't it?

See, in the beginning, a single user OS was perfectly OK. Even if you hooked your DOS machine up to the internet, it was probably a terminal, not as a computer in its own right. And really, they had so little RAM that a full-on operating system like linux would be massive overkill. A cell phone is a multimedia powerhouse compared to those machines.

But the microcomputers got bigger. They got a networking stack. People started using them like real systems instead of big, featureful, programmable calculators. They went mainstream, too. But the mindset of the users and developers was (and still is) somewhere way back in the 80s. The developers have gotten better; they add in UNIX features with every windows release. But the users, for the most part, just want to buy a box from Dell and have it work out of the box, like an appliance. Which is a fine thing to want, but those same users are also the kind of people who will install the purple monkey, become phishing victims, run binaries they got off P2P, and so on. And unless Microsoft locks people out of their own computers, there's not a damn thing they can do about that.

So while it was acceptable to bash Microsoft back in the day (no firewall, single-user mode, instability, etc), most of these problems have been fixed. Oh, sure, Windows is no OpenBSD. It's kind of kludgy, compared to linux, or OSX, or your *NIX-like system of choice. But at this point, if your system gets hacked, its probably your own dumb fault. Anymore, if you whine about windows without mentioning specifics, you just end up looking stupid, not 1337 and educated.

No, I am not a Windows fanboy. I don't dual boot, either, although I do use VMWare when I absolutely must. But it still pisses me off to see such obvious bullshit. Some of it is Apple propaganda, but a lot of it is propagated by windows users themselves. Which is understandable, I suppose, but not particularly productive.

Historical problem

[Lonewolf666]

From the blog linked in TFA:

The culture is different on these other operating systems. On UNIX, you'd be considered nuts if you ran as root all the time. And if you wrote a program that demanded to be run as root for no good reason, your application would be shunned, and rightly so.

and:

If you are a developer who has turned off UAC in frustration, remember that UAC is only this way because of all those software developers who insist on running as admin. It's not Windows you should be looking to blame.

I think that this is, in turn, a consequence of earlier Microsoft operating systems (Windows 3.x to ME) that did not have security features worth mentioning. Unix had a clear differentiation between user and admin (root) rights since decades. Windows did not, and essentially everyone was administrator.

As a result, lots of applications got written that implicitly required admin rights, accidentially or because it was the path of least resistance for the developer. As a result of that, people got used to work as administrators all the time on the newer systems (Win NT and later) too. As a result of that, there was less pressure to clean up the applications.

Now Microsoft is trying to break that vicious circle with UAC, but it seems they are not very successful... as it is once more the path of least resistance to turn it off ;-)

Re:I saw a different problem

[badfish99]

Surely the reason that Window developers haven't learned from the rest of the universe is Microsoft's fault. Microsoft have done everything thay can to make Windows development an entirely self-contained and proprietory process: you use Microsoft's IDE, write your code in Microsoft's unique language or (if you use C++) using Microsoft's unique proprietory API. You never learn, because you never have to think; you just go along with what Microsoft tell you to do, without ever having to understand it. Microsoft told people to run as administrator, and made it the default, so that's what they did.

Re:Won't work

[iang]

Actually, passing NULL as the first parameter of CreateEvent is almost always the right thing to do.

Of course the vast majority of developers don't actually know that - they just pass NULL out of laziness. But it turns out that if you spend the time it takes to learn the intricacies of the Win32 security model, you'll still end up passing NULL once you understand what's happening.

You just get to feel smug about it.

Re:They're half-right

[chaboud]

Note: I'm normally a Microsoft defender here, but I've spent too much of the last eight months dealing with Vista breaking-changes. Onto the rant...

This is such utter nonsense. UAC first came in, IIRC, in Beta 2 (May), but there were far too many problems with Vista over the beta/RC cycle to be workable. UAC was too annoying to leave turned on while trying to figure out the real bugs. UAC is still awful over remote desktop on a slower connection, as it blanks the screen. This cycle was nothing like the 2k or XP cycles with regards to beta and RC stability and direction.

One of our long-released apps went through this:

Beta 1:
Some draw issues, crashes on exit.

Beta 2:
Some draw issues, just fine.

RC1:
Some different draw issues, crashes a helper process on startup, then a second crash, completely, app dead.

RC2:
Some completely different draw issues (others gone), otherwise fine.

Release:
Same draw issues as RC2, crashes a helper process on startup, annoying help pop-up for any plug-in expecting old-school help to be available.

This was a released app for which the shipping bits did not change, at all, over the Vista cycle.

Now, it gets worse with UAC, because there are things that get more restrictive when the user gets sick of UAC and turns it off. The most obvious example is the "can't write to the TEMP folder" defect (by design? The designer is defective.). This kept several installers from working properly. If the user shuts UAC off, apps can no longer write to the TEMP directory and run their expanded installer app (winzip installer approach). This means that getting tired of UAC and pulling the plug on this behavior still interferes in the use of the system. In this case, it will hand the user a cryptic error message and no direction.

They went down this road with things like broken file-sharing and remote-desktop access with no-password accounts in XP, and it continues throughout Vista. Users of Microsoft products are regular victims of hidden behaviors, where seemingly simple changes can have much-delayed distant results.

Microsoft once cared a great deal about backwards compatibility. Now they seem to expect all software vendors to re-code, re-compile, re-test, and re-deploy for an OS change, and that OS was a moving target for the year preceding its release.

We're handling it, but what happens to the software that was orphaned by companies that died (or moved to a different platform)?

Re:I saw a different problem

[Aladrin]

Actually, I tend to leave my programming environment open for weeks, regardless of operating system. It's not 'annoying' if you would do it anyhow. It's quite a bit less annoying that way because you can just sit down and work, without the 30 second wait for everything to load back up.

So it's a matter of perspective. I will agree that if I had to keep most other programs open to avoid the UAC, it'd be annoying.

(I don't have Vista yet... I'm waiting for that first killer game that makes it a necessity. May it be long in coming.)

Re:I saw a different problem

[Anonymous Coward]

I had disabled UAC in my vista box and had to reinstall recently, so UAC was turned back on and thought about leaving it for a while, but every time I wanted to delete a file I'd get the expected and usual "are you sure you want to delete?", then the UAC file operation yes/no and one other window, I don't need to click three things to delete a file. So I turned it back off. What you're saying makes perfect sense, but there should be some way to tell that the user clicked on and requested deletion of a file rather than a program.

Re:No chicken and the Egg problem here.

[Anonymous Coward]

Unix daemons only run as root in order to bind to privileged network ports and the like then they usually suid() to their own account. So it's rare for a user to run server software under the UID of their own *nix account. The majority of windows software was just never really written for multi user systems and 2006 was a little late for them to be adding their Microsoft patented sudo.

Another advantage of open source code is that if it's being done wrong, someone will notice and educate the developer. I don't even know what the Windows equivalent of suid() is?

1. UAC is not SUDO. 2. What they did wrong.

[argent]

1. UAC is not SUDO

UAC is completely unrelated to sudo. It's an extension of the proxy privileged service scheme they've been using all along. It's not a bad model... it's much like what SafeTcl slave interpreters use... but it shouldn't be confused with "su", "setuid", or "sudo" in UNIX.

2. What they did wrong

Security is like sex, once you're penetrated you're ****ed. UAC, reduced privilege mode to run IE in, all the extra dialogs and warnings and security centers of the last ten years, they're all attempts to reduce the damage or pass the blame for the penetration on to the user. The solution is not to add more layers of annoying mitigation after IE, Outlook, and other applications that use the HTML control are inevitably penetrated. The solution is to redesign the HTML control so that it doesn't provide a security penetration API (the way ActiveX works in IE, that's what it comes down to) in the first place.

Instead, they present Silverlight, based on .NET, complete with its own security penetration API. :p

Re:I saw a different problem

[nschubach]

For one, I'm not a big fan of the verbose naming and the structure of "Documents and Settings", and the only "safe" way I can find to change any of that structure is to reinstall Windows using a "hack" install because the registry saves its data here. I ended up moving it off the system drive and changing it to \home\%username%\settings\ and moving my documents to \home\%username%\docs\ which really plays havoc with those programs that don't use system variables. It does keep the registry in the settings directory though, allowing me to do whatever I want with my documents without having to worry about selecting the registry files along with them. I never did understand why the registry files were in the user's folder. You can't copy those files to another computer and use them there without setting up a roaming profile and copying them to a network share.

Anyway, I think storing settings outside the program scope just creates directory clutter that's not needed. Keeping all the programs contained in their respective directories would allow me to back up that application very easily to a DVD/CD and restore it quickly if I ran into a problem. On top of that, you never have to worry about Program "X" browsing through your documents or pictures looking for something they shouldn't be poking around in. With disk space cheaper and cheaper, the OS could also make a compressed backup after install and use that as a backup in case you find that the program was corrupted or a patch failed without having to re-install it. I'm sure things don't happen a lot, but how many times have you used the airbag in our car?

In my model OS, programs would have less rights to the disk than the user running it. There's really no reason for programs on your PC to have user access and the user should decide when the program leaves it's designated space and what access it has. This would be done with the file open/save dialog as mentioned above and a "directory grant" dialog (or symbolic linking with permission granting a "docs" directory under the program scope) on install or program config option in the OS. Oh, and no programs should ever have access to the OS files unless specifically granted with the exception of dialog/window request or "interface" libraries in a "common library" directory that every program has read only access to in order to request windows, dialogs, and hardware access.

The best part about this is that it would be transparent to the user, yet more secure for the OS and all the programs installed. At least, every time I think about it, that's what I keep telling myself. ;)