At one time, PCs were stand-alone machines and had
no security issues to speak of. Yes, a PC could get infected by someone
with a floppy, but even that form of infection required direct user
interaction and was easily stopped by leaving the floppies out of the
machine. Early network connections weren't much of a problem either, as
long as the administrator kept the system clean. The problems started
when users started connecting to the Internet and the potential sources
of contamination became many and varied. Today, a network administrator
has to work hard simply to keep the infections under control, much less
prevent them. Consequently, systems today need robust security, and the
UAC is part of that solution. The following section provides a
developer view of the UAC.
1. Considering the Need for the UAC
Developers have become more careful about their
programming strategies as technology has improved. Applications today
are usually carefully planned and rely on a significant number of tools
to make them more secure. The problem is complexity. Today's
applications are considerably more complex than those early
applications that ran on the original PC. In addition, bugs can exist
in many places, many of them not under developer control. Consider
these bug sources:
Developer-created application code
Code used from older projects and other developers
The .NET Framework
Third-party libraries
Windows
External application interactions
Drivers and DLLs
Given that only the first of these sources is
actually under the developer's control, it isn't surprising that lots
of finger-pointing occurs when a bug results in an infection. There are
more people looking for entrances into your application than there are
developing that application. It's easier to find and exploit a bug than
it is to fix it once it's discovered.
When an outsider wants to exploit a bug in your
application or any of the support mechanisms on which it depends, it's
all too easy to persuade the user to participate, which is where the
UAC comes into play. In many cases, the best way to avoid infection is
to look for unusual activities. The UAC alerts the user to possibly
unusual activities that could result in an infection. Of course, the
big thing is to train the user to recognize the UAC as a helpful aid
and also to keep UAC alerts to a minimum so the user doesn't get
desensitized to them.
2. Why It Isn't a Good Idea to Override the UAC
Most users don't care anything at all about your
application — their only concern is getting work done so they get paid
and can go home each night on time. Anything else is an unwelcome
disruption. It isn't too surprising, then, that security takes a back
seat to the user's desire to get work done. Consequently, users often
look for ways to disable the UAC because it disrupts their work.
Developers are almost as bad as users when it comes to the UAC. The developer has to write
additional code to implement the UAC. In short, the UAC is also a
disruption to the developer who wants to get a working application out
the door as quickly as possible.
Windows isn't known as a particularly secure
operating system. In part, this reputation is warranted — Microsoft has
made more than a few security mistakes over the years. Windows is also
a complex operating system, and many of the concepts incorporated into
it come from a time when security wasn't as big an issue as it is
today. However, part of the reputation is simply a matter of Windows
popularity. Everyone likes to attack the biggest target, and Windows is
definitely a big target.
Because of the number of threats arrayed against it,
Microsoft implements a number of security features in Windows. Of
course, there's the application security that you should be adding to
your application. (You are adding it, aren't you?) Windows itself
provides security features, and there's the firewall that Windows
supplies. The system should also have antivirus measures installed. The
UAC is an essential piece of additional protection for a system that's
almost certainly under daily attack. In most cases, it's also the only
piece of protection that alerts you to unusual system activities
(unless you have a third-party product installed that also provides
this protection). Consequently, user and developer alike should make
use of this important feature.
3. Developing Applications with Fewer Rights
One way in which the UAC can actually help the
developer is by providing an alert to excessive rights. When a user is
going to read a file, there's no need to give that user the right to
write to it as well. If your application needs to view access rights
for the user to a file, there's no need to also obtain the audit
rights. Every time your application needs to display a UAC dialog box,
you need to consider whether the UAC alert is actually warranted. The
UAC provides an important indicator to the developer that something is
amiss with the application.
Developing applications with fewer rights is a good
idea from a number of perspectives. A user who uses an application with
fewer rights is less likely to invite various forms of contamination
onto the machine, and there's less chance that the contamination, when
it does occur, will cause problems such as data loss. Fewer rights also
make it less likely that applications will face issues such as resource
contention. For example, several applications can share a file in
read-only mode; only one application can use a file in read/write mode.
There are many ways in which fewer rights actually make application
development easier, not harder.
A concern for most developers in creating
applications with fewer rights is that users will complain. It's true
that users will complain if they can't access the things they need to
accomplish work. However, most users won't even notice having fewer
rights when they can access everything they need. You'll make the
application more secure and less resource-hungry, and all without
raising any user ire as long as you test the application carefully
using precisely the same rights that the user has to the application.
Testing is the important part of the equation because the user's
initial impression is important — an application that functions
correctly from the outset won't attract any attention, even if the user
has fewer rights than with the previous version.
