locked
The UAC Nightmare RRS feed

  • Question

  • I'm beginning to reach the conclusion that the current implementation of the UAC in Vista is, IMO, a nightmare that creates more problems than it solves. If Microsoft wants developers - and users - to embrace the UAC (instead of just turning it off altogether) then it better come forward with a LOT MORE information and support than it is currently providing! If it doesn't, I will begin to suspect Microsoft only added the UAC so it can tell Windows users 'well, we added the option to secure Windows - you're the ones turning it off' and therefore wash its corporate hands. I would really hate to see this happening.

    To name just a few of the problems the UAC brings to us developers:

    1 - Applications that require Admin privileges are blocked at startup.

    Heh? The work around is to create a service that does the actual program launch at startup? Am I reading right?

    2 - Applications with lower privileges cannot communicate/send Windows messages to applications running at higher security levels.

    One of the applications I develop replaces the Windows taskbar. For this to work, my application needs to be able to bring other windows to the foreground, minimize/maximize/restore them, etc... I'm not trying to control other applications, just minimize a window, and I can't even do that. On the other hand, the Explorer taskbar, which is running at medium privilege, is able to do it... HOW? Where is the information that would enable me to add the same functionality to my application?

    My application is just an example here, there are literally hundreds, if not thousands, of other applications that NEED to legitimally communicate with other windows, regardless of their security level. WHERE is the information that will allow us developers to do this? Where is the answer to the following questions:

    a) Exactly what does uiAccess=True do?

    b) How can I use uiAcess=True without requiring Admin privileges?

    c) Does digitally signing an application solve ANY of these problems in Vista?

    3 - Because of (2), applications running at Admin level do not accept drag & drops from applications (such as Explorer) running at lower privilege levels.

    This is simply unacceptable, whichever way you look at it! If another workaround is required to solve this problem, then you can bet hackers and such will use the same work around to do their thing... so why make life difficult to us normal developers?!

    This is just a sample of the questions Microsoft should be actively providing the answers for in these forums or in the MSDN. Instead there is only silence, and Vista for consumers is just around the corner!!!

    I also don't understand why the UAC can't act more like Firewalls do: tell the user that application X is asking for admin rights, ask if it should provide them or not and then provide an option to remember the answer, so that, if the user says yes, the next time it doesn't need to ask again and the app is automatically given admin rights as required. It would also keep an eye on application checksums and ask again if the executable has changed for some reason. If Firewalls can be trusted to protect your PC from Internet threats coming from the outside - and the inside - with this method, why not the UAC for elevating applications? It would vastly reduce the number of UAC prompts and solve most of our problems as developers, while still providing more than reasonable security.

    Tuesday, January 23, 2007 12:33 AM

All replies

  • Ok, looks that I am the only one replying to my own message... Sigh. 

    For future reference, I managed to track down exactly *two* posts on this issue, both apparently by MS employees (nothing on MSDN that is actually useful, just a statement that there is indeed something called uiAccess. Great quality documentation - not!):

    The uiAccess flag in a Vista manifest allows an application to bypass UI protection levels to drive input to higher privilege windows on the desktop.

    However, for it to work, two things must also be true:

    1 - The application that wishes to receive the uiAccess privilege MUST reside in a trusted location on the hard drive (i.e.; c:\Windows\ or c:\Program Files\). They will still run if they are not in one of these locations, but they will not receive the privilege, which means my application will fail to function properly if the user decides to install it anywhere outside c:\Program Files\.

    2 - Applications that request uiAccess=true must have a valid, trusted digital signature to execute. Personally I resent being *forced* to shell out $199 for a digital certificate from MS *every year* so my application runs properly on Vista. And what will a freeware application developer do when he finds out his utility won't run - or will not run correctly - unless he actually pays MS money every year?

    I think these two issues provide some food for thought, even if your application is not affected by them.

    I still have a couple of questions, though:

    1 - Will my application accept dragged files from lower privilege applications if it is digitally signed *and* has the uiAccess privilege *and* is installed on a trusted location *and* is running with administrator privileges?

    2 - After compilation, data critical to license key validation is appended to the end of my application's executable file. This data is read every time my application is run. Since a Digital Certificate also appends data to the end of an executable, how can I get the two to work together? i.e.; if I append the data AFTER signing the application, won't it complain later about code tampering? If I append the data before, how would my application then know WHERE to look for it?

    By the way, I'm *assuming* that the uiAccess flag set to true does NOT automatically require the application to also have admin privileges. I really hope I'm not wrong.

    Wednesday, January 24, 2007 10:22 PM
  • Hello,

    1) Applications that both start when the computer turns on and require administrative privileges probably should be implemented as a service anyway, since that is essentially what they are.

    2) I agree that this is unfortunate. This restriciton is in place due to the fact that win32 wasn't really designed to support different privileged apps running on the same desktop, so this kind of isolation is necessary to prevent privilege escalation between different privileged processes [known as a shatter attack]. Luckily, (as of now) neither hackers nor programmers can get around this, so the security is intact.

    3) Agreed - this is unacceptable. However, the security implications of not having UAC is even more unacceptable, IMHO.

    The reason UAC doesn't allow "blessing" of an executable is becuase it would allow lower-privileged applications to start blessed higher-privileged applications and abuse them. Imagine the (likely) common case of a user blessing a command prompt to always run as administrator. A lower-privileged application could thus start the always-trusted command prompt and use it to elevate its privilege level and abuse the system.

    One might say "well don't let non-privileged apps run always-blessed apps." Well, from the OS's perspective, how can you tell the difference between the user starting a program and a program starting a program? (And no, it's not as simple as tracking mouse clicks :) Answer: A UAC prompt! A UAC prompt both ensures that the user is the one initiating the action and that the user has unbiased info about the program requesting permission. Hopefully in the future Windows will have a better way to tell if a user is intending for a program to start elevated, without having to go thru the hussle of a UAC prompt; until then, we're stuck with what we have. Throwing in a 'always elevate this program without prompting' option right now would completely defeat the security of UAC.

    In the same vien, this is why you don't have an option to 'approve all admin actions automatically for the next X minutes' - malicious apps would just wait for the user to enter this mode and then silently execute their payload.

    As for the firewall analogy - UAC and firewalls are different beasts. Firewalls ensure that two computers (or applications) can only communicate with each other according to a pre-defined policy. UAC allows the user to decide if they want a program to run privileged or not. Unfortunately, it is not possible yet for UAC to tell if the user wants a program to run privileged without prompting them every time it runs.

    - JB

    Microsoft MVP - Windows Shell/User

    Friday, January 26, 2007 2:31 PM
  •  Jorge Coelho wrote:

    1 - Will my application accept dragged files from lower privilege applications if it is digitally signed *and* has the uiAccess privilege *and* is installed on a trusted location *and* is running with administrator privileges?

    Not by default. However, any higher-privileged application can specify that it wants to allow lesser-privileged apps to send it certain windows messages using the ChangeWindowMessageFilter API. http://msdn.microsoft.com/library/default.asp?url=/library/en-us/winui/winui/windowsuserinterface/windowing/windows/windowreference/windowfunctions/changewindowmessagefilter.asp

    Friday, January 26, 2007 2:41 PM
  • Hi Jimmy - and thanks for your reply.

    I have nothing against making Windows more secure, except when that security starts to seriously compromise your ability to make things work. Going a bit overboard, it's almost the same as thinking that 'the only truly secure computer is the one that is turned off, so lets prevent the user from turning it on and call it a day'!

    In the name of security, Microsoft has broken one of the golden rules that made Windows what it is today: backwards application compatibility (read the very interesting Raymond Chen's true story at http://blogs.msdn.com/oldnewthing/archive/2005/08/24/455557.aspx to get an idea how important this was to Microsoft when Windows 95 was being developed). The new security features in Vista, as they currently are, have broken compatibility with hundreds, if not thousands, of applications out there (http://biz.yahoo.com/prnews/070129/nym254.html?.v=27). This is not a good sign.

    Although developers are rushing to change their applications so they run in Vista (they have to, no choice), all these limitations are generating a lot of ill feelings towards Microsoft (http://searchnetworking.techtarget.com/originalContent/0,289142,sid14_gci1210002,00.html , http://www.gamasutra.com/php-bin/news_index.php?story=12314 , etc...) and, worse, seriously compromising what the software can actually do.

    I for one intensely dislike that, from now on, I have to pay Microsoft a fee every year in order for my software to run as well in Vista as it did in XP and all Windows versions before it.

    I think the UAC still has a long way to go. As it still is, I believe most users will simply start turning it off in order to run their favorite applications.

    Friday, February 2, 2007 6:33 PM
  • Jorge,

    Just want you to know that you are not alone, and further that you have put into words very well how I feel about Vista.  Thank you.

    Kevin

    Wednesday, February 7, 2007 9:20 PM
  •  

         I have been developing Software for MS for years and I have talked good of MS for a long time as well but I agree with you Jorge 100%.  I almost smashed my studio when I found out my application would have to work so hard in order to work and FURTHER I aint paying MS NO MORE $$$ than I paid for Vista, VS2005, Office, Ect just to have a program that I wrote work!  That is freaking stupid.  I will start programming on Linux before I pay MS anything to approve my application.  Unless my application is making mad cash then screw that ***.  I develop freeware and share useful tools and applications as a hobby and job.  I don't usually charge and if I do it's minimal.  This is rediculous.

    Saturday, February 17, 2007 10:53 AM
  • Hi, JB,

    Are u sure for the following? I create a service there, but it still blocked by Vista... Why?

    Thanks

    1) Applications that both start when the computer turns on and require administrative privileges probably should be implemented as a service anyway, since that is essentially what they are.

     

    -chueh8

    Thursday, February 22, 2007 6:44 PM
  • Maybe because your service is not signed? No idea, just guessing here.

    This is precisely one of the things that really gets on my nerves: the current lack of information from Microsoft on how to handle all these UAC imposed limitations...

    Thursday, February 22, 2007 6:52 PM
  • I do not get why the user is unable to pre-approve an application (at install time) to silently elevate and run at startup with admin privileges. ???
    Friday, February 23, 2007 3:31 AM
  • I was thinking the same thing.

    Can't I create an application that a user may download, install, and run without problems in the UAC?

    Will users have to click "allow" every time from now on?

    Is the only way around this to send MORE money to microsoft?

    If that is the case, we may opt to recommend our clients to disable the UAC.
    Either that or take the same route that some other companies did. Telling people "Seer clear of Vista for now."

    The reason? We already paid Microsoft upward of $1500 PER WORKSTATION for Windows, Office, and Visual Studio, why should we have to pay more, just to work around a stupid popup message in Vista, (which I thought was supposed to be better for developers)

    Don't get me wrong, they are awesome products, but our lawns aren't made of cash.

    in my dreams.. someone comes along here and tells me i got it all wrong and there is a way after all ;)

    -zacho
    Saturday, February 24, 2007 4:05 PM
  • Jimmy explained it in a post above: because if this was possible (and lets call this 'blessing an application') and the user blessed, say, the Command Prompt, then a malware application could in theory launch the Command Prompt (which would then run with admin privileges WITHOUT displaying a UAC prompt) and use it to lauch a copy of itself. Because privilege is inherited, the malware launched by the 'blessed' Command Prompt would in turn run with admin privileges and have access to the whole system.

    Even if I do understand the reasoning behind this, there are two things I would like to point out: first, how would the malware know which applications have been blessed and which not, so it knows which ones to 'abuse'? Second, it's still the user's responsability to reply Yes or No to an UAC prompt. Why trust the user for this and not for 'blessing' applications, then?! Doesn't make sense to me.

    Sunday, February 25, 2007 5:18 PM
  • " ... and use it to lauch a copy of itself"

    Yes, but at this point an approval request would pop up becuase the malware is not allowed to run as full admin. The command prompt is but the malware not. 

    Monday, February 26, 2007 12:46 AM
  • No it wouldn't because privilege levels are inherited:

     If application A launches application B, then application B will run with - i.e.; inherits - the same privilege level of application A (unless A is running at normal privilege level and B requests an elevation of privilege, which is not the case). Assuming A is the 'blessed' Command Prompt and B the malware, then B will run with the full admin privileges of the 'blessed' Command Prompt that launched it.

    Monday, February 26, 2007 1:02 AM
  • You are right, but the malware is running not elevated.... so it should not be able to run Command Prompt elevated.

    I only approved that Windows startup/shell can do that automatically.

    Monday, February 26, 2007 2:21 AM
  • Ordinarily, no, but we are talking about an imaginary situation where the user himself would have previously 'blessed' an application - in this example the Command Prompt - so it always run with admin privileges and therefore would never again present the user with a UAC prompt (much like you tell a Firewall never to prompt you again when an application you trust tries to access the Internet).

    What you seem to want is a 'blessing' that only works at system startup - well, this would only solve half the problem, and probably create as many security loop-holes as a full, always on, 'blessing'.

    Note that I am NOT defending the point of view that 'blessing' an application should NOT be possible, quite the contrary! Even if I do understand Microsoft's reasoning for not allowing the 'blessing' of applications, there are two things I would like to point out: first, how would the malware know which applications have been 'blessed' and which not, so it knows which ones to 'abuse'? Second, it's still the user's responsability to reply Yes or No to an UAC prompt. Why trust the user for this and not for 'blessing' applications, then?! Doesn't make much sense to me.

    Anyway, there is a white paper at MSDN called '"Developing Applications that Run at Logon on Windows Vista" that states at the end:

    Certain applications when executing setup may require a reboot to continue and complete the installation.

    In such a case, the elevated application should write to the RunOnce registry key at: HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\RunOnce.

    When the system reboots and a user in the Administrators group logs on, the application will launch, complete the installation and delete the entry from the RunOnce key without requiring the user to interact with a UAC elevation dialog box.

    I wonder what would happen if an application kept putting itself back into the RunOnce key every time it run... Since the default Vista user is part of the Administrators group, and unless I am missing something, once your application got elevated by the user ONCE, it could through this method make itself automatically executed and silently elevated every time the default user (or any other user in the Administrators group) logged in after a reboot. Of course, this would probably not work if there is more than one user using the machine (the RunOnce key is only run after a reboot?).

    Anyway, I haven't tried this, though, so I could be dead wrong. If I'm not, then this looks like a nice loophole in the current UAC's security scheme.

    Monday, February 26, 2007 3:07 AM
  • If 'blessing' is such a security hole, why can services be blessed to run with full elevated admin, without repetitive approval? Maybe 'hackers' do not know how to write or interact with services?

    RunOnce is an interesting possibility, need to try that.

    Another method could be to add a task to the new Vista task manager with instruction to run at startup with elevated privileges. Need to check this one as well.

    Or creating a service which runs your program at startup, more complicated, but seems possible.

    Monday, February 26, 2007 5:41 AM
  • Given Chueh8's post on this thread, I'm convinced services that need elevated privileges will still be blocked from running at startup unless digitally signed. This means you must pay Microsoft 'protection' money (hey, a bit strong, I know, but that is exactly how I feel right now) every year to get a digital signature that enables your software to run properly under Windows Vista. Funny how Commodo, for instance, just doubled their retail prices for Code Signing Certificates...

    I would still like to see a reply to Chueh8's post from a Microsoft MVP or representative who knows the actual requirements in order to confirm or deny my suspicions.

    Monday, February 26, 2007 6:09 AM
  • We were able to add a task to the new Vista Task Scheduler....

    The new task launches our application at logon with elevated privileges and without any elevation approval

    Matt

    Wednesday, February 28, 2007 2:48 AM
  • Interesting... without having looked at the Vista Task Scheduler (please correct me if I am wrong), this probably means two things: first, the task scheduler service is running with elevated privileges and, second, every task launched by it will also run with elevated privileges because privilege level is inherited. Besides the obvious security risks, this will be a PITA if you actually DON'T want your task scheduled application to run with elevated previleges (for instance, you want it to accept files dragged from Explorer): since you can't lower your privilege level, you're stuck.

    Anyway, all this begs for a question then: what has Microsoft achieved by blocking applications that need to be elevated from running at startup? Nothing, except pissing developers up by making their life difficult and forcing them to abuse other Windows features to work around the Vista imposed limitations. Good job... not! The UAC is full of holes and inconsistencies.

    Wednesday, February 28, 2007 4:19 AM
  • first, the task scheduler service is running with elevated privileges

    Yes (all services do)

    second, every task launched by it will also run with elevated privileges because privilege level is inherited.

    For each task, you decide. You can run a task with elevated privileges or not.

     

    Wednesday, February 28, 2007 4:31 AM
  • I am not a developer.  I am a user. 

    UAC is not a virtual world issue. 

    Signing may have something to do with it, but if so, why does Microsoft Office 2007 tell me that the Office component has not been installed for the current user?  There is only ONE user account, which I used to install Office 2007. 

    I have tried to find an answer by searching the internet & posting at forums.  The problem is so new that no one has replied. 

    I understand that using an OS during its 1st "X" months is a challenge.  But problems with Office 2007? 

    I hope one of you discovers the cause & the remedy for situations such as mine. 

    edx15
    Saturday, March 3, 2007 9:27 AM
  • I have another item to add to your nightmare.  I'm running Vista 64-bit.  I'm the only user and the UAC has me listed as an Administrator, but when I try to alter or move files from the Program Files folders I'm told that I need permission.  I've tried going to the security tab of the folder I want to move to change the permissions, but all of the check boxes are greyed out.  I ended up having to reboot in safe mode to remove the folders in question.

    Anybody know how this might be fixed?  MS support took 3 hours on chat to decide that my user account is corrupted.  Any other thoughts?

    Tuesday, March 6, 2007 9:37 PM
  • Msmythe: 

    I commend you on your perseverence; 3 hr chat.  WOW!

    That is progress.  Less tedious than a re-format  & re-install. 

    Why did this happen?  What can be done to prvent it from happening again?  Why is there air? 

    edx15

    Wednesday, March 7, 2007 3:11 AM
  •  Jorge Coelho wrote:

    In the name of security, Microsoft has broken one of the golden rules that made Windows what it is today: backwards application compatibility (read the very interesting Raymond Chen's true story at http://blogs.msdn.com/oldnewthing/archive/2005/08/24/455557.aspx to get an idea how important this was to Microsoft when Windows 95 was being developed). The new security features in Vista, as they currently are, have broken compatibility with hundreds, if not thousands, of applications out there (http://biz.yahoo.com/prnews/070129/nym254.html?.v=27). This is not a good sign.

    Guess what, if your application requires Administrator rights to run, IT IS ALREADY BROKEN! It has been broken since Windows NT was introduced. You've just been getting away with shipping a broken app by virtue of the defaults in Windows.

    All UAC has done is move the cost burden away from end users trying to maintain a secure, standard user environment and on to the developers of broken applications in the first place, where it belongs. For every pain that UAC inflicts on a developer, it has already been felt a hundred times worse for anyone who has previously tried to make that application run in a secure environment. Frankly this couldn't happen soon enough.

    Friday, March 9, 2007 1:25 PM
  • In Vista, an administrator-level account is not the same as logging on as Administrator.  These have 2 very different sets of permissions.  Log on as the local Administrator and you will find you have different permissions.
    Monday, March 12, 2007 2:53 AM
  • Hello,

    For the most part, UAC only causes problems for applications that have not been developed to follow the development requirements that have been in place for years now (not saving data in program files, not assuming the user is an administrator, etc).

    I agree that there are a number of such applications on the market; however, I do not believe that justifies leaving things the same, especially since what is required of a non-admininstrative application has been documented for a long time.

    This change was going to happen sooner or later; modern windows was never designed such that all users would be running all administrative programs.

    Also, I do not feel that UAC is unreasonable. Users should be aware when they are running an administrative application, whether via a prompt or some other mechanism.

    I also don't believe this limits what you can do as a developer, except in very, very limited scenarios (such as sending fake keyboard/mouse inputs to all the programs on a computer - I see requiring software publishers to prove their identity in order to do this as a reasonable requirement).

    Most application have no business being an administrative application. The majority of the time the user will not experience UAC prompts.

    I would understand your argument better if UAC was as prominent as so many people seem to suggest that it is; however, it only rears its head when users are performing administrative tasks, which really doesn't happen all that much, and when it does, users need to know that they are entering a mode of operation that can seriously affect the way their computer works.

    - JB

    Monday, March 12, 2007 3:28 AM
  • Hello,

    What do you mean by blocked?

    The basic strategy here is:

    1- Implement your admin non-gui core code into a service

    2- Implement your non-admin gui code into an executable that you can run on the users desktop and can interact with your service, to get its status and perhaps tell it to do things

    - JB

    Monday, March 12, 2007 3:32 AM
  • How would the malware know?

    Well, this information would probably be exposed to a standard user in some fashion, so that explorer could adorn it with a different UI tag, or whatnot.

    That not being the case, it could do trial-and-error or guessing (I'm sure there would be many common system utilities that would be blessed by a large number of people).

    Second - Why trust the user?

    That's the whole point of UAC - *User* account control - it puts the control of the user's account into the user's hands.

    The system cannot through automated means determine if the user is INTENDING to launch a program or initiate an action that could potentially harm the system.

    This is why UAC is necessary and why it is so critical that the user be asked every time - the system is determining if the user is wanting to perform an action, and the only way to do this (right now) is by asking the user.

    There is no 'right' or 'wrong' answer here - the user is ALWAYS RIGHT. If they want to run some file they downloaded off the internet with admin rights, that's fine. If they are paranoid and will always click cancel when a UAC prompt pops up, that's fine too.

    UAC makes sure that the user knows that they are entering into a mode of operation that could potentially harm their computer, and if they aren't comfortable with that, for whatever reason, it gives them a chance to back out.

    It provides security in the fact that anything that the user does that does not prompt is incapable of hurting system-wide settings/data. The user can trust that if they run something that is wanting above-normal control over their computer, they will be notified and given a chance to back out.

    - JB

    Monday, March 12, 2007 3:42 AM
  • Jimmy,

    I have a question about your statement below:

    "The system cannot through automated means determine if the user is INTENDING to launch a program or initiate an action that could potentially harm the system.

    This is why UAC is necessary and why it is so critical that the user be asked every time - the system is determining if the user is wanting to perform an action, and the only way to do this (right now) is by asking the user."

    Why does the system trust the user's click on the UAC dialog, but not his double click on the application icon? I'm going to hazard a guess that the UAC elevation dialog is itself running at high privilege, and so is immune to being "driven" by a malicious (but low privilege) app. If so, why can't Windows Explorer and the other desktop components be secured in this same way?

    I'll admit that plenty of problems can and should be worked around by developers. My own company was able to remove the (pointless) need for admin privilege in our app. But it's weird to have Vista constantly asking me, in effect "Did you just click that?" It gives me a sneaking suspicion that the problem has been solved in the wrong place.

    Monday, March 12, 2007 6:34 AM
  • I'm sorry Andy and Jimmy, but this 'holier than thee' attitude (i.e.; the UAC only affects applications that break the rules) is simply NOT true and really gets on my nerves. You can't accuse me of breaking a rule that didn't exist yet! Microsoft is making the rules as it goes along, and, as far as I know, it still can't re-write history! There was no rule ANYWHERE (until Vista and the UAC) that stated that lower privilege applications should not attempt to communicate with higher privilege applications. There was no rule ANYWHERE that stated that applications requiring admin privileges cannot be added to the startup list.

    Sure, if you want a world of plain vanilla applications, where every program is either a calculator or a word processor, then by all means, go ahead and make sure the OS only runs what cannot potentially hurt it (and then be proven wrong once again). I'm all for safer OS's and applications BUT definitely NOT when you start REMOVING functionality to enforce security. This is the same as you buying a top-of-the-line sports car and then finding out it has been capped to 50 miles per hour to enforce speed limits!

    A LOT of the UAC limitations can ONLY be bypassed by digitally signing your code. This costs real money (ain't it curious that Commodo DOUBLED their retail prices now that Vista is out?), and it's not a one time thing either, you have to keep paying every year. Not only are we not made of money, as this is akin to Microsoft saying to the teenage kid who came up with a revolutionary idea: pay up, or you won't be able to a) put your idea into practice and b) you won't be able to distribute it either. This stifles innovation!!!! Can't you see it?

    In reality, the only people who trully benefits from this are Microsoft and the certificate merchants, who use scare tactics on the users to bully developers into submission!

    Wow, did I just come up with my first conspiracy theory?

    Monday, March 12, 2007 8:59 AM
  •  Jorge Coelho wrote:

    There was no rule ANYWHERE (until Vista and the UAC) that stated that lower privilege applications should not attempt to communicate with higher privilege applications.

    There was no concept of lower/higher integrity levels prior to Vista, so in that respect you are right. However there were strong guidelines recommending that privileged code (such as services) should never open windows on an interactive desktop, because of the so called shatter attack. UIPI finally plugs the gap in the window manager that allowed Shatter style attacks to work and does so in a way that minimizes impact on other applications (you can still send "safe" window messages to high priviliege apps, for example)

     Jorge Coelho wrote:

    There was no rule ANYWHERE that stated that applications requiring admin privileges cannot be added to the startup list.

    Really? So how do I start an application that requires Administrator rights from a Standard User account at startup on XP then? Answer: It can't be done. Requiring Administrator rights for anything other than a task which is administering the computer is fundamentally wrong.

     Jorge Coelho wrote:
    A LOT of the UAC limitations can ONLY be bypassed by digitally signing your code.

    Again, no. It isn't possible to bypass the majority of UAC technology. This is by design. The only thing that should have any reason to do so are accessibility tools that need to drive user input for disabled users.

    Monday, March 12, 2007 9:22 AM
  •  AndyCadley wrote:
    you can still send "safe" window messages to high privilege apps, for example

    Ah, so a user initiated drag & drop operation is not safe? If the user himself cannot drag & drop a file from Explorer into an application running with admin privileges, don't you even stop for a moment to think that something might not be right with the current UAC implementation?

    Sure, Microsoft's view on this NOW is that you should divide your application into a front end UI (running with normal privilege) and back end executive (running with admin privileges), but that is not my point. This is a new thing. Developers never needed to do this. It complicates things tremendously. It breaks hundreds, if not thousands, of applications - whatever happened to the 'backward compatibility' holy grail at Microsoft? Guess it was gone with the wind when DOT NET came out.

    Furthermore, answer me this: most installers have a 'Run application now' checkbox. As it happens, the installer MUST be running with admin privileges to do its stuff. Since privileges are inherited, any application launched by the installer ends up running with admin privileges too. Because of this, and because you cannot LOWER your privilege level, any application that interacts with the user via drag & drop will appear to be broken when launched through the installer. So, should we, application developers, deny the user the convenience of launching applications through the installer or should Microsoft change the UAC to allow applications to lower their privilege levels?

     AndyCadley wrote:
    Really? So how do I start an application that requires Administrator rights from a Standard User account at startup on XP then? Answer: It can't be done. Requiring Administrator rights for anything other than a task which is administering the computer is fundamentally wrong.

    Ok, then tell me why I need admin privileges to get performance monitoring information about running processes with PDH? Or why I need admin privileges for an application that synchronizes the clock with time servers on the Internet? Or... I could go on and on, but the problem is that far too many little things require admin privileges in Windows to work. Some of them make sense in a corporate environment, but are just plain dumb in a home environment.

     AndyCadley wrote:
    Again, no. It isn't possible to bypass the majority of UAC technology. This is by design. The only thing that should have any reason to do so are accessibility tools that need to drive user input for disabled users.

    And HERE you have proven me absolutely right! It is precisely this shortness of sight that got us where we are now with Vista and the UAC. I can assure you my applications - and those of my competitors - are NOT for disabled users, yet they still need to drive input to other applications. Just because YOU cannot imagine something, doesn't mean that somebody else might not - this is what I meant by 'stifling the innovation'.

    And you're wrong about not being able to bypass the majority of UAC technology, as even you yourself open an exception for Accessibility tools. In order for Accessibility tools - or applications like mine - to drive input to other windows, they must:

    a) Be digitally signed (see? ah-ah!)

    b) Reside in Program Files or other trusted location (this, by the way, takes the choice of where to store an application away from the user or otherwise breaks my application if it is installed anywhere else other than a trusted location).

    c) Set 'uiAccess=true' in their Vista manifests.

    P.S. Sorry if I 'sound' a bit annoyed (I am), but this is not, in any way, directed at you.

    Monday, March 12, 2007 10:01 AM
  •  Jorge Coelho wrote:
    Ah, so a user initiated drag & drop operation is not safe? If the user himself cannot drag & drop a file from Explorer into an application running with admin privileges, don't you even stop for a moment to think that something might not be right with the current UAC implementation?

    The trouble is that it's impossible to distinguish between a user initiated drag and drop operation and one initiated in code. And I don't mean difficult, I mean impossible. If a high privilege application can safely accept drag and drop operations, then it can specifiy that it can accept these. Yes this means updating the app, but the security gains from doing so are significant enough to justify it.

    It's not that I haven't stopped to think something might be wrong, it's that I've spent a lot of time figuring out why it's not....

     Jorge Coelho wrote:

    Sure, Microsoft's view on this NOW is that you should divide your application into a front end UI (running with normal privilege) and back end executive (running with admin privileges),

    No, that's not the view at all. 99% of applications do not and should never require high privileges to run. So 99% of applications never need to jump through these kind of hoops at all, they just need to be fixed such that they behave the way NT applications have always been supposed to act (it's been in the Windows Logo requirements for decades)

     Jorge Coelho wrote:

    Furthermore, answer me this: most installers have a 'Run application now' checkbox.

    Ok, pet hate time. This already breaks under numerous scenarios - RunAs, automated install scripts, per-machine deployment. It's never been a good idea.

     Jorge Coelho wrote:

    Ok, then tell me why I need admin privileges to get performance monitoring information about running processes with PDH? Or why I need admin privileges for an application that synchronizes the clock with time servers on the Internet? Or... I could go on and on, but the problem is that far too many little things require admin privileges in Windows to work. Some of them make sense in a corporate environment, but are just plain dumb in a home environment.

    Arrgh, no. You're doing the all too common developer thing of seeing the word Administrator and instantly thinking in terms of a corporate scenario. If you are developing for a home scenario, mentally replace the word Administrator with Parent and Standard User with Child.

    Changing the time: I as the Parent have restricted the amount of time my Child can play games during the day. If the operating system allowed the Child to change the time, that would be meaningless, since they can play for as long as their hearts desire by just constantly altering the clock. (As an aside, since Windows has synchronised it's clock with online time servers since XP, why bother writing an app to do it as well?)

    Performance monitoring: I think the PDH issue arises because it can monitor processes belonging to other users, which presents privacy issues, unless you bear that in mind when checking counters you'll get access denied errors. It certainly is possible to read from some performance counters under a Standard User account, because you can happily run perfmon.exe which uses pdh.dll.

     Jorge Coelho wrote:
    And HERE you have proven me absolutely right! It is precisely this shortness of sight that got us where we are now with Vista and the UAC. I can assure you my applications - and those of my competitors - are NOT for disabled users, yet they still need to drive input to other applications. Just because YOU cannot imagine something, doesn't mean that somebody else might not - this is what I meant by 'stifling the innovation'.

    It's not that I can't see reasons for wanting to automate applications. Heck I spend enormous amounts of my time doing precisely that. It's about doing so in a safe, secure way that cuts out all the malware and viruses that do no good for anyone. I'll say again, the vast majority of applications should never, ever, ever, need Administrator rights and for all those applications this is a complete non-issue. If something needs to drive Administrative applications then it absolutely should require elevation when it runs and that absolutely should require a user to confirm the danger via a UAC prompt, because it could well be doing anything.

     Jorge Coelho wrote:

    P.S. Sorry if I 'sound' a bit annoyed (I am), but this is not, in any way, directed at you.

    No offence taken. Likewise my comments are not a criticism of you or your app, they just come from a lot of experience "fixing" these kinds of LUA issues with previous versions of Windows.

    Monday, March 12, 2007 3:51 PM
  •  

    If something needs to drive Administrative applications then it absolutely should require elevation when it runs and that absolutely should require a user to confirm the danger via a UAC prompt, because it could well be doing anything.

    Any progam can be scheduled to run at logon automatically and with full elevated admin without approval. Thanks to the new Vista Task Scheduler. Here you go.

    You're doing the all too common developer thing of seeing the word Administrator and instantly thinking in terms of a corporate scenario. If you are developing for a home scenario, mentally replace the word Administrator with Parent and Standard User with Child.

    The child should not run under the administrator account, even if with UAC. It should run as a limited user, that is already the same in XP. UAC is only about protecting the "parent".

    Monday, March 12, 2007 10:14 PM
  •  MattAus wrote:

    Any progam can be scheduled to run at logon automatically and with full elevated admin without approval. Thanks to the new Vista Task Scheduler. Here you go.

    And breaks if the user kills the hung app, turns off the scheduled task, runs as a limited user, has anti-spyware software that flags this as potentially malicious behaviour or if Microsoft add any new user interaction requirement to prevent abuse of the task scheduler. This is not the way to fix applications.

     MattAus wrote:
    The child should not run under the administrator account, even if with UAC. It should run as a limited user, that is already the same in XP. UAC is only about protecting the "parent".

    I was making a point about why changing the time is a privileged operation. It's not just corporates worried about Event logs, auditing and such. Changing the time is one of the most privileged operations on a system and should absolutely be protected, regardless of who is logged on.

    Monday, March 12, 2007 10:45 PM
  • And breaks if the user kills the hung app, turns off the scheduled task, runs as a limited user, has anti-spyware software that flags this as potentially malicious behaviour or if Microsoft add any new user interaction requirement to prevent abuse of the task scheduler. This is not the way to fix applications.

    ... turns off the scheduled task : Ok, if the user does not want to run the application at logon, she can switch the task off. 

    ... runs as a limited user: the task runs at logon only for the main admin account, who installed the application, not for other users.

    ... has anti-spyware software that flags this as potentially malicious behaviour : users trust our application more than any anti-spyware

    ... Microsoft add any new user interaction requirement to prevent abuse of the task scheduler: why is this abusing the task scheduler??? There is a NEW option in the task scheduler (added by Microsoft, not by me), called "Run Elevated". It was not there in XP or 2003.  It was added since UAC was introduced in Vista. This flag has exactly the function to run scheduled tasks with elevated admin WITHOUT approval. Or you would like to approve each time your scheduled tasks run? To add a task you need elevated admin, so you can do this during installation, after asking the user.  

    This is not the way to fix applications. We are not fixing anything  We just want to run our application at logon with elevated admin for the administrator, if she wants to do that... Too much to ask? Services already do that. Our application can be installed as a service or a desktop application, it is the user's choice.

    Monday, March 12, 2007 10:59 PM
  •  Scott Cooper wrote:
    Jimmy,

    I have a question about your statement below:

    "The system cannot through automated means determine if the user is INTENDING to launch a program or initiate an action that could potentially harm the system.

    This is why UAC is necessary and why it is so critical that the user be asked every time - the system is determining if the user is wanting to perform an action, and the only way to do this (right now) is by asking the user."

    Why does the system trust the user's click on the UAC dialog, but not his double click on the application icon? I'm going to hazard a guess that the UAC elevation dialog is itself running at high privilege, and so is immune to being "driven" by a malicious (but low privilege) app. If so, why can't Windows Explorer and the other desktop components be secured in this same way?

    I'll admit that plenty of problems can and should be worked around by developers. My own company was able to remove the (pointless) need for admin privilege in our app. But it's weird to have Vista constantly asking me, in effect "Did you just click that?" It gives me a sneaking suspicion that the problem has been solved in the wrong place.

    Hello,

    Excellent questions and observations!

    The UAC prompt is trusted to ascertain the intent of the user for two reasons:

    1- It is running inside a trusted, secure environment that prevents it from being driven by another application

    2- Essentially Windows ITSELF is asking this question directly of you, bypassing any other application

    So ... why can't Windows Explorer/Desktop be trusted the same way?

    Well, Windows Explorer is a program, it is not part of the operating system. To Windows, it is no different than any other program you are running. Windows is not designed to trust one application running on your desktop more than another. UAC gets around this by seperating different privileged applications from each other, but explorer is designed to work with all the other applications on your computer, not be completely seperated from all of them.

    Essentially, UAC is not asking "Hey, did you just click that?". Windows could be made to know with a high degree of certainty where you clicked your mouse or what key you pressed. Windows also knows what programs try to do after you click something.

    What Windows DOES NOT know is if you INTENDED for the program to take certain actions AFTER YOU CLICK THE MOUSE.

    UAC is telling you, "Hey, Program X is requesting complete control over your computer. It could do some pretty nasty stuff. I realize that you just clicked the mouse and all, but I just want to make darn certain that you know that Program X is going to have complete control over your computer from this point on, that you did indeed start program x (because I can't tell that for certain either), and that you're OK with that."

    As for UAC being implemented in the wrong level, I would disagree... UAC needs to be implmented inside core Windows and outside of the programs-realm. I DO, however, believe there are better ways to go about doing this than a UAC prompt :).

    Although it would not be a good thing to leak system-level decisions into program-land, as would be the case with a privileged explorer, I would very much like to see Windows start to work user intent into the UI and privilege models inside the base OS, and then use that to determine user intent instead of a UAC prompt.

    In fact, I think UAC should be made much more granular ... I don't think it should be admin vs. non-admin, I think it should unlock very specific privileges, only the least amount of privilege that needs to be unlocked in order to carry out an action.

    - JB 

    Monday, March 12, 2007 11:31 PM
  •  MattAus wrote:

    You are right, but the malware is running not elevated.... so it should not be able to run Command Prompt elevated.

    I only approved that Windows startup/shell can do that automatically.

    So the malware installs a shell extension and then runs the elevated command prompt :).

    Monday, March 12, 2007 11:45 PM
  •  MattAus wrote:

    If 'blessing' is such a security hole, why can services be blessed to run with full elevated admin, without repetitive approval?

    For the same reason you don't have to bless an API to run privileged.

    Services are essentially an extension to the operating system. The are providing functionality that is to be implemented at high privilege but not EXPOSE such prilege to the lower-privileged applications (and this the users) that are composed of them.

    Applications are meant to DIRECTLY carry out actions on behalf of the user. Most of the time the user isn't expecting an application to have full access to their computer in order to cary out their actions. When an application DOES want full access to their computer, UAC is there to make sure that the user is intending for this to happen.

    - JB

    Monday, March 12, 2007 11:51 PM
  • What prevents a malware to install itself as a service and harm the system? Once the administrator approves an installation, the malware has full access to the system. And no repetitive approval is required, is it? In the same manner, I want to be able to run an application always elevated, without always approving. Eg QuickBooks. Eg Regedit. Why not? I (the user) want to approve that.  If that is not OK, why giving the ability to run applications elevated in the task scheduler then. Sorry, it does not cut it.

    Tuesday, March 13, 2007 12:24 AM
  • Jorge: 

    I agree. 

    My problem occurred with Office 2007 & Vista Ultimate 64 bit. 

    Which part of the Micro$oft team should be fired, the Vista team or the Office 2007 team? 

    I want a secure OS. 

    The marketing dept at Appple that created the UAC spoof hit the nail on the head. 

    I am a user, not a developer.  I hope you, the developers, or Microsoft find a soltion, soon. 

    Sincerely,

    edx15

     

    Tuesday, March 13, 2007 6:00 AM
  •  

     MattAus wrote:

    ... Microsoft add any new user interaction requirement to prevent abuse of the task scheduler: why is this abusing the task scheduler??? There is a NEW option in the task scheduler (added by Microsoft, not by me), called "Run Elevated". It was not there in XP or 2003.  It was added since UAC was introduced in Vista. This flag has exactly the function to run scheduled tasks with elevated admin WITHOUT approval. Or you would like to approve each time your scheduled tasks run? To add a task you need elevated admin, so you can do this during installation, after asking the user.  

    Remember, I'm not familiar with your application. In some circumstances it may well be the right thing to do (though I'd still offer the user a choice, it is preferable, where possilble, to avoid running elevated applications for extended periods of time). The probelm with the task scheduler is that people are already starting to suggest using it to try and make UAC situations just go away, by launching executables at startup that sit around running elevated rather than taking a LUA-aware approach. That is what I'd call abusing the Task Scheduler and that will eventually lead to Microsoft changing the way tasks are created to restrict this.

    Tuesday, March 13, 2007 10:42 AM
  • Exactly! By installing itself as a service, the malware has full access to the system, without the need for UAC prompts other than the one you get at install... so why do normal applications have to suffer when UAC protection can be so easilly by-passed? Suddenly we all have to divide our applications into service and front end components?! For what?! What is REALLY accomplished by this if all it takes for malware to take over your system is a simple Yes reply to a UAC prompt ONCE?

    Of course, my question still is: do services need to be digitally signed to run on Vista? Anybody knows this?

    Anyway, what is happening now is the direct result of Microsoft enforcing security by locking the bad guys together with the good guys. Developers still need the functionality they are now being denied, so they will bend the rules and use ANY and ALL work arounds they can find (like the Task Scheduler thing) to get their applications working as intended. Developers, on the most part, are not unreasonable people - if they're doing this is because Microsoft gave them no choice. So the problem is with the current UAC implementation, which is flawed because it denies the functionality needed to run applications properly!

    Tuesday, March 13, 2007 1:56 PM
  •  Jorge Coelho wrote:

    Exactly! By installing itself as a service, the malware has full access to the system, without the need for UAC prompts other than the one you get at install... so why do normal applications have to suffer when UAC protection can be so easilly by-passed? Suddenly we all have to divide our applications into service and front end components?! For what?! What is REALLY accomplished by this if all it takes for malware to take over your system is a simple Yes reply to a UAC prompt ONCE?

    Not full access. Services can't access the interactive desktop and their rights are still defined by which user account they're running under (SYSTEM, LocalService, NetworkService or other). What's more it constrains the number of places that "always running elevated" processes can be started from, making it easier for anti-virus/spyware software to detect and remove the threat. There are no silver bullets that can end the problems for all time and each time you put a barrier in the way, someone will try to find a way around it. It doesn't mean you just give up trying and let the bad guys win.

     Jorge Coelho wrote:

    Of course, my question still is: do services need to be digitally signed to run on Vista? Anybody knows this?

    No. I've just tried and it works fine.

    Tuesday, March 13, 2007 4:15 PM
  •  AndyCadley wrote:

    It doesn't mean you just give up trying and let the bad guys win.

    Of course not - as long as it's not at the expense of the good guys.

     AndyCadley wrote:

    No. I've just tried and it works fine.

    Thanks!

    Tuesday, March 13, 2007 4:26 PM
  • Hi Jimmy,

    Making UAC more granular sounds like a good idea in principle. The generalized warnings that are issued at present can be pretty alarming!
    Tuesday, March 13, 2007 6:44 PM
  • Services can't access the interactive desktop and their rights are still defined by which user account they're running under (SYSTEM, LocalService, NetworkService or other).

    Services can start processes in the active user session. I do not know if UAC would show up in that case (still need to test this), but my guess is not, since services run at a higher integrity level (system integrity level).

    Most services run under the local system account which is allowed to perform many of the tasks administrators require approval for.

    UAC is a great concept. But it seems to me that UAC in Vista 1.0 is just not complete enough. I am afraid most users will turn it off. I think UAC should be more granualar, eg now it is just on or off, once you approve you approve EVERYTHING. For instance just to copy files to "program files" you need to approve so you are also approving EVERYTHING else.

    You are also unable to approve an application once and forever, like you do with a firewall.

    I mean think from a user perspective: why do you have to approve your copy of QuickBooks everytime it starts? I already told you I am OK running this application, why are you asking me EVERYTIME? Where is the "do not ask again" option?

    In the future the amount of approvals MAY reduce, as applications are becoming more Vista compliant and will isolate the functions that require approval. But that is not even easy to do. There is no API, you need to create a separate process, or a COM object.... it will take a long time....

    Still if I have my favourite backup application running that wants to create a volume shadow copy, why do we have to approve all the times??? Please give me my "do not ask again" option!!!!

     

    Tuesday, March 13, 2007 11:07 PM
  • Exactly! By installing itself as a service, the malware has full access to the system, without the need for UAC prompts other than the one you get at install... so why do normal applications have to suffer when UAC protection can be so easilly by-passed? Suddenly we all have to divide our applications into service and front end components?! For what?! What is REALLY accomplished by this if all it takes for malware to take over your system is a simple Yes reply to a UAC prompt ONCE?

    Because UAC puts the user in control. Even if they run malware, accept the prompt, and it ends up hosing their system, it was THEIR CHOICE, and that is a choice that they DID NOT HAVE BEFORE.

    As you point out, the ONLY way a service, scheduled task, etc. can be installed is if the user allows it.

    If the user chooses to run a program with privilege, could it hose the system? Sure enough.. Will UAC stop it from hosing the system after the user allows it to run? Nope.. Does the fact that the user may allow a program to hose their system constitute a design flaw in UAC?

    NO!

    UAC IS NOT DESIGNED TO PREVENT MALWARE. It is designed to put control of the system into the user's hands, where it belongs, as opposed to at the whim of whatever software happens to run on the user's computer (whether malware or not).

    UAC is not an attempt to limit how you develop software nor an attempt to combat malware. It is simply an effort to set things right in Windows where they were not right before - mainly, to ensure that administrative tasks are initiated by the user (and not a program on its own behalf), that the user understands that programs that perform administrative tasks should be trusted because THEY COULD HOSE THEIR SYSTEM, and that non-administrative tasks should NOT run with the capability to perform administrative tasks.

    As for the service issue, I don't think I made myself clear.

    I *DO NOT* recommend that developers turn all of their administrative programs into services. This is a very bad idea. If you have an administrative tool that the user runs on-demand to perform an administrative action, it should be implemented AS AN APPLICATION and will display UAC prompt.

    What I meant was that if you have some code in an app that is meant to 1) start when the computer starts 2) encapsulate some sort of action that needs to be implemented in privileged code and 3) exposes that action [in a secure, non-privilege-leaking way I hope] in some form to other code (whether inside that same module or not), then what you actually have *IS* a service, and should be implemented as such.

    What I would like to make absolutely clear, to all developers on this forum, is that any action that you take that results in an administrative .exe being ran on the user's computer without prompting the user for permission when it starts [including registering a service and a scheduled task] OPENS A POTENTIAL HOLE in the integrity of the user's system, by creating an environment where the user no longer has control under certain circumstances.

    Sure, it is possible and even easy for programs to do this (i.e. scheduled task and services). But, YOU MUST BE VERY CAREFUL to ensure that if you decide this is what you are going to do, that you keep the user's security at heart.

    Because, when the user installs your program and they get the UAC prompt, when they click that Continue button they are expressing their trust in YOUR PROGRAM, knowing that your program COULD do nasty things to their system. So it's up to you to not put their computer in a worse security situation that it was before they clicked that button.

    For example:

    - Administrative .exe's that run without user interaction or without prompting (ie services, scheduled tasks) should be in a location that cannot be written to by non-admins

    - There should be no way for ANY UNPRIVILEGED PROGRAM (including YOUR unprivileged programs) to start a privileged process that does not prompt the user for permision to run

    - There should be no way for ANY UNPRIVILEGED PROGRAM (including YOUR unprivileged programs) to talk to a privileged application and convince it to perform a privileged action that the unprivileged code cannot do itself.

    (A good example of this last point would be creating a service that allows one of your programs to write to restricted areas of the registry or filesystem. You can't do this because there is no way your service can restrict access to just your privileged program. If your service/privileged code exposes some functionality to unprivileged processes, even if you try to limit who can use this functionality, you MUST assume that malware can access that functionality as well).

    I just can't stress this enough ... UAC is put in place to put the user in control of their system. Once the user has trusted your application by allowing it to run privileged, you HAVE THE POWER TO ABUSE THIS ... but you also have an OBLIGATION to the user to KEEP THEM IN CONTROL by not subverting the control that UAC gives the user.

    Sure, malware will still be out there and it will indeed subvert this control if it can convince the user to trust it by launching it via a UAC prompt. But YOU are not writing malware, and it is a totally facetous argument to say "malware will do it, so there's no reason I shouldn't" -> because the USERS are now in control, even if they decided to run that malware, and they now have the choice to stop software that they don't want to run on their system, regardless of whether it is malware or not :).

    Anyway, what is happening now is the direct result of Microsoft enforcing security by locking the bad guys together with the good guys. Developers still need the functionality they are now being denied, so they will bend the rules and use ANY and ALL work arounds they can find (like the Task Scheduler thing) to get their applications working as intended. Developers, on the most part, are not unreasonable people - if they're doing this is because Microsoft gave them no choice. So the problem is with the current UAC implementation, which is flawed because it denies the functionality needed to run applications properly!

    UAC certainly changes the developer scene quite a bit. This is not meant to lock anyone out, good guys or bad. This is only meant to put the user in control of the applications that run on their computer.

    I am confident that at a design/feature level, everything developers could do before, they will still be able to do going forward, even if it means they have to learn new ways of implementing those features. And there are many people on this forum who will help developers to do that.

    I am also confident that thanks to UAC, software being developed will end up being more secure, which will benefit not only that developer's customers, but all Windows customers as a whole.

    - JB

    Wednesday, March 14, 2007 12:57 AM
  • The UAC concept is great, and should have been implemented ages ago.

    I guess it is the way it was implemented in Vista that is not 100%, maybe becuase this is just version 0.9?

    Some issues:

    - I have to run ALL installers elevated, just because they need to copy to the program files directory? Eg to install "Paint" I need to run in elevated mode? Why? I do not expect Paint to perform any change to the system, beside copying its files to "program files"

    - Programs are unable to write to their Program File directory unless they run elevated. I mean, I install application A to c:\program files\A\ shouldn't application A be granted writing access to c:\program files\A\ (note only application A).

    - UAC is just OFF or ON. It should be more granular.

    - I do not want to approve the same application/task again and again.

    Think from user's perspective and usability. There could be a technical reason behind each point, but technical issues are there to be resolved. After a few weeks of running Vista I find myself clicking continuously on dialog boxes, and I am clicking always for the same reason/task! What the... The altrernative: switch off UAC, which, obviously,I do not want.

    It should not be an alternative. Usability vs. Security. I need both.

    Wednesday, March 14, 2007 1:59 AM
  •  MattAus wrote:

    I have to run ALL installers elevated, just because they need to copy to the program files directory? Eg to install "Paint" I need to run in elevated mode? Why? I do not expect Paint to perform any change to the system, beside copying its files to "program files"

    Program files is a shared resource. Any time you modify a shared resource you potentially alter the behaviour of the computer for other users of the system. That makes modifying files in Program Files a privileged operation and thus requires a UAC prompt.

    If your application is low impact and should be installable by limited user accounts then you can make a per-user install that installs into the users AppData folder (as per the logo guidelines) without requiring Administrator approval.

     MattAus wrote:

    - Programs are unable to write to their Program File directory unless they run elevated. I mean, I install application A to c:\program files\A\ shouldn't application A be granted writing access to c:\program files\A\ (note only application A).

    Again, its a shared resource, so storing data in it causes a whole raft of issues - file locking under Fast User Switching/Terminal Services, failure to run under Limited User Accounts (even on NT, 2000, XP), weird Roaming Profile behaviour, etc.

    Resources don't belong to applications, they belong to users. If your application needs to store data, use the AppData folder the way it's intended.

     MattAus wrote:

    - UAC is just OFF or ON. It should be more granular.

    Grafting an entire new security layer onto Win32 would take decades, even if it is possible at all. Given how few developers seem capable of correctly dealing with the situation as is, do you really think it would get easier if they had more scenarios to consider? In any case, how would all those different permissions be presented to my Granny in a way she'd understand without a full course on programming Win32?

    Worse still, even after you'd done all that, developers would still have to write applications that the most limited accounts could run, so you'd still be developing to the same restrictions you have today.

     MattAus wrote:

    - I do not want to approve the same application/task again and again.

    Then pester the vendor to fix their application so that you never have to approve it at all. If it's your app, then fix it yourself. The way to reduce prompts is not to introduce security holes by automatic elevation, it is to fix the applications that unnecessarily require elevation in the first place.

    Wednesday, March 14, 2007 5:58 AM
  • Then pester the vendor to fix their application so that you never have to approve it at all. If it's your app, then fix it yourself. The way to reduce prompts is not to introduce security holes by automatic elevation, it is to fix the applications that unnecessarily require elevation in the first place.

    Let me start with Microsoft: Regedit, Task Scheduler, Event Viewer, etc, Running Command Prompt as Administrator, Running Notepad as Administrator, Running ANY Microsoft Program as Administrator... but I did login as Administrator of this computer, didn't I. 

    I did select "Running Notepad as Administrator", didn't I , so why are you asking me to confirm???? Does Vista think I am stupid or something?

    So if I need to administer my computer for a few minutes, should I turn off UAC and then back on? Or click 100 times on the same dialog?

    Anyway, I respect your opinion, we will probably never agree

    I still think UAC has a long way to go, we'll see what the future brings us.

    take care.

    Wednesday, March 14, 2007 6:31 AM
  •  MattAus wrote:

    Anyway, I respect your opinion, we will probably never agree

    I guess not, as I'd consider those types of elevations fundamentally different to those of applications that can't run normally, though I can see where you are coming from.

    Note, that if elevation dialogs bother you that much you can always go into the Local Security Policy editor and change the UAC policy (Local Policies -> Security Options -> User Account Control: Behaviour of the elevation prompt....) to "Elevate without prompting". It's slightly less secure, but still gives you most of the benefits of keeping UAC enabled if you're sensible enough not to run random executables.

    Wednesday, March 14, 2007 7:51 AM
  • Hi,

    I' ve been reading this thread, and I must agree that UAC is at least "a work in progress". User impact is terrible. People clicking yes ALL THE TIME... after 20 clicks, they will answer yes on anything, even deleting all his documents (which they wont be in program files). I guess the change in explorer to confirm file copy-move-deletion has changed by this fact.

    On the other side, someone has verified that, if a program is NAMED "install", "setup" "update", it will run as administrator without asking anything, just because "compatibility" with old installers?... If this is true what is the point in UAC?

    I'm deciding how to deploy Vista in my network, and as far as I go, due to virtualization (another nightmare) and  this issues, I will do it with UAC turned OFF. I have good security policies, and also physical security in place, with 1 incident (in a web server) in 5 years now. So this nightmare will not be used in our network (if is possible to completly turn off UAC and vistualization).

    The other features of Vista are awesome, but UAC is wrong. All this discussion of how can a program be attacked, are certainly true, but the solution is not to ask everytime if this is correct. This is common sense: if you need to take 2 decisions a day you will probably take some time to think and choose the right one, but if you have to take 300 decisions a day, you will probably make a mistake. Assuming that asking for administrator privileges is a threat, is like assuming that trying to write in the hardisk is a threat too. In fact in corporate environments, the users are not administrators of their computers, even that, they have to click A LOT to perform THE SAME WORK, they were doing... I prefer my antivirus heuristics to detect a potential threat that this UAC implementation. Also the lack of accept only ONCE (ie. blessing) is pointless. I can think a lot of ways to do that, like the operating system signing and hashing the program that you (the user) has blessed, and to only be possible to bless managed code programs, installed by a proper controlled situation. It wont be perfect, but this UAC implementation is not also. Also viruses always infect setup programs, and they will run as admin...

    I can foresee an URGENT service pack that will put this straight, probably with a better balanced solution.

    In the mean time, we do have internal applications that need administrator privileges, and we wont change them now. Calling a COM object will need this privilege and we also use several features and controls that can't be included in a Service. Another reason to disable UAC.

    The main point of Vista is to enable you to do your work in a better way... UAC gets in the middle of that, and if enabled, my users will choose to keep XP pro.

    Cheers,

    Mariano.

    Wednesday, March 14, 2007 11:47 AM
  •  MarianoC wrote:
    I' ve been reading this thread, and I must agree that UAC is at least "a work in progress". User impact is terrible. People clicking yes ALL THE TIME... after 20 clicks, they will answer yes on anything, even deleting all his documents (which they wont be in program files). I guess the change in explorer to confirm file copy-move-deletion has changed by this fact.

    It doesn't matter if the user always clicks Yes.

    They are no worse off than they were under XP when running as Administrator. However, all the applications that know they don't need Administrator rights will still be running as limited users. This means that an exploitable bug in, for example, Outlook can't completely destroy their system because Outlook doesn't have enough permissions. The real advantage of UAC is not that it prompts for elevation, it is in the extra security it offers to all the applications that never need elevation in the first place.

     MarianoC wrote:
    On the other side, someone has verified that, if a program is NAMED "install", "setup" "update", it will run as administrator without asking anything, just because "compatibility" with old installers?... If this is true what is the point in UAC?

    That's just plain wrong. If something is detected by the Installer Detection as a legacy installer, such as somethig named setup, then it will ALWAYS prompt for elevation.

     MarianoC wrote:
    I'm deciding how to deploy Vista in my network, and as far as I go, due to virtualization (another nightmare) and  this issues, I will do it with UAC turned OFF. I have good security policies, and also physical security in place, with 1 incident (in a web server) in 5 years now. So this nightmare will not be used in our network (if is possible to completly turn off UAC and vistualization).

    Virtualization is designed to fix issues with applications that would otherwise fail under UAC. If you disable virtualization the number of issues is likely to go up, not down. You can disable it for individual applications if they still don't work, but you will likely have to apply other mitigations such as amending file/registry permissions to make it function correctly.

    Of course you could just turn of UAC entirely, but then you are throwing away the number one benefit of switching to a much more secure platform than XP.

     MarianoC wrote:
    The other features of Vista are awesome, but UAC is wrong. All this discussion of how can a program be attacked, are certainly true, but the solution is not to ask everytime if this is correct. This is common sense: if you need to take 2 decisions a day you will probably take some time to think and choose the right one, but if you have to take 300 decisions a day, you will probably make a mistake.

    You are absolutely right. The solution is never to have to ask in the first place, the way to do this is for applications to work with the Windows security mode, not against it.

     MarianoC wrote:
    In fact in corporate environments, the users are not administrators of their computers, even that, they have to click A LOT to perform THE SAME WORK, they were doing...

    They shouldn't have to. If an application runs as a standard user on XP it will work under UAC without elevation. The limited user scenario on Vista is significantly better than under XP. Do you actually have any examples of where this is no longer the case, or is it just wild speculation?

    Wednesday, March 14, 2007 12:05 PM
  • Making UAC more granular sounds like a good idea in principle. The generalized warnings that are issued at present can be pretty alarming!

    Agreed.

    A good example is deleting an item from the all users desktop.

    In order for this to happen, Explorer has to run a process with full admin rights to the system.

    There is no reason for this - Why give something the ability to format hard drives, load device drivers, etc, when it really just needs to be able to delete an item off of the all users desktop?

    Thursday, March 15, 2007 2:48 AM
  •  MattAus wrote:

    The UAC concept is great, and should have been implemented ages ago.

    I guess it is the way it was implemented in Vista that is not 100%, maybe becuase this is just version 0.9?

    Some issues:

    - I have to run ALL installers elevated, just because they need to copy to the program files directory? Eg to install "Paint" I need to run in elevated mode? Why? I do not expect Paint to perform any change to the system, beside copying its files to "program files"

    - Programs are unable to write to their Program File directory unless they run elevated. I mean, I install application A to c:\program files\A\ shouldn't application A be granted writing access to c:\program files\A\ (note only application A).

    - UAC is just OFF or ON. It should be more granular.

    - I do not want to approve the same application/task again and again.

    Think from user's perspective and usability. There could be a technical reason behind each point, but technical issues are there to be resolved. After a few weeks of running Vista I find myself clicking continuously on dialog boxes, and I am clicking always for the same reason/task! What the... The altrernative: switch off UAC, which, obviously,I do not want.

    It should not be an alternative. Usability vs. Security. I need both.

    I agree that these are technical/implementation limitations, as opposed to design/architectural limitations, and they are begging to be improved upon.

    I do not thing UAC in its current form is unusable. Most people don't do administrative things that often, and when they do, they need to know that they are entering a mode of operation where the program that they are unlocking can potentially hose their system.

    However, I think that UAC functionality can be fleshed out and better integrated with the OS, resulting in a better approval mechnism than a prompt as well as much more granular "unlocking of privilege" than all-vs-none.

    In my opinion, UAC is kind of only 50% as good as I think it should be. It does a beautiful job of keeping applications that don't need privielge from having it. Unfortunately, it doesn't do nearly enough in limiting how much privilege applications that do need privilege receive.

    For example, most applications that need privilege don't need to load device drivers... why let them?

    Of course, as another poster mentioned, these changes would probably change the way we program software for windows in a rather radical way - however, personally, I think it could be done on the current Windows code base, although I haven't really thought too much about the implications of backwards compatability - I suppose in the worse case, backwards compatability could be done by keeping the current Vista-style behavior for legacy applications.

    Fun to think about, in any case :)

    - JB

    Thursday, March 15, 2007 3:00 AM
  • I agree 100%. The inability of applications that require elevated privileges to accept dropped files from explorer is a joke. This makes working with Vista a tiresome and awkward for me. I’m considering disabling UAC completely because of this one issue. The documentation on the issue is a poor crop at best.

    Friday, March 16, 2007 10:57 PM
  • Visual Studio, which requires to be run as admin, can not accept dropped files from explorer. Is MS breaking the rules or is UAC simply a pain in the proverbial?

    Friday, March 16, 2007 11:03 PM
  • Hey Andy,

     

          I'm not against the very basic concept of UAC. But I can see it is a work in progress, and with the existing software today, it is a nightmare. Now let me clarify some points (I don't know how to quote your replies so, I will number them)

     

    1.- You said that the user answering YES always, doesn't matter? Well, what about blessing the app or adding a YES TO ALL... saying that is like tell me to disable UAC. In the other hand is true that answering always YES will behave like XP Pro as administrator, but with three hundred clicks a day... Outlook destroying their system... well, now I have strict policies centrally enforced to autoupdate antiviruses in servers and workstations, why are you supposing that asking to elevate will be better than that... also the user will answer YES 90% of the time... the trick is to keep the threats OUT of my network and enforce physical internal security. Now, talking about a home user, with UAC, he must: update antivirus software and anti spyware software as always, plus answer YES to everything. I really don't see the point. UAC will be very better implemented in the future, I have no doubt. To be something usefull, it should analyze the intended elevation 100 times better than now, and ask the user in a very potential threat issue, and applications should be securely blessed. As I have said, I prefer antivirus heuristics than current UAC, even they are very different things.

     

    2.- You're right about the compatiblilty in "setup", "install" et al. We have run tests also. Elevation is always asked for, but virtualization is disabled.

     

    3.- I'm very familiar with what virtualization does, but is bad implemented. Put plain simple, it redirects write operations to protected areas, such as HKLM registry and program files directory to the virtualstore in the users local profile. Well, it does not redirect some reads, and almost all applications virtualized fail: they still find deleted files in protected locations, they are not notified of changes in files, etc. We have successfully converted a small internal app to vista, and beleive me, it took hundreds of development hours, just to make it run as it does in XP Pro.

     

    4.- Even if you try to work with windows security mode, vista has also changed a lot of behaviors, for example, now the debugger detects thread stack corruption from another thread and a lot of COM interop apps, now pop up the debugger. Even managed code runs different from what it used to. And I can assure you that the security requirements will be more granular in the future and, that code that today don't need to run elevated, tomorrow may require it. Today's implementation assigns the security "integration level" at process startup, and you can't elevate later, so the "best practice" today is to separate code in different processes and put a nice shield icon in button and call it from there. That means create more executable files for your app. Now, if tomorrow some operation requieres an elevated integration level, or if integration levels change, you'll need to change your program again... this does not sound good, does it? At least the .NET framework should handle it more transparent... which I think will became true in the future. Today is a big problem.

     

    5.- Yes I have some examples. The most annoying is WinRAR. It doesn't work as expected even if elevated, the context menus don't work, and every time you click a compressed file to open it, you must say YES and elevate. I'm making an internal list, it's not finished, but what I'm seeing is that almost all shareware apps don't work or require elevation. Yes, I know the answer: that apps where bad constructed and never respect the least privilege pattern... bla bla bla... now, that "bad" constructed app, has sold some millions of copies and used to work perfectly with XP Pro... and never MOLESTED the users, as it does today... hey wait, I have more examples...powerpoint 2003 requires elevation... as most of the office 2003 suite... it's really nice to say YES every time I open it... also is real nice to say YES every time I want to change my monitor resolution... Is nice not to be able to drag and drop between elevated and nonelevated apps...

     

    Now, I don't intend to be offensive, just joking a little. Don't get me wrong, I like the UAC concept, I don't like the actual implementation. It sounds to me that they were in a rush and want to include UAC at all costs. I'm sure it will be better implemented in future releases. It can be done in a much more smarter way with far lower impact to the end user, but I'm sure that it will require two or three years of development, they couldnt afford at this time. I hope, wish, beg, that some of these mistakes will be corrected so we can foresee some reasonable plan to implement Vista!

     

    Cheers,

     

    Mariano.

     

    Tuesday, March 27, 2007 4:22 PM
  • Hey you are not alone.  Whoever at Microsoft came up with the UAC should be fired! What's a half bake design. No wonder Apple made fun of this stupid idea.  I can't believe that Microsoft with that many smart people around to let something this stupid went out with Vista.

     

    For now, turn the darn thing off will make Vista more usable.

     

    Saturday, July 28, 2007 12:41 AM
  •  

     AndyCadley wrote:

     
     MattAus wrote:

    - I do not want to approve the same application/task again and again.


     


    Then pester the vendor to fix their application so that you never have to approve it at all. If it's your app, then fix it yourself. The way to reduce prompts is not to introduce security holes by automatic elevation, it is to fix the applications that unnecessarily require elevation in the first place.

     

     

    I totally agree that the correct solution is to have the vendor fix their application.

     

    So, when is Microsoft going to put out a version of VB6.exe that will operate correctly under Vista, i.e. not require elevation and notifying me that it is from an "unidentified publisher"?

     

    After all, it is being supported into 2008.

    Monday, July 30, 2007 11:35 PM
  • VB6 is in extended support, you won't see new updates. Support for it on Vista is limited to the fact that it has been tested and confirmed to work and Microsoft will therefore aid you in resolving issues running it on that platform - the fact that doing so may require elevation is largely irrelevant.

    Tuesday, July 31, 2007 9:21 AM
  • "I totally agree that the correct solution is to have the vendor fix their application."

     

    One would think that Office 2007 32 bit could paly well with Vista Ultimate 64 bit. 

     

    But nooooo.  UAC reared its ugly head. 

     

    Solution:  reformat, install Vista Ultimate 32 bit

     

    edx15

    Sunday, August 5, 2007 11:19 AM
  • UAC is a nightmare for me. I completely decided to turn it off after being asked if i want to proceed many times. However, i still can't change some protected registry keys and default script engine to cscript.

     

    it's really ridiculous.

     

    Monday, August 6, 2007 7:50 PM
  • I think you need to log on as "administrator", which different from an account with administrator privileges, to make the changes you want to make. 

     

    edx15

    Thursday, August 23, 2007 12:49 AM
  • I am running Vista64 and cannot run Office 2007 unless I turn off UAC and run as an administrator.  Been doing it since March.  I have all of the updates and registery changes required by Microsoft since March and it still the same.  Other have said they have been able to reload the OS and solve the problem.  This should not have to be the solution.  Anyother ideas?  So much for the great security in Vista.

    Thursday, September 6, 2007 4:52 AM
  •  Jimmy Brush wrote:

    How would the malware know?

    Well, this information would probably be exposed to a standard user in some fashion, so that explorer could adorn it with a different UI tag, or whatnot.

    That not being the case, it could do trial-and-error or guessing (I'm sure there would be many common system utilities that would be blessed by a large number of people).

    Second - Why trust the user?

    That's the whole point of UAC - *User* account control - it puts the control of the user's account into the user's hands.

    The system cannot through automated means determine if the user is INTENDING to launch a program or initiate an action that could potentially harm the system.

    This is why UAC is necessary and why it is so critical that the user be asked every time - the system is determining if the user is wanting to perform an action, and the only way to do this (right now) is by asking the user.

    There is no 'right' or 'wrong' answer here - the user is ALWAYS RIGHT. If they want to run some file they downloaded off the internet with admin rights, that's fine. If they are paranoid and will always click cancel when a UAC prompt pops up, that's fine too.

    UAC makes sure that the user knows that they are entering into a mode of operation that could potentially harm their computer, and if they aren't comfortable with that, for whatever reason, it gives them a chance to back out.

    It provides security in the fact that anything that the user does that does not prompt is incapable of hurting system-wide settings/data. The user can trust that if they run something that is wanting above-normal control over their computer, they will be notified and given a chance to back out.

    - JB

     

     

    OKAY, IF THE WHOLE POINT OF THE UAC IS TO PUT THE CONTROL OF THE USER'S ACCOUNT INTO THE USER'S HANDS, THEN MY HANDS CHOOSE NOT TO CLICK A BOX VERIFYING WHAT I "ALREADY" TOLD WINDOWS TO DO.

    IMAGINE HAVING TO EXPLAIN TO YOUR BOSS WHY YOU HAVE TO DO EVERYTHING TWICE, I'M SORRY THAT DON'T CUT IT IN MY WORLD. IF IT'S ACCEPTABLE IN YOUR WORLD TO DO EVERYTHING TWICE, MY EMAIL ADDRESS IS.........

     

    I GUESS THE PEOPLE AT MICROSOFT ARE USED TO DOING EVERYTHING TWICE. LET'S TAKE A LOOK SHALL WE, WHICH IS BETTER WIN95 OR WIN95B, WHICH IS BETTER WIN98 OR WIN98SE, WHICH IS BETTER WINXP OR WINXP SP2. SO OBVIOUSLY THE VISTA EXPERIENCE MUST BE BETTER, YOU GET TO DO EVERYTHING TWICE.

     

    ALL OF THIS IS MOOT. ARGUE AS YOU WILL, UAC GOOD? UAC BAD! I DON'T KNOW ANYONE THAT IS GOING TO SIT THERE AND PUT UP WITH HAVING TO CONFIRM EVERY ACTION THEY TAKE. THE UAC IS DEAD, WHETHER MICROSOFT WANTS TO ADMIT IT OR NOT,FRUSTRATION WILL PREVAIL AND ANY SMART USER WILL DISABLE IT IMMEDIATELY. FOR THOSE WHO WORK IN ENVIRONMENTS THAT WON'T ALLOW FOR IT TO BE DISABLED, YOU HAVE THE PERFECT EXCUSE TO TAKE LONGER TO DO YOUR JOB, SIMPLY TELL YOUR BOSS THAT IT'S MICROSOFTS FAULT FOR MAKING YOU CLICK TWICE EVERYTIME YOU TRY TO DO ANYTHING. IN THE LONG RUN THE UAC WILL NOT HAVE PROTECTED ANYTHING EXCEPT MICROSOFT, BECAUSE AS I SEEN IT POSTED HERE IN THIS THREAD, WE WILL DISABLE IT AS MICROSOFT INTENDED US TO AND THEN MICROSFT WILL CLAIM THAT IF EVERYONE WOULD JUST USE THE UAC THESE PROBLEMS WOULDN'T EXIST.

     

    I GUESS WE ALL COULD BE THANKFULL THEY HAVEN'T CAME OUT WITH A UAC FOR THE UAC. OH MAN I JUST CAUGHT A GLIMPSE OF MYSELF SITTING IN FRONT OF A MIRROR CLICKING "ARE YOU SURE?" FOR AN ETERNITY.

    Tuesday, September 11, 2007 7:04 PM
  • What I find the most disturbing is that with UAC I just can not open a C# or C++ file with Visual Studio if I run Visual Studio with admin privileges which I must do because otherwise debugger refuses to work.

    If I double-click a VS 2005 solution file, Visual Studio starts but says the file I've tried to open does not exist. LOL?!

    Tuesday, September 11, 2007 8:31 PM
  • Since this is a developer forum the entire topic is leaving me non-plussed.  I have been seeing all sorts of comingling of the concepts of UAC and Integrity Levels which are not the same thing.  Integrity levels are protecting the data itself which is why you cannot drag and drop between programs when one is elevated and the other is not.  That example is not a UAC example to begin with.

     

    Next, do not forget that as developers you are using the system in ways that are going to require Administrative access regularly and this is not the normal user's experience.  The average user is not firing up regedit on even a monthly basis.  Does anyone really question why starting regedit is a restricted action?  Really?  What really terrifies me on some of these examples are the systems administrators that are upset with UAC because they have internal apps that require Administrative permissions.  Seriously?  I cannot imagine a legitimate corporate secrity policy that allows all the users in the company to run with Administrative rights.

     

    let me quickly address the issue of having some sort of a blessing that allows UAC to never ask again like a firewall would; bad idea.  If we back up for a moment and think about what every modern operating system is it should be obvious why this is a bad idea.  We are talking event driven models here where everyone's applications are responding to events.  How does an application know how an event got into the event queue?  If an application is "blessed" then what happens when a software app asks that application to launch by adding an event to the queue?  Ooops, regedit just opened and is modifying keys, but it is doing it with the GUI supressed so I don't know that my system has just been changed behind my back because of course I always want regedit to launch without prompting.  This is not just a windows problem either.  I once knew a guy way back in college who thought it was funning to go into the Unix lab and switch everyone's cursor to the Gumby cursor by sending a remote event over the network.  It does not matter if that issue has been since fixed; I am only using it as an example of what happens when too many messages are inherently trusted.

     

    What do I think of UAC?  I am a systems administrator and for my day to day work the mimics that of a standard user I can't remember the last time I saw a UAC prompt.  When I am troubleshooting an issue like tracking down registry keys so I can remotely change the behavior of all our systems then I definitely see the UAC.  Funny that, when I perform administrative tasks I get a UAC prompt.  At the university where I work I have not only left UAC turned on in our computer labs, I have actually made it more restrictive so that students do not even have the option to elevate.  When the UAC window pops up in our labs it simply informs the user that they do not have permission to perform that task.  We have had zero complaints.

     

    Tuesday, September 25, 2007 5:08 PM
  • ok how do you fix it?!??! In plane English for the rest of the non-microsoft lovers...

     

    Saturday, July 26, 2008 9:40 PM
  •  Mark Van Noy wrote:

    Since this is a developer forum the entire topic is leaving me non-plussed.  I have been seeing all sorts of comingling of the concepts of UAC and Integrity Levels which are not the same thing.  Integrity levels are protecting the data itself which is why you cannot drag and drop between programs when one is elevated and the other is not.  That example is not a UAC example to begin with.

     

    Next, do not forget that as developers you are using the system in ways that are going to require Administrative access regularly and this is not the normal user's experience.  The average user is not firing up regedit on even a monthly basis.  Does anyone really question why starting regedit is a restricted action?  Really?  What really terrifies me on some of these examples are the systems administrators that are upset with UAC because they have internal apps that require Administrative permissions.  Seriously?  I cannot imagine a legitimate corporate secrity policy that allows all the users in the company to run with Administrative rights.

     

    let me quickly address the issue of having some sort of a blessing that allows UAC to never ask again like a firewall would; bad idea.  If we back up for a moment and think about what every modern operating system is it should be obvious why this is a bad idea.  We are talking event driven models here where everyone's applications are responding to events.  How does an application know how an event got into the event queue?  If an application is "blessed" then what happens when a software app asks that application to launch by adding an event to the queue?  Ooops, regedit just opened and is modifying keys, but it is doing it with the GUI supressed so I don't know that my system has just been changed behind my back because of course I always want regedit to launch without prompting.  This is not just a windows problem either.  I once knew a guy way back in college who thought it was funning to go into the Unix lab and switch everyone's cursor to the Gumby cursor by sending a remote event over the network.  It does not matter if that issue has been since fixed; I am only using it as an example of what happens when too many messages are inherently trusted.

     

    What do I think of UAC?  I am a systems administrator and for my day to day work the mimics that of a standard user I can't remember the last time I saw a UAC prompt.  When I am troubleshooting an issue like tracking down registry keys so I can remotely change the behavior of all our systems then I definitely see the UAC.  Funny that, when I perform administrative tasks I get a UAC prompt.  At the university where I work I have not only left UAC turned on in our computer labs, I have actually made it more restrictive so that students do not even have the option to elevate.  When the UAC window pops up in our labs it simply informs the user that they do not have permission to perform that task.  We have had zero complaints.

     



    What's the point of your anecdote about frightened students if this is a developer forum?

    As a developer, UAC is a nightmare, period.
    Monday, July 28, 2008 1:24 PM
  • However, as a consumer, UAC is a good thing.  It actively forces developers to either make reduced-impact apps, or to learn about ACLs unless they want to make me complain at them over their unnecessary prompting.
    Monday, July 28, 2008 11:49 PM

  • From reading the give and take above, I tend to see three significant flaws in or affecting the UAC.
    1)  Delegation weaknesses
    2)  Input trustworthiness
    3)  Inheritance weaknesses

    First Inheritance.  Who says that a child must inherit all the parent's wealth.  It has been stated that every child process of an application inherits all the rights and priviledges of the parent.  An application should be able to (temporarily) lower its own priviledge as well as spawn processes or tasks at lower priviledges.  This behavior fits the "inheritance" metaphor better.  It is not necessarily a UAC fix, but it is a somewhat necessary feature in the whole architecture in order for UAC to be embraced.

    Next, Input...  The buck stops somewhere.  It's been said above that you just can't tell whether a human or a program initiated an action.  That may be true, but that is no fault of the developer or of the user.  The OS knows where the input came from.  It can't tell whether a robot physically pressed the key, or mouse button, but it does know it's physical/electrical boundaries (of course BIOS's can be hacked but then UAC can be defeated there).  The OS is designed to allow all sorts of intercepts, hooks, diversion, and detours to all the I/O devices and pseudo devices and "system" calls.  Today, the OS is untrustworthy.  If MS says, there is no way of knowing whether the input was human or program, then shame on MS.  Yes, "Accessibility" requires certain program generated input to appear to be human.  Fine, sign/certify/whatever those programs to "act" that way.  A program should always be able to tell where its input came from.

    The UAC does not particularly care if the user double clicked the icon that started the operation, it is more wants to know if the user intended to click something that would take over the whole machine (read about Inheritance above).  But if the UAC can't even tell if it was a user gesture in the first place, it is lacking a key piece of information necessary for putting control into the user's hands.  Adding input tracibillty would be a huge challenge, but it would be a big step in self-defence for all programs, not just the OS.

    As for Delegation...  By this I simply mean the administrative user lacks the ability to delegate trust to a program (in a simple way).  The task scheduler has been suggested as a work around.  The "don't prompt me again" check box has been request earnestly.  The point is the user is not a developer, so it should be a simple task for the user to say, "I know the program is priviledged, and could wreak havoc, don't bother me anymore."  The concept is that as a user gains experience, paranoia will disappear and the user will be allowing some of those administrative programs to run (clicking okay).   With more experience and habitual button clicking, the user will eventually ask, why do I have to keep doing this.  Admittedly, I don't do UAC stuff that often, but the one place that I hit it all the time (and often enough) is the Task Manager/Monitor Resources button.  At some point, whether safe or not, the UAC prompt has fullfilled it's duty and should not appear again.  There should be some means of allowing the user to create a persistent delegation of trust.  I cannot recommend exactly how, but the solution should not require a yearly maintenance fee for a certificate, else free and share software may be forced to change platforms, thus negatively impacting the MS user experience.


    Les Potter, Xalnix Corporation, Yet Another C# Blog
    Tuesday, August 4, 2009 2:52 PM
  • Hi – I think my information can help.

    In fact, I do not see User Account Control (UAC) as a big problem. When it comes to information: Then there is a lot of info online also Microsoft has good guide for developers.


    Aa905330.wvduac02(en-us,MSDN.10).gif
    Figure A: UAC credential prompt dialog.

    UAC is a good technology used to prevent malware execution.  

    They who do not understand the UAC technology will “claim” that it is a “problem” – while I can say: NO that’s wrong!

    The new UAC shield: Aa511445.uac_21(en-us,MSDN.10).png


    Here is a lot of information regarding UAC:
    http://msdn.microsoft.com/en-us/library/bb756996.aspx

    http://msdn.microsoft.com/en-us/library/aa480150.aspx

    http://msdn.microsoft.com/en-us/library/aa905330.aspx

    http://blogs.msdn.com/uac/

    http://msdn.microsoft.com/en-us/library/bb530410.aspx

    http://blogs.microsoft.co.il/blogs/applisec/archive/2007/06/20/Decurate-Windows-Vista-UAC-aware-application-with-Elevated-Shield-Icon.aspx

    http://msdn.microsoft.com/en-us/library/aa511445.aspx (Check this).
      
    http://technet.microsoft.com/en-us/library/cc709628(WS.10).aspx (Check this).

    http://technet.microsoft.com/en-us/library/cc709691(WS.10).aspx (Check this).  

    http://msdn.microsoft.com/en-us/magazine/cc163486.aspx (MSDN Magazine).

    As you might see there's a lot of information...

    I hope this information was helpful…

    Have a nice day…

    Best regards,
    Fisnik


    Coder24.com
    • Proposed as answer by Fisnik Hasani Monday, October 12, 2009 4:42 PM
    Friday, August 14, 2009 10:26 AM
  • Hello Jorge Coelho:

    Is this issue solved?

    Please tell me!

    Have a nice day...

    Best regards,
    Fisnik

    Coder24.com
    Sunday, October 11, 2009 11:19 AM
  • Hi Jorge:

    How is the situation on your side?
    Is this thread solved?

    Please tell me!

    Have a nice day...

    Best regards,
    Fisnik
    Coder24.com
    Friday, November 13, 2009 8:26 PM
  • Hi Jorge:

    How is the situation on your side?
    Is this thread solved?

    Please tell me!

    Have a nice day...

    Best regards,
    Fisnik
    Coder24.com
    Thursday, November 26, 2009 12:19 PM
  • Hi again:

    How is the situation on your side?
    Is this thread solved?

    Please tell me!

    Have a nice day...

    Best regards,
    Fisnik
    Coder24.com
    Sunday, December 27, 2009 9:43 AM
  • Hi again:

    How is the situation on your side?
    Is this thread solved?

    Please tell me!

    Have a nice day...

    Best regards,
    Fisnik

    Coder24.com
    Saturday, January 2, 2010 2:59 PM
  • Hi again:

    How is the situation on your side?
    Is this thread solved?

    Please tell me!

    Have a nice day...

    Best regards,
    Fisnik

    Coder24.com
    Saturday, January 2, 2010 2:59 PM
  • This information was quite informative and had many resources.... thanks 
    Saturday, March 13, 2010 1:54 AM
  • This information was quite informative and had many resources.... thanks 

    Hi Dr.MobileKing:

    No problem. BTW, UAC Controller Tool v1.0 is now available at
    http://www.itknowledge24.com

    I hope you find this information useful…

    Have a nice day…

    Best regards,
    Fisnik


    Coder24.com
    Saturday, March 13, 2010 12:35 PM
  • Set the EnableLUA DWORD value in HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System to 0 and reboot.

    this will disable UAC without a problem, i would do it to all your users, with or without permission, because the vista UAC is so horrid that i do believe the less people that have it on the better and greater the punishment to microsoft for creating such an incomplete peice of hog-wash, it is now better in win7, but vista, i hope it burns in ____. it has already ruined my week. and if you are one of those people who believe disabling uac is bad and actually like vista's uac, then dont read my comments, dont disable uac on ur users machines, and most importantly do not comment on this as i do not with to hear your flames.

    have fun with my registry trick :)

    works in win7 as well, let me know how you got along with it.

     

    Sunday, July 11, 2010 6:09 AM
  • hai,

    pls check this link

    http://in.groups.yahoo.com/group/Codeforum/

    http://cid-53e55f9c6647cc74.office.live.com/browse.aspx/C%5EN

    http://www.s4vs.webs.com

    Please remember to mark the replies as answers if they help and unmark them if they provide no help.
    suhas.v
    Friday, February 4, 2011 9:39 AM