rehoult said:
Hi Jimmy,
First, sorry for asking my first question before, I was tired and clearly
didn't look hard enough for the other posts about it. I imagine the question
gets old after a while. Also, you answers to the other questions were right
on.
Hello,
Actually, I enjoy revisiting these questions every now and then. They
are fun to think about.
could there not be an in-between where [...]
programs which are asking for admin access because
they are designed to alter the system shouldn't be able to be overriden; but
older program which are being forced to ask for access because they use the
program files forder in ways they shouldn't (or other similar crap coding
techniques) could be overriden. I'd also argue for not including the option
as part of Windows so that most users don't even know about it; make it a
downloadable change from Microsoft so that only those that need it take the
time to download it.
You bring up a great point. I'm not sure if there's really a
well-defendable right or wrong answer here, so I will just share my
thoughts and opinions.
So... how to deal with legacy programs? They don't fit inside of a
modern least-privileged environment. They do admin stuff when they don't
need to. Do we give them a break, and let them "just run" with admin
power as an advanced option, perhaps even a well-hidden option burried
where those who would not understand it would not find it? Or do we stay
hard and fast with the model?
Well, Microsoft has certainly decided to break their model as an option
in other scenarios. For example, one can always allow elevation inside
of an admin account instead of prompting -- for EVERY program -- this is
obviously more insecure than what you talk about, and yet it can be
done, albeit it is hidden very well, especially for home users.
I would point out that MS has done a lot to make legacy programs that
expect admin power work correctly WITHOUT it - thru virtualization. And
some legacy programs do legitimately need admin power, and would need
admin power even if they were Vista compliant.
But, virtualization doesn't work in all cases, so there will inevitable
be some programs that need admin power when they really shouldn't.
Your constraints are reasonable. Legacy programs only. Only if the user
turns on the feature. A security risk? Yes. But if you really take the
time to analyze what the program does when it starts up, what
files/registry keys it reads, etc, you can get a pretty good idea of
what the specific risks are, and create a plan that addresses, or at
least monitors, those risks.
So why wasn't it done like this? Even as just a little something special
to supplement virtualization for the people who need it when
virtualization doesn't work for them?
I have no idea what the actual reason was. If I had to guess, perhaps
they thought the number of people that would benefit from it when used
corectly would be too small to justify implementing it.
But here's the scenario that personally bothers me with such a feature:
It offers an easy, naughty way out to software developers who want to
push out their new software as vista-compliant without actually making
it vista-compliant. A "get out of UAC free" card.
All they would have to do is design their installer (which runs
elevated) to change the special setting or, if it is a downloadable
component, to download the setting change installer and run it in silent
mode. Then, they just make their application look like a legacy program
to the OS, and add it to the list of allowed programs.
This would go undetected by the user, as everything else would prompt as
normal, except for the "bad apps" that do this, which would appear to be
vista-compliant non-admin apps, when in fact they are not - they are
silently running as admin.
This could potentially undermine UAC in a couple of ways.
Firstly, if popular enough programs did this and it caused one to be
exploitable because of this setting change, the security of UAC would be
diminished both in fact (for the afflicted users) and in the minds of
people in general, since Microsoft and UAC would be blamed.
And secondly, if enough programs did this, UAC itself would fail in a
much broader sense, as it only works if programs end up being programmed
against the new model.
It's kind of like how many devs "get around" the driver signing prompt
for unsigned drivers on XP by faking a mouse click on the 'continue'
button so users never see the prompt. Nobody benefits here (except
possibly the developers) - users get potentially unstable drivers, have
no way to tell when they are being cheated, and Microsoft looks bad.
There are many more software devs out there than driver devs. If driver
devs actually do this, I shudder at the thought of the volume of
software devs that would do something sneaky like this.
Since all the other "security tweaks" UAC offers essentially turn off
UAC in a very noticeable fashion (the UAC prompts completely disappear),
it is much less likely that devs will use those as a way out.
It would be less secure, but I would argue not much, as designing a virus
that can scan for any program which has access admin with a prompt, and able
to correctly interface with said unsecure program to execute system altering
code is not something for the meak.
They will adapt, of course; I would rather make them work for their
money by searching for those hard-to-find technical exploits, than
letting them get by with exploiting a flaw in the security model
.
Of course, if not a lot of people used the option you talk about, then
it's kind of a moot point, as it would be unlikely that a majority of
malware would take advantage of a flaw that only exists on a minority of
computers.
Teaching them that they need to constantly click 'ok' to run
their programs removes the security UAC provides anyways as the box becomes
nothing more than a common activity; they will always click ok. While a CS
grad might notice when the box shouldn't be appearing and click no, the
front-line beginner users won't.
Actually, I would argue that for UAC, this isn't the case.
Users should expect and get used to clicking on a prompt when they run
an admin program.
Just like on *nix how you would expect to get prompted for your password
when you run an admin program. Even though you are constantly being
asked to repeatedly perform this action (click a button or enter your
password), it is always at your request, so the thing the prompt is
guarding against (an unexpected, out-of-nowhere, or unusual/incorrect
prompt) is still obvious.
Users just need to recognize that the prompt hasn't changed for that
program since the last time they ran it. This is pretty easy to do since
the prompt is so small and easily scanned, and does not require any
technical knowledge.
The prompt is designed so that in almost all cases, if something tries
to impersonate a prompt or replace a program with a malicious one, the
prompt will look different, and in many cases, significantly different.
*nix doesn't have that benefit, and this is one reason why I think UAC
is more secure than the *nix sudo model, at least in this regard.
Until they do, I'm stuck recommending
that my clients stay with XP until they can find replacement software, and I
don't see how that's better for Microsoft or security in general as it
doesn't have UAC or the loads of other security advantages of Vista.
Ryan
Excellent point. This is a tough, nasty issue
.
- JB
