What is a "LUA Bug"? (And what isn't a LUA bug?)
First, what is "LUA"?
"LUA" is an acronym that variously refers to "Limited User Account", "Least-privileged User Account", "Least User Access", and probably several other clumsy phrases that ultimately indicate a computer user account that cannot make changes that affect other users of the system or the operating system itself. In Windows, these are typically members of the built-in "Users" group; they are explicitly not members of powerful groups such as "Administrators", Power Users", or "Backup Operators", and do not hold elevated privileges such as "Load and unload device drivers," "Take ownership of files or other objects," or "Act as part of the operating system".
A "LUA bug," then, refers to an application -- or a feature of an application -- that works correctly when run with elevated privileges but fails to work for a LUA user, and where there is no technical or business reason for requiring elevated privileges. A common example is when an application saves its runtime settings to a registry key under HKEY_LOCAL_MACHINE (which is read-only to LUA users), instead of to HKEY_CURRENT_USER.
Windows doesn't allow LUA users to change the system time. That is not a LUA bug, because changing the system time has security implications with respect to auditing and to the Kerberos protocol. The fact that Windows XP doesn't allow LUA users to change the time zone is arguably a LUA bug, as is the fact that double-clicking the clock in the taskbar's notification area gives you an error message instead of a read-only view of the Date&Time applet. (Note 1: Vista is heavily focused on a more seamless LUA experience -- see the UAC blog for more info -- and the Date&Time applet is a primary target for an upgraded experience. Note 2: I wrote an earlier post about how to grant a Windows XP user the ability to change the date, time and/or time zone.)
By far, the majority of LUA bugs are due to registry and file system access. A program might try to save its settings into its installation folder under %ProgramFiles%, or it might try to open a key under HKLM for "All-Access" even if it only ever needs Read access. However, there are other types of LUA bugs: attempting to start or stop a service, load a device driver, access hardware resources directly, create or manage file shares, or even explicitly check whether the current user is a member of the Administrators group.
At the core, there are always one or more low-level operations ("API calls") that succeed when performed as admin but that fail when performed as LUA. You can see some of these yourself using tools such as SysInternals' Regmon and Filemon. However, is every one of these a real LUA bug? The answer is that it depends on how the application responds to the failure. The responses I have seen can be categorized in one of three ways:
- "Fire and forget" : The application invokes the operation, doesn't check the result, but doesn't depend on the operation having succeeded in order to continue working correctly. This is not a LUA bug.
- "Gracefully degrade" : The application invokes the operation, checks whether it succeeded, and handles failure in an appropriate way. This is not a LUA bug.
- "True LUA bug" : The application invokes the operation, assumes it succeeded, and depends on the operation having succeeded in order to continue working correctly. A variation on this is that the app checks whether the operation succeeded, but handles the failure inappropriately, such as by displaying an error message and falling over dead.
If you've ever monitored a GUI app running as LUA with Regmon, you've probably come across an example that could be categorized as fire-and-forget: a failed attempt to open HKLM \ System \ CurrentControlSet \ Control \ MediaProperties \ PrivateProperties \ Joystick \ Winmm for All-Access. This occurs during initialization of the joystick subsystem for the process. The specific operation fails, but it does not impact the correct behavior of your application. However, I have seen "guidance" on the web (no doubt from people misinterpreting Regmon output) claiming that to fix some particular application you need to grant the user full access to this key. No! It's not a true LUA bug. You should never need to change permissions on this key!
Before you go making wholesale changes to security settings, you should verify that you're remediating a true LUA bug and not just a phantom, and that there aren't better ways that don't increase exposure. More on that in upcoming posts.
Comments
Anonymous
February 05, 2006
I agree that it should not be up to a unprivileged user to change the system time, but it should be possible to change the time zone. Changing time zone should not change the system time (which should be in UTC), but should change the local time presented to the user, based on UTC, time zone and summer time changes.Anonymous
February 05, 2006
The comment has been removedAnonymous
February 06, 2006
I don't think that changing the time (or timezone) is the primary use case for the Date/Time applet.
It's a pop-up calendar, for working out what day of the week the 17th will be, or what the time is in another timezone. It should be capable of doing this without requiring rights to change the clock (or timezone).Anonymous
February 06, 2006
Aidan: actually, its original purpose was explicitly to set the date, time and time zone. (See http://blogs.msdn.com/oldnewthing/archive/2005/06/21/431054.aspx) People started using it for reference, or to watch the cool time zone map (remember when it used to draw a highlight over the selected zone? http://blogs.msdn.com/oldnewthing/archive/2003/08/22/54679.aspx).Anonymous
February 06, 2006
Great stuff Aaron!!
I have been wrestling with LUA issues for some time now. Mostly, trying to help admin an SBS2003 domain while trying to keep all the WinXP desktop users running with LUA.
As was stated, Quickbooks was a big pain (why do they need full access to the HKCR registry?), although Intuit has a list of privileges required, so I was at least able to get the LUA users running with Quickbooks by setting elevated privilege workarounds for users of that app.
My latest pain seems to be finding work-arounds so the LUA users can use camera and printing software (i.e Kodak Easyshare, HP, Epson, etc.). There are users that need to use these apps for capturing and printing photos.
Also, please provide some pointers for XP Home LUA (trying to get home computers locked down). In WinXp Pro, it is relatively easy to elevate user privileges to specific folders, files, and registry keys as workarounds for LUA users. However, in XP Home I can't find a way to do this.Anonymous
February 08, 2006
LUACrazy:
I'm not familiar with the specific issues that Kodak, HP, Epson, etc. cause. Have you contacted the vendors?
[No help there - but a helpful tip coming in the next paragraph...]
Re the last issue you raise: Windows Explorer offers splendid ACL editors in the Properties dialogs for folders and files - the "Security" tab, which is normally not shown in Home Edition. The "Security" tab does appear if you boot in SAFE MODE.Anonymous
February 09, 2006
The comment has been removedAnonymous
February 09, 2006
Mike Stoltzfus - I haven't seen that problem. There is at least one dialog I know of that doesn't offer the "in future" checkbox, but the ones that do always obey, as far as I can tell. If you're running IE using the "Protect my computer" option, then they probably won't stick. Which dialogs are disobeying you?Anonymous
February 15, 2006
A systematic approach for working around LUA bugs that avoids unnecessary exposureAnonymous
February 16, 2006
Aaron - It must be the "Protect my Computer" option, because when I run as a limited user, they don't obey the checkbox. (Showing a little ignorance here:) What exactly is the "Protect my Computer" option? Is that something set through group policy?Anonymous
February 16, 2006
Mike Stoltzfus - Setting "Protect my computer" will prevent the program from writing to HKEY_CURRENT_USER in the registry, and will prevent even reading from your Docs&Settings folder in the file system. Some more info here:
http://blogs.msdn.com/aaron_margosis/archive/2004/09/10/227727.aspxAnonymous
February 16, 2006
Complete list of Aaron Margosis' non-admin / least privilege posts, for easy lookup.Anonymous
March 17, 2006
I'm having trouble accessing Works 8 calendar as under LUA. Any work around for this?Anonymous
March 24, 2006
i have a friend who's internet doesn't work when on a lua..but it does for the admin account. as far as i know, they have changed no other settings for this to happen, but it does. any ideas would be great! thanks!Anonymous
March 27, 2006
A systematic approach for working around LUA bugs that avoids unnecessary exposure - "the rest of the story"Anonymous
March 28, 2006
ML - was the calendar created by a different account from your LUA account? If so, permissions need to be changed on the calendar file.Anonymous
April 24, 2006
I am having a LUA problem - mine is when i log into a LUA, i get a "fAIL" error message, yet it still loads. I changed this account to an Admin and it loads without the fAIL message.
It seems to be just an annoyance - but i would like to get rid of it.
I was told by others to take the system back to the factory defaults, but was hoping someone here had a "better" suggestion....
any suggestions? oh, I am familiar with the registry and also periodically back up my system
thanks, in advance...Anonymous
April 24, 2006
D Robinson - from what you're describing, it sounds as though there is a program that automatically starts when you log on that has a LUA bug. The best tool for identifying "autostart" programs is Autoruns from sysinternals.com - that will help you narrow down the cause: http://www.sysinternals.com/Utilities/Autoruns.htmlAnonymous
April 26, 2006
The whole date and time issue can be resolved with DesktopStandard Tools (www.desktopstandard.com) , I have been using them for over a year now, they are the easiest and simple solution to all the LUA problems I have had. Sounds like a plug, but I have really been impressed with them so thought I would share my experiencesAnonymous
April 26, 2006
James Cannon - I talk about DesktopStandard in "Fixing LUA Bugs, Part II" - you should read that. I also published a simpler solution to the date/time issue.
Fixing LUA Bugs, Part II:
http://blogs.msdn.com/aaron_margosis/archive/2006/03/27/562091.aspx
Changing the system date, time and/or time zone:
http://blogs.msdn.com/aaron_margosis/archive/2005/02/11/371474.aspxAnonymous
May 01, 2006
trebor: I had the same problem a while ago. Pre Service Pack 2 I think. If I remember correctly it affected me on LAN provided 'net access, and dial-up seemed fine. I discovered that non-IE based programs worked under LUA.
AnthonyAnonymous
June 19, 2006
More info on the risks of changing access control lists to fix LUA bugs.Anonymous
July 25, 2006
PingBack from http://www.jedi.be/blog/2006/07/26/links-for-2006-07-26/Anonymous
August 07, 2006
"Why does Application XYZ need to run as admin?"Anonymous
September 05, 2006
One way of coping with the challenges corresponding with "the principle of least administrative privilege"Anonymous
September 05, 2006
On the second Tuesday of the month Microsoft introduces updates for it's products. As a system administratorAnonymous
December 17, 2006
The comment has been removedAnonymous
January 03, 2007
The comment has been removedAnonymous
January 30, 2007
I did the same thing as Mike O'Grady with the same results. Upon calling Microsoft support, I was told to put any fully shared data into C:Public (also known as C:UsersPublic). This works without any need for changing ACL or any user administration. However, there is no CSIDL lookup for Public. This makes me concerned that using this folder is not officially supported. Any comment on using C:Public over C:ProgramData (which apparently is an alias for C:Documents and SettingsAll UsersApplication Data and can be looked up using CSIDL_COMMON_APPDATA)? David: There isn't a C:Public, but there is a C:UsersPublic. That will get you the default ACL you want, but those folders are really for items that users can browse/discover/interact with directly, rather than ProgramData which is intended for programs to manage. I would expect the better recommendation would still be to create a custom folder in the app-data folder and set its ACL appropriately. For the CSIDL, see this post and follow its links. The relevant ID is FOLDERID_Public. HTH -- AaronAnonymous
February 15, 2007
More info on the risks of changing access control lists to fix LUA bugs.Anonymous
November 07, 2007
nbtstat does not work for a limited user, only for admins. Is this a LUA bug? I think the option -n for example does no change to the system and does not read non-public information -- so it is a LUA bug. How can I work around this? I have tried LUA buglight (starting cmd.exe, then nbtstat -n ) but got no helpful result. With the option -a you can ask a remote system's NetBIOS name table. You need local admin rights but not on the remote machine! [Aaron Margosis] I just tried nbtstat using (separately) -c, -r and -n. All of them seem to work on my Vista machine.Anonymous
November 08, 2007
I have tried on Windows XP and Server 2003 only.Anonymous
February 22, 2008
Problem occurs on Windows XP and Windows Server 2003: nbtstat -n Failed to access NetBT driver -- NetBT may not be loaded [Aaron Margosis] Seems to be a LUA bug in XP and 2003: http://support.microsoft.com/kb/888373 Probably inadvertent -- those operations should work for members of the Network Configuration Operators group, but they don't.Anonymous
September 20, 2008
Why not install software under a user dedicated to that software? I know in some cases this is a bit much, however this could apply that when you install software all files and registry keys created are owned by that user. Rolling back system changes can be done similarly to removing a user and all their associated files & keys.Anonymous
May 21, 2009
Hi, Can I get a copy of your tool. When I try to download, it is giving page cannot be found. Thanks Deepu E-mail: dcherian@dlbassociates.comAnonymous
May 21, 2009
please send me the link to download LUA tool [Aaron Margosis] Link to the currently published version: http://blogs.msdn.com/aaron_margosis/archive/2008/11/06/lua-buglight-2-0-second-preview.aspx