The gospel according to LUA (least-privileged user account) took center stage at Microsoft’s Security Summit East here with a pair of Redmond consultants pitching the idea of a well-funded security deployment repository to help developers create applications for non-admin users. The LUA principle, which promotes the use of accounts with fewer access rights than Administrator accounts, has been largely ignored by end users, but if Aaron Margosis and Shelly Bird have their way, code writers will have a central place to get tools and training to create least-privilege applications.
People actually need to be trained to code for least-privilege systems? It’s one of the most fundamental tenets of everything we know about security, what’s going on here? Coders should know never to give more privilege than absolutely necessary.
I think it will help.
While I don’t want to say its *needed* it can’t hurt considering many developers don’t pay attention to little things like checking permissions before writing file(s) etc.
Half the off the wall error messages that applications throw I’m willing to bet are because of an ‘access denied’ or other permissions based error that the developer never thought to check for.
I can’t tell you how many programs assume your Windows folder is in C:WINDOWS and fail miserably when installing.
Some developers are just stupid. It’s as simple as that.
I tried to run my desktop as an unprivileged user. Many programs either didn’t work or only partially worked. The grand finale was reinstalling windows to fix the mysterious ACL object on some folder that I promoted in my frustration.
So, every user logs in with administrator privileges,
but all of the applications are fixed to run with
ordinary user privileges. Wouldn’t it be better for
users to log in as ordinary users in the first place?
Then, only the applications that won’t run in that
environment need to be fixed.
But if the user creates an “ordinary user” and tries to use a certain app/games(games tend to be terrible at such things) and it doesn’t work, what will the user do? They’ll either a) switch back to the admin user and start using it again. b) Call the application maker’s tech support which will tell them to switch back to the admin user. So fixing the applications would be a good thing to do now and then they can get people to run as “ordinary users”.
Indeed. And when an “ordinary user” inserts a new Sony/BMG music CD he just purchased to listen to his music, and it insists that he listen as an admin, he’ll log in as an admin.
I think Microsoft would do a good thing by making the Admin account ugly and boring to use. You know, like 16 colors only, a grey desktop, no 3D acceleration, etc, etc.
Yes. Everytime they do something dependent on sysadmin status you slap them on the wrist and tell them they’re a bad and lazy programmer…
Then when their manager asks why the program isn’t shipping as quick you slap him on the wrist and tell him he’s a cheapskate who’s selling crap to their customers.
It’s not training as much as it is bootcamp!
Microsoft doesn’t even do things right. I tried, for a bit, to run as a limited user on XP SP2 (worked fine before SP2). Well, when you download an installer you of course need to do a run as to install it. Unfortunately, it seems IE is setting some flag on it which says only the user who downloaded it can execute it. So, to execute them I’ve always copied them off to my FAT partition (for sharing between linux when I booted into windows more often, sort of wasted space now) and ran them there (FAT doesn’t have much _at all_ for permissions).
Why can’t I download that and run as administrator? Maybe I can, but I’ve renamed administrator is that breaking it? Is it a “if (account.name == ‘administrator’)” sort of thing?
That would be the traditional way of doing it. But that makes far too much sense for that to be how Microsoft does it!
I really don’t know why they’re doing this. My guess: Legacy compatibility for developers who just don’t want to fix their programmers and users with code that no one knows the location of the source of.
Shocking – nearly everyone here posts in utter ignorance. Read.
http://www.microsoft.com/technet/windowsvista/evaluate/feat/uaprot….
I especially like the part where people blame MS because 3rd party developers wrote their apps badly, so that they write to HKLM, System32, etc.
Ma_d, you do not ‘of course’ need to run-as to install it, if you don’t want to. Simply set the MSI installer system to run elevated. http://support.microsoft.com/default.aspx?scid=kb;EN-US;q259459 . Also (again) your issue was a poorly written installer package, not the OS.
Jgmills, not sure what you’re talking about. Everyone logs in with whatever priv/perm/groups they are assigned. With LUA/UAP, even administrators now get checks on high priv apps before they run. Also, LUA provides a built in tool to determine why a badly written app fails to run with low privs and can help correct the issue.
Read. Read. Read. Then comment. Sheesh.
A user is a user. Is a person.
Any system that requires the person using it to think in terms of abstract or logical users is inherently flawed from a usability point of view.
In a high reliabiliy server, maybe security can be a priority rather than usability, but for a desktop system: no.
I suppose you don’t ever lock doors because it’s not user friendly keeping track of keys?
when a non-privleged user can insert a Sony music CD and it automacially installs a $sys$rootkit with admin privleges then the user is not the problem, something stinks in Redmond and they refuse to clean it up…
The whole notion of programs having all privileges that the user running them has is flawed. In that sense Microsoft got it right in Vista. E.g. a program run by an admin in vista still doesn’t have all the privileges that the admin has.
However, no good idea is so tamper-proof that Microsoft wouldn’t be able to screw it up completely. In Vista the CreateProcess queries the application to see whether it requires elevated privileges. Then ShellExecute calls Application Information Service and initiates an elevated launch. AIS then prompts the user for a password through the Consent User Interface.
So, what’s wrong with that? Well, for starters trojans and viruses will of course use this interface as well. People install programs because they want the functionality those programs offer and they won’t see any difference between apps that are OK and ones that might contain trojans/viruses. People will get used to seeing that “Do you want to run this program elevated?” dialog so much that they won’t think even for a second before they answer “Yes” (or type in their password if Vista is configured that way).
And no, this is not a case of PEBKAC. A normal user can’t be expected to understand which of the fifty extremely similar requests is for the app with the trojan.
Wow that is disappointing. I always had a different understanding of how it was going to work (which was obviously wrong)
I assumed that when a program needed to run with admin privileges (older versions of WordPerfect for example), Vista would let them think they were. I thought Vista would create a fake c:windows and a fake registry for each user, and let such apps write to them while thinking they had admin privileges for the system itself.
I thought it would be something like how Wine does it, where each user gets a ~/.wine/drive_c. Figured there would be a c:/users/john/drive_c with a skeleton registry or something where programs could have full access, assuming they were accessing the real c drive.
Instead I read in Anonymous (IP: 69.132.19.—)’s link that the user has the option to give such programs actual admin access. It will let them run, but the end effect is the same as “run as, admin” (program running with elevated privileges), except it’s easier for the user to do, which isn’t necessarily desirable from a security standpoint
The other half of the coin, where programs run by admin don’t have all admin’s privileges is certainly a good thing. I just expected a whole lot more out of their mechanism for letting regular users run programs that require admin access. They are still giving them actual admin access (with admin consent of course), instead of tricking them into thinking they have it. No sandbox.
My mistaken idea was the main reason I was planning to move my families’ machines from XP to Vista (where they all run as regular users with the occasional use of “run as”). Since they don’t run as admin, the improvements to admin’s LUA won’t help them, and their stupid apps (WordPerfect) still need to run with actual privileges. Might as well stay with XP
(Sure there will be other improvements in Vista, I just mean my main motivation for switching them has just evaporated).
Again, this is not precisely true. Running a bad application through LUA involves what is called a ‘split token’. You will not suddenly become a complete administrator on the machine by invoking higher privs – your access to that process will be increased only. Also, applications that require admin rights (and let’s face it – this means ACL additions in HKLM and the file system) are discovered by LUA and it can add then add specifically the spots the application needs. Similar to your sandbox idea. Additionally, *even if you are logged in as the administrator’, running high privilege apps *still* forces a sanity check through LUA to confirm it’s you wanting to do this, and not some virus. That’s the theory at least.
Wine’s idea is actually more like Citrix/TS App server – ini-mapping mode that segments users for multi-user. Vista will not be like this. However, LUA is still incredibly live in the beta process (heck, the name changes again very soon), so rushing to judgement is not yet useful…
There’s already a long-existant programming language called Lua: http://www.lua.org/ Way to feed confusion, Microsoft!
Yeah, ’cause LUA script is sooooo mainstream. I’ll wager you and I are the only people in this thread that have ever used used or heard of LUA script…
http://en.wikipedia.org/wiki/Lua
Lua has a number of meanings:
For the Roman goddess, see Lua.
For the song, see Lua (song).
For the spoken language, see Niellim language.
For the computer programming language, see Lua programming language.
It is the Portuguese name for the Moon.
It is an abbreviation for the computing concept of Least User Access, i.e., giving users as few rights as required for work.
For the island in the Duff Islands, see Lua, Duff Islands.
It is also a Hawaiian martial art.
OMG LUA SCRIPT HAXORED PORTUGAL’S MOON, CONFUSION! Silliness.
LUA is a computing concept, not a (TM) (C) or (R). Also, as I stated earlier, it will not even be called this in Vista as a ‘product’, and has not been so in many Vista builds now.