FAQ: Why can’t I bypass the UAC prompt?

re: FAQ: Why can’t I bypass the UAC prompt?

Jeremy Bettis — Sat, 30 Jun 2007 19:11:50 GMT

If privilege elevation was really required, as opposed to lazy programming, wouldn't the classic approach be to delegate the privileged operations to a device driver or a system service?

I.e. SQL server requires special privileges to access the data files, but end users don't need any special admin rights to connect to the database.

re: FAQ: Why can’t I bypass the UAC prompt?

stupid — Sat, 30 Jun 2007 19:22:38 GMT

"Unix and Unix-like OSes such as Mac OS X" ... did typing Linux hurted :)

Scripting Elevation on Vista

Aaron Margosis' "Non-Admin" WebLog — Sun, 01 Jul 2007 08:32:00 GMT

Since RunAs.exe won't run a program elevated, is there a way to trigger an elevation prompt from a script?

re: FAQ: Why can’t I bypass the UAC prompt?

rwx---rwx — Mon, 02 Jul 2007 04:13:42 GMT

> functionality like setuid/suid or sudo found

> in Unix and Unix-like OSes such as Mac OS X

and Vista Business, Vista Ultimate, and Windows Server 2008. For previous versions of Windows Microsoft provided a separate download for Windows Services for Unix, but now it's built-in.

Maybe part of Microsoft made the right decision while part of Microsoft made the wrong decision, but I have a feeling that this is one case where customers probably don't complain about being given a choice.

> As computer security has become increasingly

> important,

As Microsoft has become increasingly aware of the importance of computer security,

Really, I am glad that Microsoft is becoming increasingly aware of the importance, but why does Microsoft still think that operating systems didn't exist before the creation of Microsoft. Sorry this is getting to be a rant, but you know you provoked it.

> Pre-approving code to run with elevated

> permissions [...] The "standard user by

> default" vision would become impossible

I think the opposite is true. "Standard user by default" is still troublesome because of the inconsistencies and frequency of UAC prompts. Now look at services. If a service is installed to run as SYSTEM (or to run as the lesser-powered Administrator ^_^) it has the privileges that it needs, it doesn't interrupt the user's work, and it doesn't discourage the advance of "standard user by default". A decision is made to trust the individual program. The same kind of decision could be made when installing an individual program that runs on demand instead of running as a service, and it would provide even more encouragement to the advance of "standard user by default".

> any compromise could lead to full system

> compromise

Yes. Just like with services. In other words, take adequate care in programming and testing before deciding whether to trust.

> How would future software for Windows be

> written? Answer: To silently elevate.

Make them noisy during installation time, and some users will still get the message. (Other users won't get the message, they'll still click on LUA prompts to run viruses which promise porn, but we can't do much about those users anyway.)

> Privilege escalation due to setuid and sudo

> has plagued Unix-like systems for many years,

> and continues to do so.

Yes. No one has a monopoly on careless coding and lack of testing. Let's appreciate those rare birds who are allowed to work with diligent care.

> "Nitpicker's corner" might be a trademark

Microsoft doesn't have a corner on nitpickers. Nitpickers were fixing bugs before Microsoft existed.

@rwx:

re the importance of computer security: More individuals and organizations are depending on computers for more of their critical needs than ever before, and their systems are under attack more than ever before by increasingly sophisticated criminals. So, yes, I will defend my assertion that computer security has become increasingly important. (And your assertion that Microsoft ever thought they invented the concept of the operating system is just silly.)

re services: Windows services offer one way to make elevated operations available to users, through controlled interfaces. A significant difference between services and setuid programs is that services do not run interactively, and the user does not interact with them directly. This allows the interface between the user and the service code to be defined with much tighter constraints. If you were to have a setuid-type program that desired to expose a file-save dialog, that dialog could allow the user full access to the entire file system.

-- Aaron

re: FAQ: Why can’t I bypass the UAC prompt?

rwx---rwx — Tue, 03 Jul 2007 03:18:17 GMT

> services do not run interactively, and the

> user does not interact with them directly.

True, the interactive part opens the client side of a named pipe and we need to prioritize code inspections of the service-side program more urgently than the client-side.

Maybe we can say that for any situation where the "users"[*] would want a program to run with setuid, the application should be divided into two parts and one part should run as a service. OK, I think I can agree that setuid isn't really necessary.

[* end users + administrators + managers etc.]

) (And your assertion that Microsoft ever

) thought they invented the concept of the

) operating system is just silly.)

(You'd be amazed by the thinking of some of your colleagues.)

re: FAQ: Why can’t I bypass the UAC prompt?

megame — Thu, 19 Jul 2007 01:07:10 GMT

Great article.

I was hoping that explanation like this would be published by Microsoft along with release of Vista.

There have been too many questions like: "why just does not Vista copy Unix/Mac security?" and part of your article is good answer to that question.

re: FAQ: Why can’t I bypass the UAC prompt?

Typical MS Partner — Fri, 10 Aug 2007 01:26:14 GMT

One thing that I hear echoed is why isn't there a set way for a program to detect at what level it's running instead of just "try and fail". That doesn't seem as well designed as if you have an api way to know if you can or can't do something -vs- let's try something catch the failure or force a admin dialog when we could be smart and not do it to being with.

Thoughts?

re: FAQ: Why can’t I bypass the UAC prompt?

Christian — Sun, 19 Aug 2007 13:09:48 GMT

What about COM+? Isn't it easy to configure any COM-object to run evelated?

[Aaron Margosis] Out-of-process COM objects can be configured to run elevated, but you still get a UAC prompt before it occurs.

re: FAQ: Why can’t I bypass the UAC prompt?

Christian — Mon, 20 Aug 2007 21:21:19 GMT

So I cannot have the parts of my programm that need to be run elevated as COM+-object and just use them?

Vista will detect if a normal programm loads these components and will show the consent dialog and eiter terminate my programm or let it run?

I thought that running elevated services with clear interfaces all the time wastes ressources and is visible to lots of users that like to remove useless clutter from their system.

COM+ on the other side allows to do the same things as a service, but it will demand-start a dllhost.exe with my interface and code running elevated.

What is the security reason? A service could do the same!

re: FAQ: Why can’t I bypass the UAC prompt?

Zen — Tue, 18 Sep 2007 03:00:03 GMT

The important point missed in this feature is UI experience. After a while user habitually clicks on yes, making this whole exercise fruitless.

[Aaron Margosis] I don't think so. What you've called out is a potential problem, but what we're expecting is that after a system has already been set up and apps have been installed, users will see few if any prompts, so each one should stand out and command attention. I think the UI experience is actually not bad at all -- it's better than training users to reflexively type their passwords, as other systems do. :-)

re: FAQ: Why can’t I bypass the UAC prompt?

Karl Fandrich — Fri, 19 Oct 2007 01:55:44 GMT

While I understand where Microsoft is coming from as far as needing to break the cycle, everyone I have talked to about Vista immediately says, "turn off UAC and it will solve most of your problems." If everyone turns off UAC because it is so troublesome and there is no way for admins to make it do what they want, then the whole UAC exercise is pointless. There NEEDS to be a way for admins to configure programs to run with admin rights without giving the users admin credentials. At the end of the day, if UAC hinders business, UAC will be disabled. If it takes 3 lifetimes to figure out how to make UAC do what you want, UAC will be disabled. While it may sound like a responsible moral decision, Microsoft is no further ahead by trying to force this issue.

re: FAQ: Why can’t I bypass the UAC prompt?

Aaron Johnson — Fri, 19 Oct 2007 19:22:46 GMT

I totally agree with Karl's post..."turn off UAC and it will solve most of your problems." It will. I am having a terrible time transitioning our scripts, programs, software, and policy to the UAC environment. I want to use the UAC, but it is going cause so much in-efficiency in our system, i don't know how we are going to do it. It think the UAC works well at home, but in our large enterprise, it is not working well with automated tasks.

re: FAQ: Why can’t I bypass the UAC prompt?

Aaron Johnson — Fri, 19 Oct 2007 19:31:10 GMT

By the way, someone want to try testing something? I think this is a problem related to the UAC. I'll give you my test scenario.

Windows Vista Enterprise 32-bit

Joined to domain

GPO that runs a batch file that maps a drive (net use)

Put a domain group in Administrators, put a different group in Users

Log on the machine with a domain account in the Users group. You should get your mappings.

Now put a group (can be same group as in Users) in the Network Configuration Operators group. Now log on again with the domain user account. Did you get your drive mappings? I don't.

If I turn off the UAC then I do get the mappings. If I take the group back out of Network Configuration Operators, i get mappings. For giggles, instead of adding the group to NCO I tried Power Users, and again no drive mappings. Take the group out and drive mappings are back. But the problem is not just the drive mappings, other programs do not work right in this scenario.

re: FAQ: Why can’t I bypass the UAC prompt?

John Grange — Sun, 31 Aug 2008 21:10:30 GMT

Only one problem this whole #$%#$% is that the way you describe as the right way causes me to have to turn off UAC because it simply makes it impossible for me to run administrative tasks with my "Domain Admin account" I run Mac OS X as my primary OS and I'm sorry they got the escalate privileges right, it works, and doesn't get in the way of doing your job.

Currently on my new server 2008 I have two options, A) always run as the built in administrator because the built in file system can not promptly for more rights when needed, or B) turn of UAC. both options defeat the whole bloody point of UAC in the first place, so you tell me how they got it right?!

If I am missing something please advise me, I would be glad to learn how to do things "the proper MS way". Right now I simply can not recommend 2008, its great idea, but poorly implemented.

re: FAQ: Why can’t I bypass the UAC prompt?

Rick Downer — Wed, 12 Aug 2009 08:32:55 GMT

Here's my problem. Users don't have admin rights. App requires elevation - I can't change that, it is what it is. So whenever the user runs that app they have to come to me to type the admin password for them. Either that, or I give the user the admin password, in which case I might as well make them an admin. Now, doesn't THAT defeat the ENTIRE purpose of users no longer running as admins?

[Aaron Margosis] The idea is that apps to be run by users shouldn't require admin rights in the first place. Apps should require admin rights only if they are performing legitimate administrative operations. Can the vendor (or internal developer) update the app so that it works correctly as standard user? If not, there are many mitigations that can help get these apps to work correctly without admin rights. (Which one to use depends on what it's doing that fails, or why it's demanding UAC elevation.)