Microsoft Pitches LUA Security Repository 158
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."
Adobe (Score:2, Insightful)
Re:Adobe (Score:1)
who in the fuck thought it was a good idea to let end user software run with ADMINISTRATOR access?
Let's all use IRC as root/administrator too.. that's just a really good idea as well...
WHAT IN THE HELL EVER HAPPENED TO JUST A LITTLE SHRED OF COMMON SENSE???
Re:Adobe (Score:2)
And its not as if you can wean people off-of Quickbooks, at this point in time.
Re:Adobe (Score:2)
Re:Adobe (Score:2)
It's worth pointing out that NT has been around since 1993 and even Windows 9x has supported APIs and similar (eg: per user registries, per-user home directories/profiles, etc) to develop "multiuser friendly" applications since Windows 95 OSR2 (ca. 1996 - 97).
Software developers have had everything they need for around a decade to create Wi
Re:Adobe (Score:2)
Those who do not understand unix... (Score:3, Insightful)
I dont' think I've ever seen a more apt example of this aphorism.
Those who do not understand allagories. (Score:2, Insightful)
So when's Unix going to invent "capabilities", and why did it take the NSA to "invent" SELinux?
Oh right, Unix security is perfect. That's why we keep hearing that damn saying every time we have a Windows story.
Re:Those who do not understand allagories. (Score:2)
In this case, the issue is about developer coding. I don't care that it is about admin/user rights and not buffer overf
Re:Those who do not understand allagories. (Score:2)
Re:Those who do not understand allagories. (Score:2)
I use CentOS, and the latest kernel you get from them (ie Redhat) is 2.6.9.22, so if I want a much later (and therefore untested version), I have to compile it myself from kernel.org
I would love if the CentOS team did the compiling for me and release the latest stable kernel as a yum-installable module.
Re:Those who do not understand unix... (Score:3, Insightful)
No one would write a UNIX app that required root to run, but if there were a bunch of such apps, what would you do about it?
(The other option is some kind of charade where old apps would get a virtual file system and registry. That would have some advantages, but it
Re:Those who do not understand unix... (Score:1)
Many people have written such apps, they are called servers. Anything that binds on a privileged port requires root access.
The other option is some kind of charade where old apps would get a virtual file system and registry. That would have some advantages, but it would also be a total mess to know where something presented by an application is a real path or a virtual path in the
Re:Those who do not understand unix... (Score:1)
I'm going off the topic and on a rant
In general, that's never true. Visual UI is a much more intuitive and manageable metaphor for several reasons, not the least of which that it enables feedback to user without displacing things. The problem you've experienced is likely the result of a poor GUI, not GUI in general. Since you appear to be a UNIX user, I'm not surprised. The
Re:Those who do not understand unix... (Score:3, Informative)
simple situation. I store my Browser bookmarks on my website so I always have a backup copy them.
GUI. "OS X" Windows or KDE aren't a lot different here
right click on applications folder in dock, (it opens a contextual menu of all items inside, think start menu, kde menu)
find ftp program and open it.
click on on appropriate bookmark,
type in password,
drag file from local to remote directory.(this assuming i
Re:Those who do not understand unix... (Score:1, Insightful)
Re:Those who do not understand unix... (Score:1)
Re:Those who do not understand unix... (Score:2)
Re:Those who do not understand unix... (Score:2)
There are plenty of non-server situations where a GUI can be clumsy. e.g. for complex find/replace on a document GUI tools can be inadequte (can't use regular expressions) or very complex (lots of clicking as opposed to typing a few symbols).
Re:Those who do not understand unix... (Score:1)
Ok, let's have a race. I want you to find all the MP3s in a directory tree /Myfiles (or \MyFiles) and move them to a new directory, excuse me folder, called "MyMP3s".
Ready.... Go!
find /Myfiles -name *.mp3 -exec mv {} /MyMP3s \;
I'm done! You done yet?
Ok, that was obnoxious but my point was setting up a chroot jail is easier with command-line utilities. If you don't know of anything that's easier with a command line tool, then you haven't done everything yet.
Re:Those who do not understand unix... (Score:2)
There are several steps, but fewer overall keypresses. (35 vs 49) One major disadvantage is that I'd hav
Re:Those who do not understand unix... (Score:2)
Only if the GUI sucks.
If you don't know of anything that's easier with a command line tool, then you haven't done everything yet.
I know of a few things that are "easier" with a commandline (and many, many things that are "quicker"). However, 90% of them are only "easier" because a GUI interface either doesn't exist, or is extremely poorly designed.
Re:Servers should *not* require root. (Score:2)
Yet when I do a ps aux on my GNU/Linux machine, I see all my servers running under their own user accounts. When I open the Task Manager on my work XP workstation, I see all services running under the SYSTEM account.
Regardless of theory, a fine-grained permission system isn't worth squat if it is not used. Conversely, in the *nix side of the computing universe, we have gotten smart (through painful experience) and wrote our server software to immediately drop permissions after binding to a port.
The proble
Re:Those who do not understand unix... (Score:2)
The registry already has virtual roots: HKEY_CURRENT_USER, HKEY_CLASSES_ROOT(*) and HKEY_CURRENT_CONFIG. Also, on amd64, registry operations from 32-bit software are (sometimes) redirected to HKEY_LOCAL_MACHINE\Software\WOW6432.
* especially nasty since this merges information from the per-user classes key with the local machine classes key--not s
Re:Those who do not understand unix... (Score:2)
The correct way to do it is to put per-user settings in HKEY_CURRENT_USER\Software\Classes, and to put all-user default settings in HKEY_LOCAL_MACHINE\Software\Classes. It's hardly rocket science!
Re:Those who do not understand unix... (Score:5, Interesting)
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.
Re:Those who do not understand unix... (Score:2)
This is not really a great deal better; your user account (and hence an attacker who has compromised your account, manual cracking or automatic worm/virus alike) is still able to alter the application.
Re:Those who do not understand unix... (Score:2)
Gutting the OS security model is not the
I blame lazy sysadmins (Score:2)
The problem is two-fold: lazy app writers, and l
Re:Those who do not understand unix... (Score:2)
No they didn't. Microsoft have been tel
Re:Those who do not understand unix... (Score:2)
http://www.cs.bell-labs.com/wiki/plan9/plan_9_wik
http://www.cs.bell-labs.com/plan9dist/ [bell-labs.com]
(Sorry, I'm not attacking Linux, I just find your post ironic....)
Bad acronym (Score:3, Informative)
Re:Bad acronym (Score:2)
Made me instantly think of the Lua programming language.
Thank god there's something like context, in which LUA the programming language wouldn't make sense... :-)
Re:Bad acronym (Score:2)
Re:Bad acronym (Score:1)
Re:Bad acronym (Score:2)
Re:Bad acronym (Score:1)
Re:Bad acronym (Score:2)
Managed PCs (Score:2, Insightful)
Some applications wont run if the user is not local admin and you know how much users can be trusted.
Re:Managed PCs (Score:1)
However, don't get me started on copy controlled apps. How about this error message from my sons workstation whilst trying to copy his roaming profile:
The com
Comment removed (Score:5, Informative)
Re:Managed PCs (Score:1)
Of course, if explorer could manipulate the files that would defeat the copy protection so they have to break the filesystem to make the system secure. Now in any normal windows directory that would be fine, except roaming profiles ships application data to and from the server, hence the error.
Re:Managed PCs (Score:2)
Windows cannot copy file C:\Documents and Settings\user\Application Data\SecuROM\UserData\???????????p???????? to location \\Server\Home\user\Profile\Application Data\SecuROM\UserData\???????????p????????
The company concerned were very friendly but the only solution they could offer was to delete the directory and not use the application.
What happens
Is this the default in Vista? (Score:4, Interesting)
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?
Re:Is this the default in Vista? (Score:1)
Developers should be able to click "users", "groups", and figure it out themselves. The "default" that you describe has nothing at all to do with how developers develop code. And after development, testers are supposed to also try these things out. This has nothing to do with Windows, and everything to do with bad developers (same thing with
Re:Is this the default in Vista? (Score:1)
Re:Is this the default in Vista? (Score:2)
Re:Is this the default in Vista? (Score:1)
Re:Is this the default in Vista? (Score:2)
Windows currently has the problem that it still mostly thinks of itself as a single user system - if you install an app, it'll put some stuff in HKLM, some other stuff in HKCU... and then a large number of apps won't work if you then log into another user. This destroys the concept of the admin inistalling apps for the unprivileged users to use.
It's not just apps writing to privileged locations, it's apps relying on the existence of configuration in HKCU - they should
Re:Is this the default in Vista? (Score:2)
This is more a problem with people writing Windows applications...
if you install an app, it'll put some stuff in HKLM, some other stuff in HKCU... and then a large number of apps won't work if you then log into another user. This destroys the concept of the admin inistalling apps for the unprivileged users to use.
It's not just apps writing to privileged locations, it's apps relying on the existence of configur
Re:Is this the default in Vista? (Score:2, Insightful)
Also, what is the point
Re:Is this the default in Vista? (Score:1)
It sounds to me that you are running a limited account that may have once been an admin account or that
Re:Is this the default in Vista? (Score:1)
It is definately not a safe standard of protection.
Re:Is this the default in Vista? (Score:1)
Limited accounts also don't allow access to many system settings (too many, IMO, such as the Power Management), and don't allow access to registry settings beyond tho
Re:Is this the default in Vista? (Score:1)
Let me guess: You are running XP with FAT32 partitions?
FAT32 does not support any kind of access restrictions (except a few attributes, but any user can change those too).
So if you want security in XP, you have to use NTFS. Then you will get security like:
- restricted users cannot write to C:\Program Files
- restricted users cannot write to C:\Windows
- restricted users c
Re: (Score:3, Interesting)
Re:Is this the default in Vista? (Score:1)
I think this would be ideal. It's one of the things that I most appreciated when I migrated from Windows XP to Mac OS X this past summer.
Re:Is this the default in Vista? (Score:2)
Microsoft have been giving developers the necessary information and tools to write "LUA-friendly" applications for about ten years now. Why is it their fault if application developers ignore it ? Is
Good start (Score:4, Interesting)
Re:Good start (Score:1, Insightful)
Re:Good start (Score:2)
Re:Good start (Score:1)
I've always tried to do the LUA thing with my clients. For the most part
Re:Good start (Score:2)
%USERPROFILE%/Application Data and %USERPROFILE%/My Documents was supported in Windows 98. The last version of Windows which had any reason to store user data with the executable was 3.11
Re:Good start (Score:2)
Re:Good start (Score:1)
Old Applications (Score:3, Interesting)
Re:Old Applications (Score:2)
The point is that older programs should be updated, not that anyone should be try to compatible with them. LUA is a Good Thing.
Re:Old Applications (Score:3, Interesting)
Re:Old Applications (Score:2)
So, how is this going to be compability with older programs that require admin priveleges?
Good question but the answer is to create a privelege set with all priveleges and assign it to such applications.
Now once a admin and then users figure out how to do this, they will simply use the admin-all privelege set for everything.
Back to square one as the problem is not being addressed.
Re:Old Applications (Score:1)
1) If LUA is not enough it prompts you to enter your password for more privileges
2) When programs running in LUA try to create files at system level. They are allowed to do so but these are virtual folders that appear to as system file/folder for the program but reality aren't so
3) Even registry particularly the LOCAL MACINE part has a similar feature.
Re:Old Applications (Score:2)
Without a shim, the open call will fail if the key is not writeable with the LUA privileges. However the shim will say "Oh you only want to read from this, so we'll just open it as read-only for you instead." Thus the call succeeds and the ap
LUA ignored by developers too (Score:5, Insightful)
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!
are you sure those games need admin? (Score:1)
Re:are you sure those games need admin? (Score:2)
1) Lots of things want access to various areas in HKLM or HKCR. They might only read the areas, but the program asks for read/write/delete/create access since it was coded poorly. You can grant the software such rights, but that is a serious change. I want a new access level called "lie" which tells the program that it has write access, but then only fails when it actually tries to write.
2) Some of them just don't work anyway. I've used regmon+filemon on some games,
Re:are you sure those games need admin? (Score:2)
Sounds like "Copy On Write", a concept which has been around for quite some time.
Re:LUA ignored by developers too (Score:2)
My boss brought in his new computer about a year ago for me to set it up securely, as our company is the only one he knows that has not had any kind of downtime due to malicious code/spyware/etc in the last six years (since I've been there).
The reason? Despite all the difficulties associated with it, all user accounts are Standard (Restricted) Users in Windows XP, and Power Users in Windows 2000 (I've found its impossible to iron-out all the kinks when attempting to run as a Restricted User in Windows 2000
MS is already working on this, apparently (Score:1)
From
http://www.winvistaforums.com/viewtopic.php?t=35 [winvistaforums.com]
http://news.zdnet.com/2100-1009_22-5998726.html [zdnet.com]
Re: (Score:1)
LUA not a panacea (Score:2, Insightful)
The two chief problems (Score:5, Insightful)
- 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.
Re:The two chief problems (Score:3, Interesting)
What you describe is becoming less and less common, but it happens. Interestingly enough, one of the worst applications at work is an electronic banking program.
Apparently banks don't care about security. We got the same response from their helpdesk.
But otherwise, it really is possible to do it. Requires some extra effort, but so does security on Unix/Lin
Re:The two chief problems (Score:2)
On the second issue, XP Home should really set up lower access accounts by defaul, and require a password. It is not like users have a choice of OS, so MS does have the power to enforce
Re:The two chief problems (Score:2)
Without any effective security. It's not unknown for applications to refuse to open files stored on CDs, unless they are first copied to somewhere else.
- Users on Windows are administrator by default
Only on a standalone Windows machine.
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
Re:The two chief problems (Score:2)
There are some pretty dumb developers out there... the developer of the telebanking app of our bank insists on placing temporary files in %windir% instead of %temp%. Maybe he once had the experience that %windir% always exists and so is the best place to write temporary files...
(similarly, some apps write tempfiles in the root directory, or in %windir%\Temp)
Windows 2K Power Users? (Score:2, Interesting)
Logo Cert. should require games and most apps to work with Power Users or equ.
Re:Windows 2K Power Users? (Score:2)
Nothing happened. The 'Power Users' group is still there, in XP Pro at least (can't speak for XP Home).
Not easy to create limited accounts on Windows XP (Score:4, Interesting)
Blame the user (Score:4, Insightful)
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.
But what about Root kits? (Score:1, Funny)
Once more again Microsoft is being insensitive to real world needs.
For everybody attempting to defend MS... (Score:1, Interesting)
"Most Microsoft employees are highly technology literate and routinely explore the limits of the tools available to them in order to improve product quality. For example more than 95 percent of Microsoft employees have local administrator rights to their desktops."
http://www.microsoft.com/technet/itsolutions/msit/ security/mssecbp.mspx [microsoft.com]
And Microsoft's martketing people are bragging about this as SECURITY FEATURES.
Re:For everybody attempting to defend MS... (Score:2)
There is a vast gulf of difference between "having local administrator rights" and "running as administrator all the time".
QuickBooks (Score:2)
What is so special about QuickBooks that it needs to be an administrator? Were the Intuit programmers just lazy or do you really need root to balance a checkbook?
Re:QuickBooks (Score:2, Informative)
They were lazy. It can be run under a Limited account in XP. Here's how I did it:
Fire up the freeware app Regmon [sysinternals.com], and set the filters to ignore the standard things running in the background (windows services, anti-virus software, and firewall software - A good starting point is as follows: csrss.exe;explorer.exe;LSASS.EXE;Regmon.exe;WINLOG ON.EXE). Just look at the list of processes that are filling up the main window for the names to put in the filter. While you're still in that filter dialog, uncheck "L
Even "aware" users have to use admin accounts (Score:3, Interesting)
I use XP largely to play games, and find that even on games that can be played in underprivileged mode, bugs pop up more frequently. Just a couple nights ago I had a problem with a Microsoft title (AOE3) and finally was able to net connect when switching to an admin account. The developers simply don't test in this mode enough.
Here's a response from Atari when I complained about having to play UT2004 in my admin account. You can't win when this is they don't even consider this a bug:
From: Tech4 Subject: RE: Unreal Tournament 2004 - Windows XP : USA : This game, like most of its type, requires Full admin access to play, and can often conflict with third party software such as firewalls or virus scanners. We recommend disabling those items when the game is in use, and turning them back on afterwards. MarkL Atari Support www.atarisupport.comRe:It may not be a bug (Score:2)
Build a Windows Sudo (Score:2)
Look at a built in Windows equivalent of Sudo with as many of the good rights you need and as few of the bad ones you don't need.
Report noncompliant apps to Microsoft (Score:4, Informative)
MSDN promotes non-LUA features (Score:3, Insightful)
the whole thing is MS's fault. not the users. The app developers have secondary responsibility but MS caused the problem in the first place. Their developer resources promote doing all kinds of bogus things in their apps. For years MSDN has gone out of its way to promote all the OS level hooks that are available to developers, many of which only work as admin.
here's an example from a couple of months ago:How to capture the print screen key and totally change how your user's GUI works [microsoft.com]. Just what I want, the ability for some random application to subvert basic elements of the system interface.
Re:MSDN promotes non-LUA features (Score:2)
No, it's solely the application developers' fault. Microsoft have been recommending, and providing the necessary resources, to write LUA-friendly applications for a decade or so. It's part of the "Made for Windows XP" sticker requirements.
Their developer resources promote doing all kinds of bogus things in their apps. For years MSDN has gone out of its way to promo
Circumventing Group Policy as a Limited User (Score:3, Informative)