Log in

No account? Create an account

LUA part 4 (of 5): Changes in Windows Vista/7 - John C. Kirk — LiveJournal

Jan. 19th, 2010

03:39 am - LUA part 4 (of 5): Changes in Windows Vista/7

Previous Entry Share Flag Next Entry

This post is part 4 of a series about using a limited (standard) account in Windows for everyday activities rather than logging in as a computer administrator all the time. (You may want to read parts 1, 2, and 3 before continuing.)

When Microsoft released Windows Vista, they introduced a new feature: User Account Control (UAC). This basically meant that when you ran certain programs, you would get a message popping up, asking "Are you sure about this?" It's fair to say that this wasn't very popular; lots of people acted as though it was the return of Clippy. Quoting from one of Apple's "I'm a Mac" adverts (YouTube): "He asks me to authorise pretty much anything I do." However, if you actually understand what UAC is for then it's quite useful, and I think that Vista is a definite improvement over Windows XP.

In Vista, by default you run all programs as a standard user, even if you're logged in as an administrator. This is a good thing, because it limits the damage that those programs can do. However, you can still "elevate" programs, by running them with administrator privileges. Windows will recognise that certain programs need elevation, so it will always prompt for them; you can also right-click on a file and choose "Run as administrator" from the context menu.

There are two versions of the elevation prompt:

1) If you are logged in as an administrator, you get a "consent prompt", where you just have to click "Yes" or "No".

2) If you are logged in as a standard user, you get a "credential prompt", where you have to enter a username and password (for an administrator account).

I think that how you react to this will partly depend on your previous habits. If you're used to running as administrator in XP, where the computer will do everything it's told without question, the new consent prompts will seem intrusive. On the other hand, if you're used to running as a limited user in XP, you'll already be used to taking extra steps to run a program with admin privileges, and the credential prompt makes life a lot easier. It's similar to the old "Run As..." command in XP, except that it works better, e.g. it can handle mapped network drives. In particular, this makes it much easier to update applications: the program will download the new setup file, then Windows will automatically prompt me for credentials as soon as it runs. This has also been useful for configuring the firewall, e.g. if I install an FTP client then in XP it would be blocked, but in Vista I get prompted to add a new exception the first time I run it.

Whether you view the prompts as good or bad, the other issue is that you shouldn't see them very often. Quoting from MSDN: "Microsoft's goal is for customers to understand that applications should not unnecessarily run as an administrator and for users to question any time they are asked to approve an application's request to run as an administrator. UAC is a fundamental component for helping to achieve this goal."

For instance, suppose that you get a self-extracting zip file, i.e. an exe file that will unzip a bunch of compressed files when you run it. This shouldn't require admin privileges, unless you want to put the files into a restricted folder (e.g. under "Program Files"). So, if you're just extracting these files to your desktop and you get a prompt saying "This program wants full administrator control of your computer", you should stop and ask why. Is it really doing what you think? If the program shouldn't need admin privileges, you need to go back to the company that wrote it and ask them to fix it. Going back to the Apple advert, if you get asked to confirm everything that you do then something is seriously wrong!

Having said all that, there are a few quirks to be aware of.

Firstly, the elevation prompt appears in a "secure desktop", where no other programs can interact with it; this means that you won't get other programs clicking "Yes" on your behalf. However, there can be a bit of a "ker-chunk" effect when this kicks in, and it feels a bit like changing down to 2nd gear when you're driving at 50mph. Still, if you've got a decent graphics card then it's not too bad; this is mainly an issue if you're using embedded VGA, so it's more likely to affect you at work than at home.

Secondly, you can get repeated messages. When Vista first came out, if you wanted to create a new folder under "Program Files" then you would have to confirm this four times! That's been fixed now, so if you run Vista with SP2 then you only have to confirm it once. However, you will ideally create new folders by using a setup program rather than doing it manually, so this was never much of an issue for me anyway.

Thirdly, Vista doesn't always identify when programs need admin privileges. For instance, suppose that you want to edit C:\Windows\ODBC.INI. If you double click on it, it will open in Notepad (without an elevation prompt), and you can make whatever changes you like. However, if you try to save it then you get an error message, even if you're logged into Windows as an administrator. So, you need to explicitly run Notepad as administrator and browse for the file you want; you will then be able to save it. This should be a fairly rare situation, but I've seen a couple of people get caught out by it.

Exchange 2007 provides another example of that third point: you have to run the Exchange Management Console as administrator (i.e. it will prompt you every time), but you can run the Exchange Management Shell (EMS) as a standard user. Unfortunately, you can't do much in the EMS without admin privileges, and the error messages can be pretty cryptic if you forget to run it as administrator. This leads some people (e.g. this blog) to overreact, by saying that the best solution is to disable UAC altogether.

I think that UAC is a bit like the warning light in modern cars that tells you if you haven't done up your seatbelt. There are a few different ways to react to this.

* The classic car enthusiast: "Bah, old Bessie here never nags me about that, it's just these new fangled cars, dagnabbit!"
(Computer equivalent: "Vista sucks, I'll stick with XP!")

* The mechanic: "Nah, mate, it's easy - just open the bonnet, unplug this wire, then the alarm won't go off any more."
(Computer equivalent: "I can't get things working with UAC, so I'll disable it.")

* The careful driver: "Clunk, click, every trip! If I plug my seatbelt in, the warning light goes away."
(Computer equivalent: "I'd rather solve the problem than mask the symptom.")

If you use UAC, you have to decide whether your main account will be standard or administrator. In theory you get the same protection either way, but an admin account means that you don't have to keep retyping your password, so that seems like the best choice. However, I still keep separate accounts; I feel better knowing that applications can't elevate unless I actually type in the admin password. Jesper Johansson has written more about this on his blog (Confusion about Vista Features: What UAC Really Is):

Good: Run in admin-approval mode
Better: Run as standard user and elevate to separate admin account
Best: Run as standard user and switch user to a separate admin account instead of using UAC to elevate

(I also recommend Jesper's books for general advice about Windows security.)

Mind you, there's more to UAC then just prompts: it also includes file and registry virtualization, to help run older programs. (There's more detail at MSDN: New UAC Technologies for Windows Vista.) As a standard user, you can't modify registry keys under HKEY_LOCAL_MACHINE and you can't modify files under "C:\Program Files", so virtualization gives you a private copy of them. For instance, if I run an application, and it tries to create the file "C:\Program Files\Foobar\Settings.ini", Vista will actually create a file called "C:\Users\John\AppData\Local\VirtualStore\Program Files\Foobar\Settings.ini".

This is something of a mixed blessing. If you're running a program on your home PC, and you're the only one who uses it, this means that it will work fine without needing admin privileges, so it will actually behave better than it did on XP. However, if you run a program at work, each person who logs in will (silently) get their own private copy of the data files and registry settings. If this program is accounting software, it could lead to nasty consequences where several people enter data but none of them see each other's changes. Again, the real solution is for the software vendor to fix their applications, but it's certainly worth being aware of this feature.

This virtualization only applies to older programs that aren't "UAC aware". If an application has a "manifest" with UAC settings then no virtualization takes place, and you'll get an error if you try to modify parts of the registry or file system that are read-only. If you create a program in Visual Studio 2008, it will automatically get a manifest, although it's invisible until you click "View UAC Settings". (You can then specify whether this program needs to run as administrator.) In the longer term, Microsoft may remove this virtualization from future versions of Windows, and then applications without manifests may not run at all. Anyway, I definitely recommend creating a manifest for all new programs.

Windows 7 is much the same as Vista, but there are a couple of extra options for UAC, i.e. you can be a bit more selective about when it prompts you. Mark Russinovich has written more about that at TechNet (Inside Windows 7 User Account Control), although the options have changed a bit since then. Basically, Windows can now "auto-elevate" its own executables (if you allow it to). However, this is only relevant if you're logged in as an administrator; a standard user will still need to enter admin credentials to run those programs. Also, you can now choose to put the elevation prompt on the existing desktop: that's quicker, but less secure. Personally, I think it's best to stick with the Vista behaviour ("Always notify on every system change").

In part 5, I'll briefly cover a few other technologies that work in conjunction with LUA to protect your computer.


[User Picture]
Date:January 19th, 2010 10:44 am (UTC)
The approach taken by the UNIX / UNIX-like operating systems I'm familiar with is slightly different to this. Admin users are given access to the sudo command, which essentially allows them to execute commands as root. This has been around on the commandline since the early '80s, and is analogous to the 'Run As...' option in Windows.

Ubuntu and Mac OS X both have graphical interfaces wrapped around this (gksudo and Authorization Services respectively) which will prompt a user when something they're doing requires greater privileges, which I guess is quite similar to the Vista UAC approach. The difference is that even an admin user account doesn't have privileges to do everything - they just have access to sudo so that their credentials can be used to elevate to root privileges where required. This means that even a process belonging to the admin user can't comprehensively mangle the computer (just that user's individual files and settings), unless the user gives it access.

You can switch to running as root, however it's generally not advised as you can elevate to root privileges on demand. Mac OS X (and possibly Ubuntu) don't even have root passwords configured by default. You can set up one up if you desperately want to, but most people don't.

I remember reading a lot of the complaints about UAC when Vista came out, and being confused by them. By that point I'd got used to being prompted for my password when installing software for all users or performing certain administrative tasks. I suppose if people were used to running in an account with admin privileges it could seem annoying, but it really does seem like the best way to maintain a sensible level of security in a graphical operating system (for the average user). I guess the Mac/Ubuntu approach is slightly simpler, as the kind of LUA you describe only requires you to have one user account set up instead of two.
(Reply) (Thread)
[User Picture]
Date:January 19th, 2010 02:24 pm (UTC)
Ubuntu does indeed not set up a root password by default.
(Reply) (Parent) (Thread)
[User Picture]
Date:January 19th, 2010 06:01 pm (UTC)
Which (for those reading who may not know) doesn't mean the root account can be accessed without a password e.g. by just hitting enter; it means the root account can't be accessed, by anyone, at all. It sits on its plinth and anyone wanting root privileges must send up a request on the ladder of sudo.

Of course, there is the option to use sudo to set up a root password, and then you can sit on the plinth when you like. Which makes me wonder: does sudo instead of root grant any extra security beyond the mental check enforced by having to prepend your command with sudo and then type in your password? I mean, if you can get access to a sudo-enabled account, you can get root, and then you can do anything.
(Reply) (Parent) (Thread)
[User Picture]
Date:January 19th, 2010 07:25 pm (UTC)
If you get access to a root account, you can do anything. If you get access to a sudo-enabled account, you still need to know the password to do root things.

There also isn't a handy account named 'root' you can try to guess the password for :)

It's not much, but it makes sense.
(Reply) (Parent) (Thread)
[User Picture]
Date:January 19th, 2010 03:03 pm (UTC)
I haven't used sudo, but it does sound like a fairly similar concept. There's a blog post here which discusses some implementation differences; the main issue seems to be that in Unix you can authorise a program once and then always run it as root, whereas in Windows you have to authorise it every time. Does that match your experience in Mac OS X?
(Reply) (Parent) (Thread)
[User Picture]
Date:January 19th, 2010 03:34 pm (UTC)
Whenever I run commands (programs) which modify files outside the areas my default account can access, I have to use sudo to acquire the required privileges if on the commandline, or I will be prompted for my password if in the GUI. You can set things up deliberately so that they always run at a different user level, but I've never done this. This is broadly the same on Mac OS X and Ubuntu.

Some software will install components which run as root (or with higher levels of access) - but you get what you deserve if you install that sort of thing without thinking about where you've got it from and whether you trust the source.

On Ubuntu, 99% of the software I use comes from the Ubuntu software repositories, which I generally regard as a trusted source. Quite a few pieces of software will install components which require different user access from my own account. Some achieve this by having components run as root by various system scripts, others set up their own user accounts with the required access on installation and use that. Community vetting would quickly detect if anything from the official repositories was suspect.

I'm not quite sure the article you link to knows what it's talking about regarding the UNIX/Linux etc. side of things. There are problems with sudo, but to say that we've been 'plagued' by them is a bit over the top. It seems to conclude that the sudo approach wouldn't work with Windows because of the history of security on the Windows platform, not through any inherent problem with sudo (which is itself eminently configurable and can be set up in a variety of ways).

The Symantec article linked to basically seems to assert that sudo is a security hole because sometimes users are silly and run code they shouldn't. With all the will in the world, if an uneducated user has access to root privileges through any means then they have the capability to run malware and damage the system. The only way to protect them from this is to give them no access to such privileges and limit what they can do.

I personally think there's a lot more value in choosing a scheme, sticking to it, and then pushing for user education wherever possible.

Note: referring to UNIX as a whole is problematic, because whilst certified UNIX systems (which includes Mac OS X) and UNIX-like systems (like Linux) have a lot in common in the way they do things, they also do quite a few things differently. There are various choices for implementing LUA stuff, and different distros and OSes vary widely.
(Reply) (Parent) (Thread)
[User Picture]
Date:January 19th, 2010 06:23 pm (UTC)
I'm not quite sure the article you link to knows what it's talking about regarding the UNIX/Linux etc. side of things. There are problems with sudo, but to say that we've been 'plagued' by them is a bit over the top.

I may be incredibly oblivious by nature, but if there was a plague, you'd think I'd have noticed it sometime in the last 10 years...

And yes, if a user has (potential) administrative privileges and is ignorant, then absolutely nothing can protect them from hosing their computer, and possibly their finances. User education is IMO much more important and effective than putting up security barriers, especially ones that said user can take down when they like.

I've had a look at the Vista UAC prompt, and I honestly don't think it does anything for user education. It says the user needs to give permission for a process to continue, and asks the user if they started that process. It says nothing about the most important aspect, which is that this process wants administrative-level privileges, which would allow it to modify system files and settings, and is the user certain that they want to allow this process to do so? This seems obvious to us, but we already know about and understand root privileges; the real audience are the users who are in the dark, and as it stands, they remain in the dark.
(Reply) (Parent) (Thread)
[User Picture]
Date:January 19th, 2010 07:29 pm (UTC)
User education is IMO much more important and effective than putting up security barriers, especially ones that said user can take down when they like.

YES. This is *exactly* exactly my point. Having set up my parents' new Win7 machine, I have to say, I like UAC. It makes windows more secure, more sudo-like. Which is Good. BUT, it doesn't in any way replace or reduce the need for user education. If anything, it increases it, since now you get scary boxes saying "jucheck.exe wants to run, should I let it?" WTF! (turns out that's java update - good explanation there guys!)

Given the choice, I would choose user education over software controls any day. Because an idiot user will disable the software controls, but a small amount of understanding goes a very long way - and yes I am referring to supporting non-techies. I tech-support for my parents and grandparents, who range from competent but not confident to positively luddite. And yet they can all understand and apply basic security rules if explained in a sensible manner (two of which are "if in doubt, don't click it. If frightened, turn the computer off, at the mains if necessary.")
(Reply) (Parent) (Thread)
[User Picture]
Date:January 19th, 2010 05:57 pm (UTC)
I suspect the default of no root access, but instead the option to put users on the sudoers list, only applies to *nixes aimed at desktop use.

On FreeBSD, at least the last time I checked, sudo isn't on the base system, probably because anything you do with a server will need to be done as root anyway. If you use FreeBSD as a desktop OS, you can either install and set up sudo (which is genuinely trivial) or just su root in a terminal and do your rooty thing. I never came across, nor can I imagine, a situation on FreeBSD in which root privileges would be necessary in an environment beyond the command line, so just grabbing a terminal when needed was quick and convenient. (Window managers get lonely if there isn't a terminal open, you know.)

I must admit that, under *buntu's new regime, I am a bit irritated by having to prepend all my administrative commands with sudo, or type in my password whenever a graphical administrative tool brings up its sudo window. A single su root and a hard-wired paranoid reaction to a prompt ending in # is much more convenient. But admittedly slightly less secure, so I accept the added keystrokes, however grudgingly. :)

I'm getting the impression that Vista's UAC complaints were due to users being asked to give their authorisation for a lot of things, a lot of the time. (Not just when they want to install something or change a system setting, as we *nix users are used to and expect.) That, quite frankly, would piss me off immensely, and were I in that situation, I'd complain loudly too - and then turn UAC off, because the added security isn't worth the considerable irritation.
(Reply) (Parent) (Thread)