"Jimmy Brush" wrote in message
...
Well, a technical answer is that UAC shows its secure message boxes on the
secure desktop. It is not possible to mix one desktop with another (this
would kind of defeat the purpose), so you would either be able to see the
shell OR normal applications, not both at the same time.
The desktops are already mixed (or rather, overlain). When UAC shows a
dialog box on the secure desktop, the regular desktop is still shown. True,
it's dimmed, and Windows refuses to allow user interaction with the regular
desktop while the dialog box is still present on the secure desktop, but it
doesn't have to be this way. After all, Windows used to have other annoying
modal dialog boxes, and people complained, and as a result some such boxes
were made to be no longer modal. There's no reason why the dialog box on the
secure desktop has to be modal; Windows knows full well which areas of the
screen and currently showing data from the regular desktop, and which areas
are showing the dialog box on the secure desktop, and if I've got a Windows
Explorer window on the left side of my screen, and I attempt a file
operation in it which results in a UAC prompt, there's no reason for Windows
to refuse to let me make use of the calculator on the right side of my
screen until I respond to the UAC prompt.

Even if that problem were solved, there is still the problem with the
applications that interact with the shell (for instance, those zip
programs that plug in to the shell, thumbnail renderers, preview pane
plugins, etc ...
Allowing user-level programs to do these things, and other things like add
stuff to the start menu, modify the Windows Explorer right-click context
menu, etc without the user's explicit permission is a bug, not a feature.
Why is it different from allowing a user-level program unrestricted direct
access to the disk? Either way, the programs are mucking with the computer,
and ought to have to ask permission before doing so (not that granting
permission to plug into the shell should necessitate granting permission to
have unrestricted disk access, but that's another issue). And it's up to the
user in either case to decide (based on reputation of the programs' authors,
etc) whether to trust the programs and grant permission.

not to mention such things as the open/save as dialog boxes, which are
part of the shell but actually run inside of another program) - are those
going to be trusted in the same way as the shell? If not, how are they
going to work?
A program (or library) can be run as (or in) an administrator or user level
process, and can even be run as (or in) multiple processes simultaneously.
The fact that the shell program is running as an administrator-level process
doesn't mean that some of the libraries or functions which are part of that
program, such as open/save dialog boxes, can't also be run simultaneously
and separately as part of user-level processes. And the presence of a
communication channel between two processes, even if those processes are
using some libraries in common, doesn't require the vulnerability of either
process to being modified or hijacked by the other process.

If the shell was running in a more privileged environment than third-party
apps, a problem would arise: how are the third-party apps going to
interface with the shell?
Perhaps in the same way that Hotmail's web servers interface with my web
browser?

you still haven't found a way to deal with third-party programs: How can
Windows tell the difference between a user clicking say a button that says
"open the command prompt" (where the user obviously is expecting to run a
program) and the user clicking say "click here to win $100" (where the
user DOES NOT expect a program, such as the command prompt, to run).
A user-level process doesn't have the privilege to open a
(administrator-level) command prompt, no matter which dialog boxes it
presents to the user, and no matter what those dialog boxes say, and no
matter where in those boxes the user clicks. If the process attempts to open
an administrator-level command prompt, UAC will tell the user using UAC's
own dialog box, and as I mentioned previously, Windows knows which areas of
the screen are occupied by the user-level process' windows and dialog boxes
and which areas are occupied by the UAC dialog box (and supposedly the user
also knows, due to the dimming of the screen, though this notification
mechanism is a kludge and ought to be fixed), so the user-level process
can't fool the user into clicking the wrong button in the UAC box.

snip
The [UAC and standard] desktops are already mixed (or rather, overlain).

This is how things appear; however, this is not technically accurate. What
you see dimmed is actually a screenshot of the other desktop, not the actual
desktop. The desktops are actually seperated VERY well; they cannot mix as
you suggest.

In any case, this is not really necessary - In Windows Vista, programs
running in a higher privilege level are seperated pretty good from
lower-privileged applications, so this point is no longer relevant to the
discussion - the speration you are after is already present without needing
different desktops.

snip
Why is it [adding shell extensions] different from allowing a user-level
program unrestricted direct access to the disk?

UAC prevents applications from doing things that the user does not have
explicit permission to do, but the administrators group does. UAC then asks
the user if they want to invoke their admin power to complete the operation.

The user is explicitly allowed to customize their shell and generally change
anything on the system that only affects their user account, so that does
not prompt UAC since the user has access. This is how it is different - the
shell only affect the user, while other UAC-protected settings affect the
entire computer.

snip
And it's up to the user in either case to decide (based on reputation of
the programs' authors, etc) whether to trust the programs and grant
permission.

OK - at this point you have came up with a valid solution - The shell could
run privileged, and all shell plugins ALSO would have to run as privileged.

However, this does leave one problem unsolved: the problem of non-elevated
applications using the file/open dialogs. You would have to compromise
here, by re-designing the file/open dialogs and other shell code that must
run from a non-elevated process to also run non-elevated, and ask the user
for permission whenever it wants to transition to do an elevated task (which
is the current behavior and what you are trying to avoid).

snip
The fact that the shell program is running as an administrator-level
process doesn't mean that some of the libraries or functions which are
part of that program, such as open/save dialog boxes, can't also be run
simultaneously and separately as part of user-level processes.

Yes it does. The shell must either be ran COMPLETELY as an administrator -
including any components that must interact with it - or COMPLETELY as a
standard user. If you mix the two, how is the non-elevated shell going to
execute elevated tasks? It cannot (without introducing security risks and/or
annoying permission prompts for the user whenever this type of transition
occurs - which is what you are trying to avoid in the first place).

So, let me summarize what your computer looks like at this point:

- The shell runs as admin
- Anything that hooks into the shell runs as admin without prompting the
user for permission (but the user has to approve this hook-process to
happen: things just cant hook into the shell by themselves without user
permission, but once they're there, they're there)
- Any normal program that uses shell components gets a watered-down shell
that cannot do privileged things (basically reverts back to the way the
shell works right now- by prompting the user when it needs privilege)

Benefits:

- The shell is now trusted and runs seperate from lower-level processes.
This lets it do some fun stuff, like override UAC behavior in certain
circumstances.

Disadvantages:

- Much more code is running elevated by default. This is always a bad thing.
Programs should only run with the privileges they need - and 99% of the time
the shell does not need admin privileges.
- Continuing on the previous point, how many security vulnerabilities are
rooted in either the shell itself or a file that is used by the shell?
Keeping the shell running as admin means these security vulns continue to
plague Windows users.
- Approved shell plugins now run as admin, automatically, whenever you start
your computer, and without prompting the user. *shudder*.
- You don't get the benefit of the privileged shell in common dialogs and
other shared shell code that must be able to run in non-privileged
processes.
- You still don't get this bypass-UAC behavior you are looking for when
other programs run a program at the user's request - this nice feature will
only work when running applications say from the start menu or desktop.

I see way, way, way more disadvantages than advantages in this scenario. I'm
sure microsoft thought about these same sort of things when they decided to
make the shell run as unprivileged.

Me:
If the shell was running in a more privileged environment than
third-party apps, a problem would arise: how are the third-party apps
going to interface with the shell?

You:
snip
Perhaps in the same way that Hotmail's web servers interface with my web
browser?

It's not HOW the two are connected that is the problem - it is the EXISTANCE
of a connection at all. Let me show you what I mean in the context of your
example.

In this example, HOTMAIL is "elevated" - it has access to everyone's email.
And, your WEB BROWSER is non-elevated - it should only have access to YOUR
e-mail.

You are crafty and find a bug in hotmail ... say you just change the
username in some part of the URL and you can magically read other people's
e-mails ... BINGO! Your non-privileged WEB BROWSER is now executing
PRIVILEGED actions - reading other people's e-mail.

This is what I am talking about - if you allow a process with a higher
privilege to talk to a process with a lower privilege (the scenario I was
referring to here was what would you would need to do if you made shell
plugins NON-privileged but the shell PRIVILEGED), it opens up this type of
attack.

This is a security vulnerability because of a leaky abstraction - you have
defined two different things (elevated vs. non-elevated), but are breaking
the abstraction in order to allow a certain feature to work (by not
enforcing this abstraction by allowing these two different things to merge
using this magic interface).

I said:
you still haven't found a way to deal with third-party programs: How can
Windows tell the difference between a user clicking say a button that
says "open the command prompt" (where the user obviously is expecting to
run a program) and the user clicking say "click here to win $100" (where
the user DOES NOT expect a program, such as the command prompt, to run).

I am not talking here about identifying specifically if the user is clicking
a certain button - I am talking about Windows knowing that the user is
INTENDING to run a program.

The problem here is knowing WHEN to bypass UAC in a third-party program and
when NOT to. Windows simply cannot figure this out. Windows can know when it
is sending UI - but it can't know what the user INTENDS to do.

If you enable bypassing UAC based soley on when the user is performing some
kind of UI, then programs will take advantage of this behavior and render
any benefit you have gained with UAC useless.

For example, by popping up a message box and then taking advantage of the
UAC-bypass behavior when the user closes the dialog - Windows knows the user
is responding to UI, so it enables the UAC-bypass behavior, even though the
user is not INTENDING to run a program.

Thanks so much for bringing this up - I have learned a lot through this
discussion.

--
- JB

Windows Vista Support Faq
http://www.jimmah.com/vista/