Vista - Can UAC settings be made permanent?

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

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/

"Jimmy Brush" wrote:

> 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/
>

"Jimmy Brush" <JimmyBrush@discussions.microsoft.com> wrote in message
news:15B9BB4F-3785-4AC7-925E-4D26905D4D31@microsoft.com...
> 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.

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.

--
- JB

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

"Jimmy Brush" <JimmyBrush@discussions.microsoft.com> wrote in message
news:FDC712D3-989E-4B0D-82C0-583CABBD0F3E@microsoft.com...
[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?

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


--
- JB

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

> 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" <JimmyBrush@discussions.microsoft.com> wrote in message
news:BE6F3F6A-2B18-4BA0-9017-9217B503DA74@microsoft.com...
> <snip>
>
> --
> - JB
>
> Windows Vista Support Faq
> http://www.jimmah.com/vista/

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

--
- JB

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

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.

--
- JB

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