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