User security, particularly in the home market now, is becoming one of the more important aspects of computer security. One of the best ways to prevent malware from doing any significant damage to a user's system is to run as a user with limited rights. These limited rights, as the name suggests, limit what the user is capable of doing. One of the disadvantages, however, is the need to occasionally run as an administrative user to perform certain tasks, such as configuration changes or software installation. Linux has a program called sudo, Windows XP has the "Run as Administrator" option, however, the most controversial of them all is Windows Vista's User Account Control (UAC), a technology aimed at allowing users to run with limited rights will maintaining the ability to perform administrative tasks without having to log in as an administrator. As we will learn in this first real chapter of "Notes from a Vista User," UAC, for its potential merit, has some major failings.

One of the things that necessary to understanding the ideas behind User Rights Elevation technology is to have an understanding of the history behind it. As anyone should know, in any operating system, Windows, *nix, OS X, etc, running the system as a user with limited privileges is one of the first steps in running a secured system. The idea behind it is that applications the user runs are given the same privilege set as the user himself. Malicious programs that try to change system configurations, or rewrite system files are, provided the user is not allowed to do so, incapable of doing such. The resulting outcome is that malware, in many cases, is now rendered ineffective. Let it be known, however, that running as a limited user will not be the panacea for one's security woes; multiple steps must be taken to lock down a system. Given this practice of running with limited rights, one's ability to carry out administrative tasks becomes limited. There must be a way to execute administrative tasks without having to logout and log back in as an administrative user, right? Fortunately, the answer to this question is yes. This is where user rights elevation technology comes. While the implementation may vary, the principle behind it remains the same from Windows to Linux to OS X.

The implementation of this technology in Linux has evolved from Secondary Login technology, where a user logs in as an administrator while already logged in as another user, to per-execution user rights elevation. The original example of this technology, which was in all uses a secondary login, was the su command. This command, when used in a command-line interface (a terminal window, or without having logged into X Windows) allows the user to log in, secondarily, as the superuser account, root. Today, the primary avenue for user rights elevation is a per-execution technology known as sudo. This is a much more flexible solution offering a wide array of configurations. With it, it is possible to set timeouts before having to reenter the root password. Even more advanced configurations are possible, limiting sudo execution to specific users. In modern distributions, there are also graphical versions of sudo that allow one to run gui applications from their desktop/window manager's run dialog.

Windows has a different history when it comes to user rights elevation. This stems from the fact that Windows, even in Vista, still has the default user account after installation being set up as an administrative account. Beginning in Windows XP SP2, Microsoft saw the growing need for more "real" security. They saw the need to have users running with limited rights, and also saw the need to have a quick solution for user rights elevation. I remember reading reports that Windows XP SP2 users were supposed to default to limited users while maintaining a hidden Administrator account. This may be true in Home edition, but I've never seen it in Professional. Regardless of what's "default," it doesn't change the fact that Microsoft implemented a basic user rights elevation technology that has gone, for the most part, unnoticed. This is the "Run as Administrator" option. Find an executable, preferably an installation program. I believe it is visible in both limited user accounts and administrative accounts. Choosing “Run as Administrator” will prompt the user for their password, and run that application with administrative privileges. The implementation of this is almost exactly what Windows needs, except it was so hidden that nobody noticed it. Enter UAC.

UAC is a technology originally intended to make it more practical to run a machine as a limited user. Windows Vista, unfortunately, still sets itself up with the default user still being an administrator; however, despite this minor flaw, even as an administrator, it is, at least initially, difficult to cause any form of serious damage. One of the advantages brought up by UAC is the fact that it forces modern applications, at least for Windows, to be designed with the mindset that the average user will no longer be running as an administrator. Sure, an administrative account will be required to really install an application, but the execution of the software after installation no longer requires having full administrative rights to carry out its tasks. Legacy applications, which I shall personally deem as Pre-Windows XP SP2 applications, operate under the old mindset. This is the mindset that the user is always running as an administrator, and the programmer can use that to his advantage by being able to take shortcuts that are allowed use thanks to the administrative rights that the user has. This is one of the situations UAC is looking for in its list of trigger events. In principle, by looking for specific trigger events, UAC is attempting to limit how many times it pops up, prompting the user to grant permission. The downside is the trigger event list is vague. It is vague to the point that carrying out a number of actions, more specifically after the initial installation, will trigger it. As I have reinstalled Windows Vista on my laptop, I left UAC enabled to get a real feel for it. Fortunately, this vagueness is not an absolute hindrance. While events which remain common during the first few days of a new installation of Windows, such as frequent software installation (productivity suites, multimedia applications, etc.), will trigger UAC frequently, once the user has settled down, many of the more advanced or higher level administrative aspects become the primary triggers. This brings me to where UAC fails.

In spite of the sound security footing behind it, UAC is plagued with its own issues that make it worth disabling. I will even admit it myself that I prefer to run with UAC disabled. Most of these issues, however, are merely inconvenient annoyances. One of the biggest peeves anybody will experience with UAC is the frequency of prompts to do the menial tasks of day-in day-out operation. Given the number of prompts one can expect to experience within the first half hour of use after setup, they shall quickly find themselves wanting to disable UAC. This frequency tends to slow down after the first day or so of installation, but it does remain frequent enough to be annoying, especially if the user is frequently in the control panel. This brings us back to our comparison between sudo and UAC. All the iterations of sudo (sudo, gksu, gksudo, kdesu, kdesudo, etc) have quite an extensive configuration for extremely detailed security configurations. The default, however, is secure enough for the average user. This default configuration builds in a standard timeout. In effect, for one entry of the administrative password, for, say 15 minutes, every use of sudo (or its derivatives) will execute without asking for the password a second time. An example of this in action:

Assume you're visiting a website with instructions on making certain configuration changes. Unfortunately, the file that needs to be edited is owned by root (the superuser account). Bringing up the run dialog, by entering gksu gedit the user has just opened a text editor in a pseudo-superuser session. Now you can edit that file freely. It only takes a minute to make a change, save, and close the program. You read more on the website. You realize that you need to make an additional change, either to that same file, or a different file, but you closed the editor that had superuser privileges. No problem, execute the same command in the run dialog, and the editor runs again with superuser privileges, without asking for the password again. 20 minutes later, the editor's been closed for a while, and now you have another file to edit. Run the command again, and because it's been over 15 minutes since you originally entered the password, it will ask for it again. This is how sudo's timeout works.

Back to reality, UAC functions differently. It has no concept of a timeout. Unlike sudo, UAC will, for limited users, ask for the password every time an event is triggered. For administrative users, it will prompt you with a dialog asking you to either allow the process to be executed, or deny it. You've all seen those Macintosh versus PC commercials. I'm sure you've seen the one demonstrating UAC where PC now has a "Secret Service" agent standing behind him. I hate to say it, but that is not an exaggeration when you truly see how UAC is implemented.

One might ask, in this field of annoyance, of what use, then, is UAC? That remains a simple answer. Despite the annoying disadvantages, UAC still does its job the way it should. It encourages people to run more as a user with limited rights, allowing them to easily, albeit annoyingly, carry out tasks that require higher permissions without having to logout and log back in as an administrator. UAC also features a Secure Desktop mode. When a UAC event is triggered, the desktop is basically "turned off," in this case, faded out, leaving only the UAC dialog bright and "highlighted." This has the advantage of preventing dialog spoofing, and I believe it temporarily halts other processes until a decision is made. The combination of the UAC prompts with Secure Desktop also adds malware prevention. Rather, it prevents malware from doing serious harm to one's computer. Without administrative rights, it can't be installed easily. Without those same rights, even if it did get installed, it can't really do what it wants to do, what it was designed to do, which is to effectively take over your computer. Though, unfortunately, these are the only really obvious advantages of UAC to the common end-user.

UAC is a unique child of Microsoft. It remains the child that, no matter how annoying, or how misbehaved, is still a member of your family. Any true security expert will say, "For every element of security you want to add, you will lose an additional element of convenience." UAC tries to add a lot of security to Windows Vista, and keeping true to the saying, takes away a lot of convenience. If they had built in a configurable timeout, preferably something with an exceptions list, UAC would have been much better than it is. I would even allow them to require a prompt every time to edit the exceptions list. Figure, you open that one 15 minute Window of allowing any program to do what it wants, malware could easily add an exception for itself, but, that isn't the way UAC was implemented. In the end, the verdict on UAC remains simple: UAC is an excellent security concept on paper; however, it remains poor in implementation.

Disclaimer: This article was written based upon my early experiences with UAC and my limited knowledge and practicality of computer security. This article is based upon opinions. I do not pretend to be totally unbiased. Factual information in this article was adapted from Wikipedia. As a side note, as I get more interested and learned in security, primarily through "Security Now" with Steve Gibson, I find myself reanalyzing UAC, both in the context of this article, and in the context of practical security. Taken in the context of losing conveniences to added security measures, UAC is a perfectly viable option for the average user. For the power user who is constantly tweaking their system, UAC is an annoyance. For the security conscious power user, UAC is not a holy grail, and they accept that they are willing to give up that piece of security.