Slashdot Mirror
Microsoft Pitches LUA Security Repository
corp-dollar writes "According to this eWEEK story on the poor adoption of LUA (least-privileged user account) in Windows, a pair of Microsoft security consultants are pitching the idea of a security deployment repository to serve information and tools to handle LUA bugs and other problems businesses are facing. Sounds like a decent enough idea to cut back on the compatibility problems when trying to run business apps in no-admin mode."
Those who do not understand unix are condemned to reinvent it, poorly.
I dont' think I've ever seen a more apt example of this aphorism.
Or at least a less priveleged account? With a password popup box whenever you want to install drivers etc akin to Mac OS X or somesuch?
Or are they going the same route as before with the default user being an admin?
I'd hope they did, it'd probably help reduce people installing rootkits with certain audio cd's although I doubt it'd eliminate it, there'd still be people who blindly type in their password (if they'd bothered to enter one in the first place).
Also, on a sidenote.. MS aren't exactly standing on the moral superiority high ground here (I skimmed the article), how can they expect programmers to implement this with their programs when by default everyone is a local admin in windows and so far the only program which is supposed to use LUA is IE7 which isn't even released yet?
It's odd, on /. everyone complains that on Windows, many programs don't work unless you are administrator. (or have that power) It's something brought up all the time about the inadequecies of Windows. Now, Microsoft is doing something to attempt to change that, and in the first 3 posts, we get something about how they are just "reinventing Unix, poorly" That may be the case, but they are going down that road. Not every admin can run *nix, it is complex, it is hard to learn. Perhaps MS doing things to make their OS more nix like will actually help the adoption of open source *nix variants. I think the blast Microsoft for everything they do may backfire on /. crowd at somepoint...
The first bit of that plan went down very well - they love having their own user accounts. However almost none of their games/software run as anything except Administrator, even games which say on the box "designed for windows XP".
I end up having to make a custom runas command for each one with /savecred - the windows equivalent to chmod u+s. This is a PITA to setup, insecure and doesn't work for all their software. There is some we've just had to abandon since it just won't work like that.
So please, software developers, check your software works without admin priviledges!
Every man for himself, all in favour say "I"
The two chief problems with LUA in Windows are:
- The Windows programming culture assumes a single user, single tasking computer.
- Users on Windows are administrator by default
The first is the developers fault, the second is Microsoft's. At least Microsoft are trying to fix their end. But even 4 years after Windows XP was released, software is being released by developers who should know better that still require either admin rights or much tinkering to get to run as non-admin. The most recent one I encountered was an application for BACS payments a couple of weeks ago - their tech support's answer was "run as admin". I managed to get it to work for non admins (since this was on a Windows domain) only by caclsing (aka chmodding) the application's directory writeable by all!
It's obvious that the developer had simply not tested the program as non admin.
Oolite: Elite-like game. For Mac, Linux and Windows
It isn't TOO bad because of the built in file and registry virtualization in Vista. If a program running with a LUA token tries to write to say the "C:\Program Files\PoorlyWrittenApp" folder, that write will result in a copy of the file (if it already existed) being made and placed in a location under the user's profile. Then the write to that file will succeed in the new location in the user profile. The OS will preferentially read that new file whenever the file in program files is being "read" by the app.
.exe, etc.) that are never virtualized to make sure people don't get DoS attacked by "replacing" their exe files. There are API's for application developers to specify that they don't want certain files, folders, or registry keys to virtualize. All in all, it makes the app compat story pretty robust.
The same thing works for registry entries.
There are certain files (like
Just the other day I tried to guide someone through setting up a new account and e-mail settings on XP SP2 over the phone. I decided to play it safe and told them to create a limited account. But when you log into the new account and try to run Outlook Express you get this error message, which I couldn't get them past to configure e-mail. I later worked out that you must first run Internet Explorer at least once on the new account before the e-mail setup wizard will come up when Outlook Express is run.
First all this malware spreading around was because we didn't have firewalls. Now it's because we're all running with admin rights. Never mind that it's the OS default, it's obviously our fault that all these bugs keep surfacing.
Of course, the next whipping boy is that faceless developer out there who wakes up one morning and decides to violate basic programming principles like Least Privelege. But it's not the developer's fault.
The problem for the developer is that Windows makes it difficult to do anything but run as admin. The environment assumes single-user, multiple apps, but not multiple users. It was designed with one user in mind, and the multi-user stuff layered on later.
But the real problem with complaining that we're violating Least Privilege is that it's a Redmond Herring (TM). It's ignoring the big problem, which is that since Windows source code is closed, no one without a vested interest in keeping bugs hidden can look at it.
You want a security principle violation? Hiding your code is the biggest one there is.
Raise your children as if you were teaching them to raise your grandchildren, because you are.
Solving the problem by making the directory writable basically defeats the purpose. Write access to the content means that you can replace essential files, such as the executables themselves. Even if write permissions are not allowed to the contained files, you can still use DLL redirection to trojan the executables. So basically, they need to fix the app.
As for the specific issue, based on what you've written there are three likely scenarios that cause this problem. The first is that they're not separating system and user specific config data, and it's all being stored in the application directory. That's a big no-no and it can require some significant effort to fix. The remaining possibilities are easier. They may just be creating temp files under the application directory, in which case they just need to use the system provided temp path for the current user. The last one is that they're opening files under the application directory as writeable, when they only need read access. This one happens a lot, and the fix is to just make sure the file is opened as read-only if it only needs to be read.
If you are interested in finding the actual cause of the problem, you can probably diagnose it with Filemon (freeware) from Sysinternals. Who knows, you may be able to sway their developers to fix it with some specific information.
The Microsoft "Designed for Windows XP" logo program requires that Applications that are designed to work with the Windows XP infrastructure for state separation of data will work correctly under Limited User accounts. So if the application breaks under a limited user, report this to Microsoft logo control. Tell the vendor you did this. This scares some vendors; there's a risk of having their Windows logo pulled.