UAC should prompt only once when application runs first time

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.

---
Your question may already be answered in Windows Vista Security:
http://www.amazon.com/gp/product/047...otectyourwi-20


"Paul Smith" wrote:

> "etrek" <etrek@discussions.microsoft.com> wrote in message
> news:0B20AB3D-2C8B-4B96-AB26-95D6FCAF9E35@microsoft.com...

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

"Paul Smith" <Paul@nospam.windowsresource.net> wrote in message
news:uPL8eNt3HHA.5804@TK2MSFTNGP05.phx.gbl...

> 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

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.

--
Kerry Brown
Microsoft MVP - Shell/User
http://www.vistahelp.ca


"Pete Delgado" <Peter.Delgado@noads.net> wrote in message
news:etIakf03HHA.2108@TK2MSFTNGP02.phx.gbl...

>
> "Paul Smith" <Paul@nospam.windowsresource.net> wrote in message
> news:uPL8eNt3HHA.5804@TK2MSFTNGP05.phx.gbl...

>> 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" <kerry@kdbNOSPAMsys-tems.c*a*m> wrote in message
news:O1pfmv03HHA.1168@TK2MSFTNGP02.phx.gbl...

> 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

> 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/windowsvistase...ac-prompt.aspx
---
Your question may already be answered in Windows Vista Security:
http://www.amazon.com/gp/product/047...otectyourwi-20

"Jesper" <Jesper@discussions.microsoft.com> wrote in message
news:F37EE57B-9DCB-4DC5-ADCA-6545029A4F66@microsoft.com...

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

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.

>

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

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/is...s/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/archive...rn-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.

>

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

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.

>

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

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

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/windowsvistase...ac-prompt.aspx
> ---
> Your question may already be answered in Windows Vista Security:
> http://www.amazon.com/gp/product/047...otectyourwi-20
>

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

-Pete

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

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

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/jesp...rity-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.

> > Your question may already be answered in Windows Vista Security:
> > http://www.amazon.com/gp/product/047...otectyourwi-20
> >

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

Yes.

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

Could be possible to include it on the service pack?

"etrek" <etrek@discussions.microsoft.com> escribió en el mensaje de noticias
news:0B20AB3D-2C8B-4B96-AB26-95D6FCAF9E35@microsoft.com...

> 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/com...vista.security