Slashdot Mirror
Windows Users Ignoring LUA Security
blankify writes "eWeek is running a story about the least-privilege, no-admin option available in Windows (2000/XP/2003) that has been mostly ignored by end users. From the article: '"To the average user, the notion of non-admin is abstract and obscure," said Michael Howard, a senior security program manager in Microsoft Corp.'s security business and technology unit. "Most users just don't know they can set up least-privilege accounts in Windows today, and that's just a sad reality."'"
How about, embracing and extending good practice...
Deleted
most likely because this option breaks most applications
There's a reason why most people don't use it. Microsoft's implementation is flawed to say the least. When a user sets themselves up this way and then installs programs as an Administrator, they find that they can't run the programs completely or correctly as the lower privilege user. Some of this is due to Windows application programmers doing boneheaded things. Much of it has to do with the programming practices Microsoft has fostered - like writing to global registry keys in the Windows 95 and 98 days. Contrast this will Apple which has gotten the APIs right, put out tutorials on how to do this and most importantly made the whole process of installing as Administrator but running as a User as painless as possible.
If their software doesn't work in least priveleged mode doesn't it defeat the whole purpose of the system?
Users ignore it, because it's a horrible pain to use XP using a normal user account.
There are numerous games that cannot be installed without admin rights, and plenty who cannot even be EXECUTED without admin rights. All because the devs are lazy morons.
Same goes with numerous applications.
Not to mention the fact that in many case applications break in random ways, without actually telling why they break.
So right now if you actually want to use XP, you pretty much are stuck with admin mode (or you have way more patience than I do in using 'run as..' or switching users)
Everything you need to know http://nonadmin.editme.com/
http://www.sandstorming.com
Could it be "the sad reality" because Windows up until XP (ignoring 2000 and NT) there was no user-priviledges differences?
Maybe MS should start educating the population and force them to create passworded least-priviledged accounts and choose a password for the administrator account when installing or booting an OEM for the first time. Maybe also the administrator should be blocked out of surfing the web and playing games so that people just don't use the admin account for everything.
One big obstacle is that too many applications I see require administrator privileges not just to install but also to run. Your end users figure that out, set themselves up as administrators, and leave it at that.
This is nothing new...
Soli Deo Gloria
... I'm a true blue Windows user, but I've tried linux. Red Hat 8, to be specific. I remember the FIRST thing it told when I logged in as root, was to create a new non-power account. It even showed me how to. Whenever I wanted to change/install something, a nice prompty would come up asking for my password to give it the proper priviliges.
M$ should learn from this, and their little article there, that instead of the stupid tour that appears when you first login after a fresh install, there should be a message alerting the user to create a new account.
Let the commencement BEGINULATE!
Or the fact that 1/2 the programs only work with Admin rights.
It isn't the unfriendliness of the UI or the help file.
By default, new accounts created during a windows install/first use interface are administrator accounts. As are new accounts created through the generic, task view Control Panel interface for account management.
It's one of the reasons that Windows is unsecure out of the box.
If MS merely made accounts user only be default, that would take care of it.
Of course, then you'd have to fix all of the crappy software out there that can only run as admin. And there's a lot of it. Major software packages like WordPerfect still don't handle user accounts and preferences correctly and it's a very simple thing to do.
Lets not forget software just failing to work. Most third party applications simply will not run correctly in an LUA environment. Honestly, most MS software couldn't run this way before 2000. I run LUA and I have to use runas admin on far too many applications; how is that really LUA? And lets not forget that running IE with reduced rights will also cause many IE plugins and any IStream handoffs (like Media Player) to fail without explanation.
Of course, I totally agree that they claim of lack of user awareness when it is really a lack of MS support. Microsoft has also done nothing to simplify this issue for developers. There are no simple "test and prompt for elevation" routines. It's not a general Windows logo requirement; in fact it's buried in one paragraph in the enterprise logo. And to top it all off, aside from a few proactive devs making blog entries, there's been no attempt to educate users.
Way to go MS, blame user apathy for your own poor performance.
It's partially driven by software that won't install as a regular user (i can kinda live with that) and/or won't run as a regular user (unacceptable except for system utilities).
I can't even count right now how many clients I have running users with admin membership because of crappy software.
And the kicker is, it's not that hard a programming task to make software run in the regular user context! argh!
eric
MS - Hello intrepid user. I know I've always allowed you to run as root before but check this out! You computing experience could be filled with and endless array of confusing dialogue boxes all basically telling you you're not root.
User - That sounds like it might suck.
MS - No no no, it's great! And it's pretty hard to implement. Oh and a whole shitload of legacy apps won't even install.
User - Why would I want that?
MS - It's safer.
User - Do you still let programs run as System?
MS - Well yes.
User - Why?
MS - Symantec asked us to support the Open Source Virus Community and we are!
This
Changing the screen resolution in Windows does not require admin privileges.
Half the spyware normal users get uses privledge escalation holes anyway so it does not keep that crap down.
Which ones ? Privilege escalation bugs aren't exactly common.
Anyway, I have been told (but have not tried) that making the "temp" folder trees "Everyone" read/write explicitly, and adding each account explicitly fixes most of the "run as admin" problems.
You've been told wrong. For starters, every user on the machine can create new files and modify existing files that belong to them in C:\Windows\Temp. Secondly, most all apps (even the badly written ones) use the per-user TMP variables that point to directories within the users profile (that they have "Full Control" over).
Most programs dont do much registry editing, but a lot need scratch space and if they use the temp folders, they need access to them.
No, in fact the most common problem is applications that try to store things that *should* go in HKEY_CURRENT_USER in HKEY_LOCAL_MACHINE. Bugs like this are actually a good indicator of the developer's lack of interest in updating their product, because per-user registry hives were introduced to Windows 9x back with Windows 98 (they've always been in NT AFAIK).
The second most common problem is stupid developers trying to write to files (often user or application preferences) in either their program's directory or the Windows directory (DOOM 3 has this problem).
Even a lot of MICROSOFT games (Age of Mythology, for example) don't work unless you have admin rights...
I think you're over-simplifying this. The Windows NT kernel and core services were designed with security in mind. The real issue is that the shell, UI, and API's do a really poor job of enforcing and providing convenient access to that model. MS made a tough choice when they created they Win32 API; they kept developer compatability and convenience but made security a whole lot harder. There are too many default behaviors in Windows that are just dangerous.
Look how CreateProcess will progressively search for an executable at each space delimited chunk in an unquoted path; that makes a great trojan attack. Consider the shatter vulnerability and associated dangers that result from simple window input; that's why services have to be run on a seperate ACL'd desktop to be safe. Consider how trivially a power user can escalate to admin; look at how many apps need at least that privelege. Look how much code you have to write to set a simple multi-user DACL on an object.
The fact is that security is very hard to do properly in an MS environment, and historically MS has done a very poor job of promoting and simplifying it. I audit security software now, but when I wrote software I had a ton of homegrown libraries to handle things shouldn't have been necessary. So while I agree the tools are there, you almost have to be a security expert to use them properly.
Mod that man up.
:\
Intuit is criminal number 1 in this area (this month anyway, I have my targets change from time to time...)
Get this: The "enterprise" version of QuickBooks that will allow you to run in terminal services (gotta spend that extra cash to run the same software remotely you know!), requires that you have Power Users or Administrator priveleges.
Here's the catch however: I have a client running Small Business Server 2003, and they just went through a company restructuring where the CFO is going to be 200 miles away for the next few months, and needs to be able to hit QuickBooks from a terminal server session (yes, I know, VNC, PC Anywhere, bitmap pusher x..., work with me here though).
So, on an SBS, you can't have any trusts, no member servers (I might be wrong on that last one, apparently there'a hack that allows this, but again...), so the only server on the domain is the DC. You DC does not have "local" accounts and groups, only the AD users and groups. So a local power user doesn't exist. The only rights I can give them to be able to work is Admin.
The whole point of remote users is to.....access things remotely. You're requiring that every one of my users that wishes to use QuickBooks have Admin rights, and if they want to run in term serv, I have to allow dial in rights to that Admin account.
So I got on the phone with them. I suggested the following workaround:
"What if I just create a domain account, say ""QuickBooks User"". Set it to an obscenely secure password that no one but the admins could possibly know. Make it long, make it random, make it not-so-easy to remember. Grant that account Admin rights. Set Quickbooks to "Run As..." that user. Now Quickbooks gets the Admin privs it needs, but not the user."
After going through a supervisor, I was explained that this wouldn't work, and in fact they misconstrued it as an attempt on my part to subvert their licensing (because now I only have a single Quickbooks user, and we're supposed to pay per-seat for the license), and "Run As..." is intentionally broken to prevent this, along with the ability to run in Terminal Server if you haven't purchased the enterprise version.
Wow.
Cash more important than security.
Hey guys? What is so important at the system level that the *user* needs to make modifications to the OS? Why not store the data in the user's profile? Or in a shared directory with rights granted to the users in the "QuickBooks Users" group?
I just don't get it.
Karma: Chameleon (mostly due to the fact that you come and go).
"Running windows without admin rights is a nightmare."
It certainly isn't easy, unless you're willing to invest significant technical time and effort into the project -- which is, I'm sure, a big part of the reason why most people don't do it.
That being said, I'm the admin for an organization with about 60 or so Windoze stations, and I can say that it can be done for most things. It most often involves figuring out what the defective program is trying to do, and then allowing it access to just where it needs.
The two most vital tools are FileMon and RegMon, both free from SysInternals (http://www.sysinternals.com/). They monitor file system or registry accesses. In the vast majority of programs can be made to work just by applying some ACLs on program-specific registry or filesystem branches.
There's no way in hell your "typical home user" could do this, though, which is, I expect, the problem and point.
dragonhawk@iname.microsoft.com
I do not like Microsoft. Remove them from my email address.