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."
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
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.
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.
Unfortunately, since the OS we're talking about is NT-based, the aphorism should read:
Those who do not understand VMS are condemned to reimplement it, poorly
This is what amazes me about these discussions: they hired Cutler, the architect of a very successful OS, that had all of the necessary security features. They updated and reimplemented his architecture for modern PC hardware. They then mangled it beyond all recognition by insisting that programs written for Win 3.1 and later Win95 run under NT/2K/XP as if they were still on single-user, no priv separation, versions, and we're still living with that behaviour today.
I tried to run my users with no privs on the last job, and always got bitten by programs such as WordPerfect, which insisted they had to run with PowerUser privs. Meanwhile, complex, computationaly demanding, graphics-heavy programs such as Spartan (visual environment for quantum chemistry), quietly installed in their own folder, didn't write to the registry, and could be moved without breaking because they didn't install anything to the system directories.
The second one is no less complex than WP, yet it behaved for non-priv'd users while popular programs with large development teams funded by reasonable-sized corporations, didn't.
Personally, I think there needs to be a local copy or version of the registry and system folders for such programs, so that they can write to it and be happy, without the user actually having manager privs. That way people with software written for 95/98/ME that they aren't ready to give up can still run it, while the administrator can screw down their machines and keep them relatively safe. This is probably better than the real solution, which would be MS deciding with Vista: Normal users will run as non-priv'd users, and have no write access to system folder or registry. Older programs expecting that ability will simply not run.
The Truly Best Answer would be someone at Redmond deciding, "hey, the next version of our OS will be Microsoft VMS!" Just put the Vista graphical environment on top of a real VMS core, remember that the default SYSTEM account should not ship with password MANAGER, and finally do it right.
the more accurate the calculations became, the more the concepts tended to vanish into thin air. R. S. Mulliken