Can UAC settings be made permanent?

[Guest]

I participate in the Stanford University "protein folding" distributed
computing project. I need to run a command line program called
FAH502-Console.exe. I put it in a directory in Program Files, put a shortcut
on the desktop and marked the shortcut "Run as Administrator." When I click
on the shortcut icon, I still get two warnings every time I run the program:
an unknown publisher warning (no valid digital signiture) and a UAC "unknown
program" warning. On the first warninig, I always uncheck the "ask every
time" box and click on Run. On the UAC warning, I click on continue (or
whatever). The program then runs fine. But can't I PERMANENTLY approve this
program?

BTW, same thing when I navigate to the executable and run it by clicking on
"Run as Administrator."

 

[Jimmy Brush]

Hello,

Unfortunately, there is no way to allow a specific program to always run
with administrator privileges every time it starts without prompting you for
permission. This is to prevent malware from abusing this setting.

For example, imagine the case where you have told the command prompt to
always open with administrator privileges without prompting. In this
scenario, a malware that does not have admin privileges could open a command
prompt and have that command prompt perform administrator functions, since
the command prompt would automatically receive admin privileges.

As for the other prompt talking about a program that has been downloaded
from the internet, you should be able to dismiss this prompt permanently. I
believe if you perform the following steps you can get it from comming up:

- Click start
- Find command prompt
- right-click it, click run as administrator
- browse to the EXE file you need to run
- Type its name and press enter (to start it)
- When you are prompted, click the check box saying never to warn me again
- Exit the program

From this point on, I do not believe that you will get prompted for the
unknown publisher - but like I explained, you will always get prompted for
the administrator permission.

Unfortunately, the program itself will need to be re-designed so that it
will run without needing administrator permissions.

 

[Guest]

Hello,

Unfortunately, there is no way to allow a specific program to always run
with administrator privileges every time it starts without prompting you for
permission. This is to prevent malware from abusing this setting.

For example, imagine the case where you have told the command prompt to
always open with administrator privileges without prompting. In this
scenario, a malware that does not have admin privileges could open a command
prompt and have that command prompt perform administrator functions, since
the command prompt would automatically receive admin privileges.

As for the other prompt talking about a program that has been downloaded
from the internet, you should be able to dismiss this prompt permanently. I
believe if you perform the following steps you can get it from comming up:

- Click start
- Find command prompt
- right-click it, click run as administrator
- browse to the EXE file you need to run
- Type its name and press enter (to start it)
- When you are prompted, click the check box saying never to warn me again
- Exit the program

From this point on, I do not believe that you will get prompted for the
unknown publisher - but like I explained, you will always get prompted for
the administrator permission.

Unfortunately, the program itself will need to be re-designed so that it
will run without needing administrator permissions.


--
- JB

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

 

[Roof Fiddler]

Unfortunately, there is no way to allow a specific program to always run
with administrator privileges every time it starts without prompting you
for permission. This is to prevent malware from abusing this setting.

For example, imagine the case where you have told the command prompt to
always open with administrator privileges without prompting. In this
scenario, a malware that does not have admin privileges could open a
command prompt and have that command prompt perform administrator
functions, since the command prompt would automatically receive admin
privileges.

That would only be the case if Vista's shell were unable to distinguish a
request by a user process to a open command prompt from a request by the
console (i.e. the keyboard and mouse, whose buttons only the user has the
ability to press) to open a command prompt. But Vista's shell can make that
distinction, can't it? Or is the shell (mis)designed to allow ordinary user
processes to hijack the keyboard and mouse event system, so that such
processes can fool Vista into thinking that the user is pressing buttons on
the keyboard and mouse when in fact he's not?

Assuming Vista can make the distinction, then (for example) an administrator
could configure an icon on his start menu such that, if and only if the icon
is pressed by the user using the keyboard and/or mouse, will open a command
prompt in administrator mode without asking for confirmation.

The same solution would apply to the "run as administrator" option, and
anywhere else the security shield appears, and for any program set to run as
administrator; if the user, while logged in as administrator, moves the
mouse and presses its buttons (or does the equivalent with the keyboard)
such as to cause the cursor to move over the Start orb, then cause a
left-mouse-button-click event, and then move the cursor over the icon of a
program in the start menu which is set to run as administrator, and then
cause another left-mouse-button-click event, then the program will be run as
administrator with no confirmation necessary.

Is there any particular reason why it's not done this way?

Of course, a similar restriction would be placed on setting the "run as
administrator" attribute for a program; only the user using the keyboard and
mouse, or a process already running with administrative privileges, would be
allowed to do it.

The main point is that once a user has logged in at the console as an
administrator, Vista can trust all local keyboard and mouse events until the
user locks the console or logs out, and the shell, which processes keyboard
and mouse events, can't be fooled into thinking that it's receiving such
events when it really isn't.

I've written previously in this newsgroup on this topic (message subject
"Simple way to reduce UAC prompts without reducing security", on September
05, 2006), but never got any response.

 

[Jimmy Brush]

Hello,

You bring up a good point.

The question you are getting at here is basically "Can windows tell when a
user is running a program vs. when a program runs a program." The answer is
no. There's a few reasons why this is the case:

1) The UI event pipeline is not fully trusted. Although there has been some
major work done in Vista to harden this area, I don't believe that it is
fully trustable yet.

2) Even if all UI input was guaranteed to come from the user through a
trusted driver and sent to applications without modifications, Windows has
no way of knowing what action that UI event will take, and in what context
it was submitted (i.e. how the program asked for the input). This
information is critically necessary in determining whether or not to throw a
UAC prompt.

And, I should point out here that the decision on whether to throw a UAC
prompt or not needs to be made by the core UAC component that runs as a
service or in the windows security subsystem, not the Windows shell which
runs as an application in the context of the user, precisely because of that
distinction - the Windows shell runs inside of a UAC-protected environment
and must not have the power to override the behavior of UAC prompting. If it
did, other applications would be able to do the same thing (even if MS made
it extermely difficult ... it would still be possible).

In other words, Windows cannot allow the shell to do stuff that other
applications cannot, because from the point of view of Windows, there is no
difference between the shell and any other third-party application, so there
is no secure way of allowing this special behavior.

Assuming a fully trusted UI event pipleine, an obvious solution would be to
not display a UAC prompt if the following cirumstances are true:

a) The user has told Windows not to prompt for a specific application
b) A program executes that specific program while processing UI input

Since the UI input chain is trusted in this ficticious scenario, Window is
99.9% certain that the user has initiated the action.

But, this solution is far from perfect, because this will bypass UAC
prompting for approved applications while the application is processing ANY
UI input - i.e. any keypress or any click in an application - and regardless
of how the program requested this input.

This would still leave the user vulnerable, because an application could
throw up a fake window or something (for instance, a fake message box saying
"an unspecified error has occured"), and when the user clicks the OK or
CANCEL button the malware would then be able to launch an
always-run-as-admin program without throwing a UAC prompt. And this is but
one example - I'm sure the malware authors would get much more creative and
sneaky.

So, even though Windows knows the user initated some action, it has no idea
WHAT action the user is trying to accomplish (because the application
controls this, not Windows), so Windows cannot determine with any degree of
certainty whether it is safe to allow a UAC override.

If this functionality were implemented as you have suggested, it would
indeed throw up some barriers that would make it difficult to create a
malware that would take advantage of the situation - but it would not make
it impossible. If Microsoft went ahead and implemented this, malware authors
would catch on soon enough and adapt - making it pretty much pointless in
implementing.

This is a very challenging problem that presents no obvious solution, and
will probably require a fundamental change in the way Windows is architected
in order to solve.

 

[Roof Fiddler]

[snip]

And, I should point out here that the decision on whether to throw a UAC
prompt or not needs to be made by the core UAC component that runs as a
service or in the windows security subsystem, not the Windows shell which
runs as an application in the context of the user, precisely because of
that distinction - the Windows shell runs inside of a UAC-protected
environment and must not have the power to override the behavior of UAC
prompting. If it did, other applications would be able to do the same
thing (even if MS made it extermely difficult ... it would still be
possible).

In other words, Windows cannot allow the shell to do stuff that other
applications cannot, because from the point of view of Windows, there is
no difference between the shell and any other third-party application, so
there is no secure way of allowing this special behavior.

That's the root of the problem. There _should_ be a difference between the
shell and third-party applications, in the same way that there's a
difference between UAC and third party applications.
Vista guarantees that when UAC takes control of the console and displays a
confirmation dialog, it's impossible for a user-context process to press the
"Continue" button. Similarly, the correct way for Vista to be designed would
be for the shell to run in a separate context from the regular user context
in the same way that UAC does, and guarantee that it's impossible for a
user-context process to press the Start orb or perform any other such
interaction with the shell.
The UAC code is trusted, and it already contains GUI code (it can interact
with the user via dialog boxes). So why not go the rest of the way, and run
the entire shell in the UAC context?

 

[Jimmy Brush]

Similarly, the correct way for Vista to be designed would be for the shell
to run in a separate context from the regular user context in the same way
that UAC does

The UAC code is trusted, and it already contains GUI code (it can interact
with the user via dialog boxes). So why not go the rest of the way, and
run the entire shell in the UAC context?

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. 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 ... 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?

To answer your question at a more abstract level, I believe that UAC is
fundamentally a policy - a set of rules that is enforced by the core
operating system. This makes it correct for it to be implemented inside the
heart of Windows, where it has access to everything.

The shell, OTOH, is fundamentally an application and a platform - it is a
bundle of core functionality/UI that is to be extended by other applications
to make it useful. This means the shell needs to work together with
third-party apps in order for it to function.

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? Having a privileged shell would make this extremely
complicated, and open up the shell to privilege escalation attacks -
applications could try to trick the shell into doing a privileged action
that they are not able to perform themselves. No matter what security
restrictions you put in place, this will ALWAYS be a problem with the shell
in this scenario, because the shell MUST have a way to communicate with
third-party apps, and with this communication line, no matter how it is
implemented, there is risk.

Because of this, I believe it is correct for the shell as it is currently
designed to be unprivileged.

And, even if you did find some way to make the shell "special" and be able
to over-ride UAC settings without incuring a signifigant amount of security
risk, 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).

 

[David J. Craig]

To answer your question at a more abstract level, I believe that UAC is

fundamentally a policy - a set of rules that is enforced by the core
operating system. This makes it correct for it to be implemented inside
the heart of Windows, where it has access to everything.

This is a little confusing. The operating system is NT, while the
personality is Windows. All the GUI interfaces are Windows. At one time
there was an OS/2 personality. A Unix personality exists, but I am not sure
for how much longer. I believe that UAC is mostly a Windows artifact, not a
one of the NT kernel which is the real core. Being a device driver type, I
consider this to be extremely important though useless trivia for most
users.

Recent pet peeve about the Windows GUI junk: MFC allows a program to have a
modal dialog box that resizes. However, it does not offer a way to
automatically tag the various members of that window to be relocated and/or
resized when it is resized. I adapted the logic in WTL in a program I
needed to get it working, but something so obvious should be a part of MFC.

 

[Jimmy Brush]

This is a little confusing. The operating system is NT, while the

personality is Windows. All the GUI interfaces are Windows. At one time
there was an OS/2 personality. A Unix personality exists, but I am not
sure for how much longer. I believe that UAC is mostly a Windows
artifact, not a one of the NT kernel which is the real core. Being a
device driver type, I consider this to be extremely important though
useless trivia for most users.

Well, you can't run Windows without the Windows subsystem ... so I don't
really differentiate here

UAC essentially is a very simple change to the core architecture of Windows
.... instead of a user having one security access token, there are two
(elevated and non-elevated). I imagine this could be implemented in either
the Windows Subsystem or the executive.

You do bring up a good point, though ... if UAC is implemented in the
windows subsystem, and you have another subsystem installed, would it be
possible to bypass UAC by using the other subsystem? If so, this could be an
issue for corporate customers who use Windows Services for Unix.

 

[Jimmy Brush]

I will add here that I am talking about the case where the user is logged in
as an administrator or a user with more than "standard" privileges - this is
the case where they have two access tokens.

 

[Roof Fiddler]

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.

 

[Jimmy Brush]

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.

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.

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).

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:
You:

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:
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.