UAC should prompt only once when application runs first time

[Guest]

UAC should ask for permission ONCE and remembers what programs are
allowed/not-allowed to run.

Further (optional): The ONLY time UAC should give warnings for a previously
allowed program is in the event that the program has been altered, i.e.
updated to new version, (anything that changes the CODE of the program).

This would make UAC warnings very useful as a protection strategy without
the annoyance!

Many people are turning off UAC because it keeps prompting over and over
again for the SAME applications. UAC is a great protection strategy, it just
needs to REMEMBER which programs are allowed.

----------------
This post is a suggestion for Microsoft, and Microsoft responds to the
suggestions with the most votes. To vote for this suggestion, click the "I
Agree" button in the message pane. If you do not see the button, follow this
link to open the suggestion in the Microsoft Web-based Newsreader and then
click "I Agree" in the message pane.

http://windowshelp.microsoft.com/co...35&dg=microsoft.public.windows.vista.security

 

[Paul Smith]

UAC should ask for permission ONCE and remembers what programs are
allowed/not-allowed to run.

Further (optional): The ONLY time UAC should give warnings for a
previously
allowed program is in the event that the program has been altered, i.e.
updated to new version, (anything that changes the CODE of the program).

This would make UAC warnings very useful as a protection strategy without
the annoyance!

Many people are turning off UAC because it keeps prompting over and over
again for the SAME applications. UAC is a great protection strategy, it
just
needs to REMEMBER which programs are allowed.

Programs should be re-written so they don't need full rights to the whole
box, which is nothing less than bad practice which they've gotten away with
for too long.

--
Paul Smith,
Yeovil, UK.
Microsoft MVP Windows Shell/User.
http://www.dasmirnov.net/blog/
http://www.windowsresource.net/

*Remove nospam. to reply by e-mail*

 

[Guest]

Prompting once would be a really bad idea.

First, how do you identify the program and the fact that it has not been
modified to make sure it is the same one you wanted to run last time?

Second, how do you identify what the user intended to do with the program?
Take a very simple example (which is not a UAC aware app, but makes a good
learning experience): NET USER Running "NET USER" by itself is not sensitive.
However, running "NET USER /ADD FOO" is. How are you going to determine
whether to prompt for this program, or do you want to simply allow automatic
elevation for all executions of NET USER, whether sensitive or not? Remember,
you can't rely on command line parameters either because the vast majority of
programs can be used for all kinds of things based on GUI input.

Third, how do you know that it is the interactive user that is executing the
program deliberately and not some malware running as that user? You cannot
tell which it is and by enabling automatic elevation for applications you
enable malware to execute them.

There is no way that software can discern intent. Only the end user can do
that, which means the security must involve the end user evaluating whether
the action the computer is about to take matches what the user intended.

Paul is right. The way to fix this problem is to rewrite software to
separate administrative actions from user actions. The whole purpose of UAC
is to build infrastructure to permit that.

 

[Pete Delgado]

Programs should be re-written so they don't need full rights to the whole
box,

Programs only need to require a *single* additional right before UAC gets in
the way. There are many legitimate reasons for applications to require
additional rights.

What I would like to see is the ability to configure applications in a
manner similar to the internet configuration where you can designate trusted
applications. Furthermore, I would like to have the ability to grant/deny
each application specific user rights. This would allow the setup program
for the application to grant the application the rights that it needs
without hindering the users ability to use the application.

which is nothing less than bad practice which they've gotten away with for
too long.

There are many areas where bad practices have existed, however restricting
the users ability to use valid rights that have been assigned to them is
self-defeating.

-Pete

 

[Kerry Brown]

If a program requires ongoing administrative permissions it can be setup as
a service. In Vista services have a SID and can be restricted to only having
administrative permissions for certain things. This accomplishes some of
what you are talking about but only with Vista compatible applications. The
installer would require a UAC prompt. It would then set up the part of the
program that requires administrative access as a service and restrict what
that service is allowed to do. This can be as specific as what network ports
can be used, what folders can be accessed, etc.

 

[Pete Delgado]

If a program requires ongoing administrative permissions it can be setup
as a service.

If a program is a user-based application, setting it up as a service makes
absolutely no sense. In addition, setting a program up to run as a service
means that the particular program must be designed and tested to run as a
part of the TCB -something that has much higher security requirements than
most user-based applications.

In Vista services have a SID and can be restricted to only having
administrative permissions for certain things. This accomplishes some of
what you are talking about but only with Vista compatible applications. The
installer would require a UAC prompt. It would then set up the part of the
program that requires administrative access as a service and restrict what
that service is allowed to do. This can be as specific as what network
ports can be used, what folders can be accessed, etc.

I don't think that this is useful in the sense that what if my application
requires the SeImpersonatePrivilege right and no other rights. This
specific privilege allows my user-based application to do what it needs to
do. My app doesn't need anything else. The current Microsoft scheme gives
me all of the user rights for the account or the filtered rights. There is
no way to specify anything in between which is plain stupid. I should be
able to add the specific required rights into the manifest file, but as of
today, I can't. I can only accept one of three options. This doesn't give
me the fine-grained security that I am used to getting with Windows and is
IMHO a flaw in the design of UAC.

-Pete

 

[Guest]

If a program is a user-based application, setting it up as a service makes

absolutely no sense.

If a program is a user-based application it should not be doing system-wide
changes. If a program does make system-wide changes, then it makes absolute
sense to set that part up as a service.

In addition, setting a program up to run as a service
means that the particular program must be designed and tested to run as a
part of the TCB

Not true at all. The TCB is just the kernel, not all the services in the
system.

I don't think that this is useful in the sense that what if my application
requires the SeImpersonatePrivilege right and no other rights. This
specific privilege allows my user-based application to do what it needs to
do. My app doesn't need anything else.

SE_IMPERSONATE_NAME essentially gives you admin privs on the system. You're
right. Your app won't need anything else since granting the user identity
SE_IMPERSONATE_NAME is tantamount to making the user an admin, possibly a
domain admin, depending on how you run your network.

The current Microsoft scheme gives
me all of the user rights for the account or the filtered rights. There is
no way to specify anything in between which is plain stupid.

Not true. Take a look at
http://msdn2.microsoft.com/en-us/library/aa375202.aspx. You can, and should,
take out any privileges you don't need.

I should be
able to add the specific required rights into the manifest file, but as of
today, I can't. I can only accept one of three options. This doesn't give
me the fine-grained security that I am used to getting with Windows and is
IMHO a flaw in the design of UAC.

I'm not sure what you are getting at there. Are you asking why the OS does
not ask the app what privs it needs and creates a process token with just
those privs? That is not a bad idea. It would be easier than starting out
with calling AdjustTokenPrivileges.

BTW, this is an interesting article on this topic:
http://blogs.msdn.com/windowsvistas...09/faq-why-can-t-i-bypass-the-uac-prompt.aspx

 

[Pete Delgado]

If a program is a user-based application it should not be doing
system-wide
changes. If a program does make system-wide changes, then it makes
absolute
sense to set that part up as a service.

What part of my post indicated that my hypothetical application makes
system-wide changes? There are a variety of privileges that can
legitimately be used by a user-based application without the need for full
administrative privileges and those privileges do not necessarily need to be
used to make system changes.

Not true at all. The TCB is just the kernel, not all the services in the
system.

Bullcrap. The TCB is NOT just the kernel. "[the] SeTcbPrivilege, which
SYSTEM has by default. This is the most powerful privilege in Windows, as it
indicates that you are effectively part of the operating system itself, or
the "trusted computing base," which is where the acronym TCB comes from."

http://msdn.microsoft.com/msdnmag/issues/07/01/SecurityBriefs/default.aspx

In the context of our discussion, unless you have configured your service to
run as a different user, it will run in the system context in the system
login session thus making it a part of the TCB since LocalSystem has the
SeTcbPrivilege right.

http://blogs.technet.com/voy/archiv...n-0-of-windows-vista-and-longhorn-server.aspx

Granted, on Vista one could use the RequiredPrivileges registry entry to
limit the attack surface that a poorly written service will provide to
malicious code, but the fact remains that adding code to the TCB unless
absolutely required is not advisable.

SE_IMPERSONATE_NAME essentially gives you admin privs on the system.

No, it doesn't. It gives you the ability to impersonate the security
context of a user using one of the impersonation functions. With the
exception of the ImpersonateAnonymousToken function, this requires that you
have access to a kernel object with different security credentials.

You're
right. Your app won't need anything else since granting the user identity
SE_IMPERSONATE_NAME is tantamount to making the user an admin, possibly a
domain admin, depending on how you run your network.

Wrong again. Unless you have the ability to access and use a kernel object
with different security credentials, you cannot impersonate another user
other than yourself or the anonymous session. In addition, since the
privilege can be granted on a per-machine basis within the LSA, you could
potentially have the ability to impersonate on one machine but not another
if you are using a domain account.

Not true. Take a look at
http://msdn2.microsoft.com/en-us/library/aa375202.aspx. You can, and
should,
take out any privileges you don't need.

So your contention is that an application is safe because it can adjust it's
privileges? What is then to stop malicious code from then readjusting the
token privileges *back* to the highest available privileges? Nothing.

I'm not sure what you are getting at there. Are you asking why the OS does
not ask the app what privs it needs and creates a process token with just
those privs? That is not a bad idea. It would be easier than starting out
with calling AdjustTokenPrivileges.

I'm asking why the manifest file doesn't have a section in the security
element that allows me to enumerate the privileges that my application
needs. When the process is elevated (if required) then my token should be
filtered to only have the requested privileges.

BTW, this is an interesting article on this topic:
http://blogs.msdn.com/windowsvistas...09/faq-why-can-t-i-bypass-the-uac-prompt.aspx

I wasn't aware of that particular book. Are you the co-author????

-Pete

 

[Guest]

What part of my post indicated that my hypothetical application makes

system-wide changes? There are a variety of privileges that can
legitimately be used by a user-based application without the need for full
administrative privileges and those privileges do not necessarily need to be
used to make system changes.

The point is not whether the program does system-wide changes by itself, but
rather whether it has the ability to do so. Detecting the intent of an
application is extremely hard since a lot of constituent actions can be used
to do something really bad. Each action, on its own, however, may not be
really bad. Therefore, the isolation decisions are based on privileges held,
as opposed to privileges actually used. I think we fundamentally agree on
that principle.

Bullcrap. The TCB is NOT just the kernel. "[the] SeTcbPrivilege, which
SYSTEM has by default.

You're missing my point. You made the argument that "setting a program up to
run as a service means that the particular program must be designed and
tested to run as a part of the TCB." Not all services are part of the TCB.
Only those that run in a process that has SeTcbPrivilege are. There are 150
services available in Windows Vista Ultimate. Of those, only 74 (if I counted
correctly) run with SeTcbPrivilege in their process tokens.

This is the most powerful privilege in Windows, as it
indicates that you are effectively part of the operating system itself, or
the "trusted computing base," which is where the acronym TCB comes from."

I'm well aware of where the acronym came from. It was from the Orange Book
(TCSEC). That's not really the point though. There are many, many privileges
in Windows that can be just as powerful. If you take over a process that has
only SeTcbPrivilege, and nothing else, you would have to go through a bunch
of hoops to do something interesting. Not that it is impossible, but other
privileges in combination makes the job much easier. There actually are not
that many (public) APIs that you can use just because you have
SeTcbPrivilege. A proccess with SeTcbPrivilege, for example, gives you the
right to open handles to other processes' tokens, but if you can't do
anything with that token, say, assign it to a different process, you are
relatively sandboxed in that approach to hacking the system. Combine
SeTcbPrivilege with SeAssignPrimaryTokenPrivilege and you have a combination
that is lethal, however. By the same token, SeRestorePrivilege, just by
itself, let's you replace any file on the computer. If you have no other
privilege on the system at all, SeRestorePrivilege can be used to completely
compromise the system. The same is true of SeDebugPrivilege.

In the context of our discussion, unless you have configured your service to
run as a different user, it will run in the system context in the system
login session thus making it a part of the TCB since LocalSystem has the
SeTcbPrivilege right.

Sort of, I guess. You have to configure a user context for the service. You
can't avoid that, but I guess if you configure it to run as LocalSystem, with
no other changes, then yes. Of course, on Vista, as you say, you can ask for
a restricted token, and in that case you may not have SeTcbPrivilege right
anyway. Many services do that. For example,

Granted, on Vista one could use the RequiredPrivileges registry entry to
limit the attack surface that a poorly written service will provide to
malicious code, but the fact remains that adding code to the TCB unless
absolutely required is not advisable.

The easier option may be to call ChangeServiceConfig2 at level
SERVICE_CONFIG_REQUIRED_PRIVILEGES_INFO. It lets you ask for the privileges
you want, and if you remove most of them you have a fairly well sandboxed
service. For instance, the Microsoft .NET Framework NGEN v2.0.50727_X86
service has only these privileges:

SeChangeNotifyPrivilege
SeCreateGlobalPrivilege
SeIncreaseBasePriorityPrivilege
SeIncreaseQuotaPrivilege

Yet, it runs as LocalSystem.

I don't argue at all that adding code to the TCB is inadvisable though.

No, it doesn't. It gives you the ability to impersonate the security
context of a user using one of the impersonation functions. With the
exception of the ImpersonateAnonymousToken function, this requires that you
have access to a kernel object with different security credentials.

I don't think we're in disagreement there. You create some trojan COM
object, for example; fool someone into connecting to it, and then you can
impersonate them. There are many ways to do the same thing, but they all
require (a) your ability to create or take over some object, and (b) somehow
getting someone to use it.

So your contention is that an application is safe because it can adjust it's
privileges? What is then to stop malicious code from then readjusting the
token privileges *back* to the highest available privileges? Nothing.

I'd have to play with it, but I don't see how you would do that. You'd have
to create a new token, because AdjustTokenPrivileges does not have the
ability to add privileges back to a token if it was previously used to remove
them. The test would be:
1. Create a new token for the user you want
2. Call AdjustTokenPrivileges to remove everything you don't have
3. Call CreateProcessAsUser to create a process with the adjusted token
4. From the new process, try to add privileges back

There is probably some privilege (obviously) that lets you perform step 4,
but I don't think you can do it unless you have
SeAssignPrimaryTokenPrivilege. Again, it is a matter of what all you remove.
If you are extremely strict, you can almost certainly sandbox effectively,
and if you don't, we are back to the fact that a number of privileges can be
used to defeat the sandbox. I'd have to test it though. I wrote a tool that
can be used to strip all the privs (the elevate tool at
http://msinfluentials.com/blogs/jesper/archive/2007/07/11/tools-from-the-vista-security-book.aspx).
It would perform steps 1-3. I don't have time right now to try 4, but it
would be interesting to know what it would take. Note that the Service
Control Manager also takes steps 1-3, so if you specify very strict removal
of privileges in a service it will be a lot harder to break out of the
sandbox.

I'm asking why the manifest file doesn't have a section in the security
element that allows me to enumerate the privileges that my application
needs. When the process is elevated (if required) then my token should be
filtered to only have the requested privileges.

That's a great idea. If you are on the Windows Preview beta (not a beta,
just a submission forum) vote for it. I sent it in as a suggestion.

I wasn't aware of that particular book. Are you the co-author????

Yes.

 

[Jorge Rojas]

Agree. Besides the permissions discussion, it would be a great idea making
UAC usable.

Could be possible to include it on the service pack?

 

[Jupiter Jones [MVP]]

That would also potentially give malware an easy in to the system.
In that case it would be better for UAC be turned off so there is no
expectation for protection.

Sometimes partially disabled features are worse than none.

We shall have to wait and see what changes may be in store for UAC.

 

[DevilsPGD]

In message <[email protected]> "Jupiter Jones [MVP]"

That would also potentially give malware an easy in to the system.
In that case it would be better for UAC be turned off so there is no
expectation for protection.

Only if the malware is explicitly written to exploit the app in
question, AND that app is exploitable.

As long as no apps can run by default, there is little any malware can
do.

Unfortunately this would also let lazy developers give users an easy
workaround, "Just add my app to the UAC approved list and it will work"
rather then fixing their app to not demand administrative privileges.