Follow Slashdot stories on Twitter

 



Forgot your password?
typodupeerror
×

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."
This discussion has been archived. No new comments can be posted.

Microsoft Pitches LUA Security Repository

Comments Filter:
  • Adobe (Score:2, Insightful)

    I'd like to sign Adobe up to that right away.
    • Don't forget intiut too (the makers of quickbooks and the like)

      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???

      • yup, well said, I forgot them. first against the wall with Adobe.
        And its not as if you can wean people off-of Quickbooks, at this point in time.
      • Back in ye olden days of Windows 9x, there wasn't an available multi-user concept featured in Unix for at least 25+ years at the time. When win9x went away in favour of a Windows NT kernel and environment, the multi-user environment was a completely new concept to hundreds of inexperienced programmers. To this day, several commonly-used programs still depend on Administrator access due to its development under an originally single-user environment or out of plain ignorance/stupidity.
        • When win9x went away in favour of a Windows NT kernel and environment, the multi-user environment was a completely new concept to hundreds of inexperienced programmers.

          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

          • I also recall that in the past (don't know if it holds true to date), Microsoft's APIs didn't give a clear line between Administrator and User functionality, so developers would just go ahead and used whatever was most convenient for them. Of course, that meant a lot of unnecessary admin-level functionality being implemented into common userspace programs, so now we have this admin hell that Microsoft accidently (I wouldn't say they did it on purpose...) created. Good thing Unix had this all figured out s
  • by Saint Stephen ( 19450 ) on Saturday December 17, 2005 @10:28AM (#14279409) Homepage Journal
    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.
    • by Anonymous Coward
      "Those who do not understand unix are condemned to reinvent it, poorly."

      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.
      • The issue is never because of the old 'unix is perfect' argument. Even Unix has evolved in its security capabilities - eg. SELinux, filesystem ACLs, but I still have to spend an hour running through my checklist to harden the webservers I put together. Including removing obsolete users that are installed by default! who uses gopher anymore, yet there's the user account ready to be attacked.

        In this case, the issue is about developer coding. I don't care that it is about admin/user rights and not buffer overf
    • How so? Existing programs that want to be able to write to a specific HKLM key or "needs" to write to a specific file are a significant problem. The total security can sometimes be kept, while accomodating some small changes for specific apps.

      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

      • 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?

        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

        • It's pretty messy with the pointy and the clicky but from the command line it's easy to manage, assuming you know what you're doing.

          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
          • I can do more with a command line, scripting and a text editor faster and easier than I can with a gui.

            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
            • by Anonymous Coward
              You did not prove that a command line was easier. All you really said is that you have created a script that makes ftping your bookmarks easier and you execute your program via the commandline.
          • GUIs may be better than command lines for desktop apps but the power of shell scripting and the like makes it a poor fit for a server. There are no intuitive GUIs anyway, they all have quirks that catch out the unwary user. Personally I don't find KDE any more difficult to use than Windows, and speaking as someone who provides regular tech support to non-techies I doubt they would too.
            • GUIs may be better than command lines for desktop apps but the power of shell scripting and the like makes it a poor fit for a server.

              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).
          • In general, that's never true.

            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.

            • I'm not ready to pass judgement on GUI vs command line in general, but in this case on Windows, I'd hit WindowsKey+F to open a search box, put *.mp3 in the find description, ALT+L for location, type \MyFiles, enter, wait for the results, hit CTRL+A to select all, CTRL+X to cut, hit ALT+A to focus the address bar, stick \MyMP3s in there, hit enter, SHIFT+TAB to refocus the files pane, and CTRL+V to paste.

              There are several steps, but fewer overall keypresses. (35 vs 49) One major disadvantage is that I'd hav
            • Ok, that was obnoxious but my point was setting up a chroot jail is easier with command-line utilities.

              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.

      • Aren't MS planning to do the virtual filesystem thing in Vista? So an app thinks it's writing to \Windows but really it writes to Documents\user\Windows or similar?

        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
    • by Frumious Wombat ( 845680 ) on Saturday December 17, 2005 @01:12PM (#14280042)
      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.
      • "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."

        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.

        Personally,

      • 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.

        Gutting the OS security model is not the
      • 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 problem is two-fold: lazy app writers, and l

      • 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.

        No they didn't. Microsoft have been tel

    • Reinvent unix, you mean like Linux?

      http://www.cs.bell-labs.com/wiki/plan9/plan_9_wiki / [bell-labs.com]

      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)

    by HishamMuhammad ( 553916 ) on Saturday December 17, 2005 @10:30AM (#14279411) Homepage Journal
    Made me instantly think of the Lua [lua.org] programming language.

    • 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... :-)

      • True, but I was referring to the title. Think "Microsoft Pitches PHP Security Repository". Disclaimer: I work with Lua, so the association was probably more natural for me than for most.
        • To be honest this very acronym has been annoying me in exactly the same way, the recent Microsoft LUA headlines has been somewhat disturbing. Every time I see MS mention it, they clarify the acronym with Least Priveleged User Account - surely LPUA? I suspect there's a surprising proportion of Slashdotters out there also aware of the acronym clash. (I came across LUA in a game scripting context a few months ago)
          • Marketing studies indicate that TLAs have 80% more 'sticking' power than FLAs, when PHBs perform memory tests ones week after exposure to marketing material.
    • LUA is an acronym. Lua is not. Lua means moon in Portuguese and is pronounced LOO-ah.
      • Your point? Many people write Perl as PERL. Perl is an acronym. So is PERL. The difference between LUA and Lua is not one most people would think significant.
  • Managed PCs (Score:2, Insightful)

    by brenddie ( 897982 )
    Is ridiculous how one app can screw your whole managed environment.
    Some applications wont run if the user is not local admin and you know how much users can be trusted.
    • You can sometimes solve the problem with individual apps by allowing everyone full control of the c:\Program Files\BadApp This works with Sonar4.

      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:

      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 com

      • Comment removed (Score:5, Informative)

        by account_deleted ( 4530225 ) on Saturday December 17, 2005 @12:22PM (#14279835)
        Comment removed based on user account deletion
        • Ah it's a bit simpler than that. The ? characters are unicode garbage. You can't even delete the files in explorer or from the command prompt due to the weird name.

          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.
      • 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:
        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
  • by EvilMonkeySlayer ( 826044 ) on Saturday December 17, 2005 @10:38AM (#14279446) Journal
    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?
    • how can they expect programmers to implement this with their programs when by default everyone is a local admin in windows

      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 .dll hell... bad install tool).
    • No, that's not right. For instance Office 2003 runs fine as a LUA user. There are many apps that do, it just isn't enough yet. There are some cool technologies in Vista to allow more apps to work as LUA though. File and Registry virtualization will allow writes to protected locations to succeed - but virtualize it to a place under the user profile and then preferentially read from there. Obviously this comes with its own set of problems but overall will help to make apps that still are badly behaved able to
      • Elevate? You mean like the new Daleks?
      • "Protected Admin" sounds like the Mac OS X example where the default account is admin, but you need to enter your password to do admin stuff like change particular system settings (but you can still access the entire file system and wreak havoc without any such password prompt).
      • That could solve a bunch of things too.

        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
        • Windows currently has the problem that it still mostly thinks of itself as a single user system

          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
    • Perhaps I'm ignorant, but I have never understood the situation you describe either. In XP, a limited user account does not seem to offer any protection - files can be installed, executed, and removed at will. It seems that some software installation and deletion methods are blocked for limited users, but most aren't. This leads system admins (in corps and uni's), with large numbers of computers on their hands, to use third party software to get the security job done effectively.

      Also, what is the point

      • I think you are wrong... I run XP home on my home pc and only use it from a limited account. I can not complete and install without running the setup program as admin and there are many directories I can not acccess with switching accounts. Most setup programs fail if you try to install them from a limited account - others automaticly pop up a dialog box asking for the admin password to continue.

        It sounds to me that you are running a limited account that may have once been an admin account or that

        • No way did I give rwx access to anything. If the software did, thats a major problem. What about software with third-party install methods, self-extracting installers, or no installation method at all (simple extraction) - I have been able to install similar programs under LU accounts in XP without a road block.

          It is definately not a safe standard of protection.

          • Under XP a limited account does not have write access to any of the system directories (i.e. c:\windows) nor the "programs" directory (i.e. c:\Program Files (or whatever it's called (I'm typing this from a Mac and don't feel like booting my windows machine to find out ;-))), nor does it have read or write access to any other user's directories.

            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
      • In XP, a limited user account does not seem to offer any protection - files can be installed, executed, and removed at will.

        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)

      Comment removed based on user account deletion
    • With a password popup box whenever you want to install drivers etc akin to Mac OS X or somesuch?


      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.
    • 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?

      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)

    by MandoSKippy ( 708601 ) on Saturday December 17, 2005 @10:40AM (#14279449)
    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...
    • Re:Good start (Score:1, Insightful)

      by deaddrunk ( 443038 )
      Because as the world's biggest software company they should have done something like this a very long time ago instead of bullying everyone else in the PC industry, breaking the law and pointlessly fighting a court case instead of settling and behaving at least a bit co-operatively with the people that are stuck with their shoddy software.
    • If you understood the article (oh, this is slashdot, maybe you didn't read it), you'd note that it isn't about Microsoft pushing LUA for XP. It's about some consultants who have an app that can find LUA bugs, and who want to create a central repository to document them. I enjoyed the second comment over at the article; an entertaining rant about how Microsoft shouldn't be signing code that requires the administrator account to run.

      I've always tried to do the LUA thing with my clients. For the most part
      • Storing user data with the executable is so Windows 98, but the developers don't seem to even recognize this is a problem.

        %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
    • Slashdot is comprised of more than one person. The people complaining about "reimplementing Unix, poorly" are not necessarily the same people who complain that Windows is insecure.
    • UNIX is very user friendly... It is just very picky about who it is friends with.. :-D
  • Old Applications (Score:3, Interesting)

    by dduardo ( 592868 ) on Saturday December 17, 2005 @10:42AM (#14279457)
    So, how is this going to be compability with older programs that require admin priveleges?
    • So, how is this going to be compability with older programs that require admin priveleges?


      (I assume you mean "how is this going to be compatible with".)


      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)

      by GIL_Dude ( 850471 )
      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
    • 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.

    • The implementation of LUA on Vista has these features to aid LUA apps that I am aware of

      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.

      • Vista also uses the existing app shim technology, which means MS will include shims for existing apps that have problems with LUA. For example, a common problem (apparently) is Application X opening a registry key for read/write, when it only actually reads from it.

        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

  • by ncw ( 59013 ) on Saturday December 17, 2005 @10:44AM (#14279465) Homepage
    From the article :-

    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.
    Coming from a unix background, when I set up a computer for my children with Windows XP, I decided to make sure that the children each had their own user account, and that none of those user accounts had administrator priviledges.

    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!

    • did you run tools like Filemon from Sysinternals http://sysinternals.com/ [sysinternals.com] to see what was failing when running as a pleb? Too often the answer is to run everything as admin when all that is required is write access to some folder under "C:\PROGRA~1"
      • I do that but it doesn't always work:

        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,
        • 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.

          Sounds like "Copy On Write", a concept which has been around for quite some time.
    • 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

  • "The [LUA Buglight] tool is primarily meant for IT professionals who need to fix bugs in corporate or third-party applications, the Microsoft representative said. However, it can also be used by developers to hunt for LUA bugs in their own applications, the representative said." It is currently not available, as of right now, and the release date is unknown.

    From

    http://www.winvistaforums.com/viewtopic.php?t=35 [winvistaforums.com]
    http://news.zdnet.com/2100-1009_22-5998726.html [zdnet.com]

  • Lots of things a software should be able to do can't happen in LUA mode. So we have few solutions, like popping up admin password boxes (which can be exploited on its own with fake pop-up boxes prompting us to enter our admin login/pass), or having broker processes with higher privileges do the job. But it's important to understand that low-privilege IE and LUA for users is not removing the attack surface, just recucing it significantly and presenting few new ways to exploit the situation... Also it'll be
  • by Alioth ( 221270 ) <no@spam> on Saturday December 17, 2005 @11:20AM (#14279587) Journal
    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.
    • We have been running Windows 2000 workstations with ordinary "user" privileges and toughened filesystem security settings at work for several years now.
      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
    • One advantage of the MS development environment is that it allows the developers to concentrate on coding the process, and therefore allows more effecient development. Under this premise, it is the responsibility of MS to provide the scafolding so that the developer does not have to waste resources reinventing the wheel.

      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

    • - The Windows programming culture assumes a single user, single tasking computer.

      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
      • Maybe they hadn't heard of the User Shell Folders registry keys, which have been in Windows for over a decade, either!

        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)
  • by Anonymous Coward
    What happened to the Windows 2000 Power Users type in XP? Had they kept that and used it as the default in XP, we'd be in a lot better shape today.


    Logo Cert. should require games and most apps to work with Power Users or equ.

  • by Mandrel ( 765308 ) on Saturday December 17, 2005 @11:31AM (#14279635)
    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 [microsoft.com] 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.
  • Blame the user (Score:4, Insightful)

    by lheal ( 86013 ) <lheal1999NO@SPAMyahoo.com> on Saturday December 17, 2005 @11:49AM (#14279700) Journal
    I know running as admin is bad in principle, but from TFA:
    Despite the fact that LUA is accepted within software security circles as a key to reducing damage from malicious hacker attacks, Margosis said a large percentage of customers still run Windows with full admin rights, making them sitting ducks for malware attacks that rely on "maximum privileges."

    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.

  • I mean, how can Sony or UBI load their root kits on your box, and trash the system?

    Once more again Microsoft is being insensitive to real world needs.

  • by Anonymous Coward
    Quote from their website:

    "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. ::shudders::
  • From what I remember of QuickBooks (at least, a recent version) it must be run as administrator. This was a huge issue with some computers we were setting up at a small office... trying to maintain some level of security and this just blew that out of the water.

    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)

      by DynamicBits ( 542509 )

      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

  • by bender647 ( 705126 ) on Saturday December 17, 2005 @01:00PM (#14280000)

    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.com
  • If the issue is that nearly everything needs admin, and it does, and, admin itself is pocked with problems then the answer is to build a better admin with better protections so that you can have the rights without the wide open problems associated with it.

    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.
  • by Animats ( 122034 ) on Saturday December 17, 2005 @03:30PM (#14280522) Homepage
    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.
  • by dmh20002 ( 637819 ) on Saturday December 17, 2005 @05:52PM (#14281085)
    Microsoft trumpets this issue like its a new thing, not a 30 year old principle.

    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.

    • 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.

      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

  • by NZheretic ( 23872 ) on Saturday December 17, 2005 @05:53PM (#14281098) Homepage Journal
    The problem is that Microsoft's LUA restriction has been broken on all of their platforms [sysinternals.com].
    ... Windows administrators should be aware that if a user, even one running with a limited account, can execute just one program of their choice that they also can circumvent many group policy settings, including ones aimed specifically at tightening security such as Software Restriction Policies and Internet Explorer Zones. ...

    ... It's also important to note that the ability of limited users to override these settings is not due to a bug in Windows, but rather enabled by design decisions made by the Microsoft Group Policy team.

Two can Live as Cheaply as One for Half as Long. -- Howard Kandel

Working...