Slashdot Mirror
Longhorn to use UNIX-like User Permissions
destuxor writes "After years of Windows users abusing administrative accounts out of necessity, Microsoft promises that Longhorn will make better use of user permissions in what sounds exactly like what UNIX/Linux users have been doing for years. Hopefully this will fix the long list of applcations that cannot be run by a Least-Privilege User Account (LUA) while giving a much-needed security boost. Too bad "MS-root" can't watch over your grandmother when she opens emails."
The Tao of math: The numbers you can count are not the real numbers.
--
Evan (Really nifty language)
"$30 for the One True Ring. $10 each additional ring!" -- JRR "Bob" Tolkien
The permission mechanisms in Windows NT/2k/XP are pretty flexible. Unix is only just migrating from the old user/group/world permission set to access control lists, something that is readily available for just about everything in the Windows operating system, from files to individual registry entries.
The problem with Windows permission management is that a) it is completely hidden from the casual user, b) there are no guidelines how applications can be made to work with restricted privileges and programmers are too lazy to figure it out themselves and c) the default XP install makes everybody an admin, so there is very little incentive for application programmers to get it right.
The ability is already there in XP to run at lower permission levels for most applications, it's just that few developers have properly coded for it, as they assume the user will be administrator. I would say that 20-30% of this problem is the developers fault, because the tools are there.
http://www.freepatentsonline.com/4135240.html
Inventors: Ritchie; Dennis M. (Summit, NJ)
Abstract: An improved arrangement for controlling access to data files by computer users. Access permission bits are used in the prior art to separately indicate permissions for the file owner and nonowners to read, write and execute the file contents. An additional access control bit is added to each executable file. When this bit is set to one, the identification of the current user is changed to that of the owner of the executable file. The program in the executable file then has access to all data files owned by the same owner. This change is temporary, the proper identification being restored when the program is terminated.
Assignee: Bell Telephone Laboratories, Incorporated (Murray Hill, NJ)
Application Number: 377591
Filing Date: July 9, 1973
Publication Date: January 16, 1979
You can add to that list Oracle (Damn them!) As I work in a large organisation which uses Oracle as its db of choice and M$ on the desktop this is a big bone of contention for me.
init 11 - for when you need that edge.
We've had the same issues at work but we've found that if you examin the bad applications closely they mostly want write access for the user in the 'programs files' area or the windows or winnt area. Giving users of these programs the proper write access solves most of the problems. We found one program that required a registery edit to work properly with just 'user' privilages. It is a major PITA to find out all these details to tighten security but we are doing it.
zenray
In XP:
Mountvol
Creates, deletes, or lists a volume mount point. Mountvol is a way to link volumes without requiring a drive letter.
Syntax
mountvol [Drive:]Path VolumeName
Can I recommend Aaron Margosis' blog? It provides a lot of tips for running as non-admin. His PrivBar is very helpful. He also talks about scripts that launch other apps with elevated permissions without having to log off - they change the user's permissions (give them admin rights), logon as that user, launch the app, and finally reset the permissions, all within the current user's session.
There's a lot that can be done to enable software to play nicely under a limited user account. Sometime's it's not worth the effort, but in some cases changing permissions on select registry keys and NTFS folders can get things working.
Sure, this is a step in the right direction, but it will have zero impact on most users, for two reasons.
1. Most users will just log in as an admin and stay that way forever. Far easier and quicker than typing a password every time you want to install software.
2. Social engineering. By which I mean a pop up box saying "type root password here to see Paris Hiltons tits!". If Joe Sixpack actually used Linux, it would be no more secure than windows, because he would dish out that password every time a dialog asked for it. Or he would get so tired of typing it that he would resort to point 1.
"I realise this is not a very popular opinion but it's the truth, and there for needs to be said" -Bill Hicks
The ones that annoy me the most are applications under Windows that, when installed using an administrator account, "Fix" the permissions on my filesystem for me. I believe the software that came with my old Canon PowerShot (A40?) did this so it could store pictures in the program directory. I mean, ferchrissakes, there's even a bloody "My Pictures" directory that's writeable by the user!
Those are basically click-once managed-code apps that execute in a Sandbox.
Go somewhere random
The submission of this story is so incredibly ignorant it boggles the mind, and already in the follow-up posts it's clear that many participants of this forum really are clueless about Windows security in the NT and after world. Windows has had extraordinarily pervasive, and extremely granular, security for many, many years. The idea that they're going to adopt "UNIX like" security, dumbing down their security, is absurd.
What Microsoft is doing is quite simply forcing application vendors to follow the rules regarding expected user rights, rather than relying upon the "see the world" leftover of the Windows 9x era. Things like applications that store user data in HKLM, which itself is admin writable only.
In fact, let me take a quote directly from the article.
"The [LUA] framework we're talking about has been there for ten years...
THIS IS NOTHING NEW. Microsoft is simply going to start separating the wheat from the chaff among third party apps (hopefully they take a close look at their own as well) to ensure that apps don't require more rights than they really should.
So basically, there were conspiracy theories that it was done on purpose, but nothing definitive. Seriously, am I the only one who remembers this? I wasn't even sure it this behavior ever really changed, but it was enough to convince me to always get drivers from the manufacturer (not MS) and ignore the driver signing warnings Windows threw up.
You can do everything you want using Group Policy objects. Like another poster said , the problem is that it's hidden from the user and basically inaccessible from windows XP home. The other problem is the way it is implemented. Local Group Policy can not be applied to individual users or groups without resorting to cheap hacks. Even when you do the ACL trick you can only get Local Policies for 2 different users. The functionality for multiple Group policies to apply to multiple users groups and computers is there, It is just restricted to using over an AD domain. Obviously this was part of the plan to boost sales of Windows 2000. The point is the only way to get restrictive granularity on users on any given Windows machine is to invest in a Windows server , setup Active Directory and force users to log on to the DC. However you still have the Local User policy problem which automagically applies when there is no Domain Policy to be forced. Obviously the ability is there , it just needs to be implemented on all levels locally and over the wire. They could proaby do it tomorrow with a patch.
No matter where you go , there you are.
linkd.exe in the Resource kit does this. Alternatively, Junction.exe from Sysinternals.com does too. ahref=http://www.sysinternals.com/ntw2k/source/mis c.shtml%23junctionhttp://www.sysinternals.com/ntw2 k/source/misc.shtml%23junction>
The most bizzare one, in my opinion, is Battlefield 1942,
It's not really too wierd- it's actually a preview of the "remote attestation" features you may get from "Trusted Computing" next decade.
Battlefield 1942, like all online games using the PunkBuster anti-cheating library, needs admin rights so that it can examine every other program you are running, in case any of them is meant to help you cheat.
By running a game like that, you are not only giving that software full control of your computer, but also allowing the publishers to remote-control your PC whenever they like. TCPA may make this behavior more elegant and compartmentalized.
No, you don't. /etc/fstab to support what you want to do.
You have to be root and deliberately set parameters in places like
The real point is that there is an established model that is documented and understood for setting up a system under GNU/Linux.
Windows is finally awakening to the requirement, and knowledge is finally getting spread through the likes of Non Admin.
The real difference is one of attitude:
Windows: user == sheep
GNU/Linux: user == shepherd
Get thee glass eyes, and, like a scurvy politician, seem to see things thou dost not.--King Lear
'Being root' and running a SUID CD burning application is rather different. In fact, it's entirely different, since you're granted no special rights as a user.
/etc/fstab is for, specifically the user flag. That is indeed a bogus claim.
You do not have to be root to mount anything. That's what
Most programs can be installed as a regular user under $HOME. I've done it many times on systems where I have no root access. This includes everything from Lua to GTK+. In fact, very few Linux programs require root access to install and use properly.
Either you haven't used Linux, or you haven't bothered to learn how to use it properly.
Wow, so you mean that things are locked down by default and you have to specifically enable things like letting users burn cds or mount things?
You have to be root to install almost anything.
Yes and no, some programs allow you to install to your home directory and then you don't need any permissions. Other than that it's the same for any OS, windows included.... it just happens to be that with windows everyone's usually an admin.
You have to be root to mount a CD-ROM, USB device like a dongle or camera, SMB share or floppy.
You have to be root to burn a CD.
chmod my friend...
Now, everyone is going to start screaming that the above trollishness is bogus but, it isn't. Sure, you can easily get around most of this stuff and many distros do. How? They get around it by either giving world writable access to the device or by SUID on the application. It's really no different.
Actually it is very different and you don't have to give world writable access to the devices in question if you don't want to. Have you ever heard of groups? You could for instance make a cdwriter group and then assign users you want to be able to burn cds to that group. The big difference is that there is no way to really do this in windows. You're either an admin or you're not. Giving someone access to write to a cdrom drive won't allow them to say accidentally install some virus. If they do install some virus, it would be limited to things they have access to.
Oh and it's this way with all Unixes, not just Linux. I for one am glad to see windows is finally catching up to UNIX, hopefully they won't mess it up too badly. This wouldn't be the first time I thought windows was going to do something good, only to find they implemented it wrong or introduced a whole slew of other problems.
You have to be root to install almost anything.
Just to point out that almost every piece of software can be talked into running from a user's home, or if the default binary will not, it almost always will when recompiled. On Windows what choices you have ? That's right, admin or the highway. With cdroms, usbs, cdburning, one or some users can be let to do it easily while the rest still kept outside. And hell, this is a very good thing. Just imagine a multi-thousand user unix server where all users have access to these stuff. But at home, who cares ? Unless, of course, if you want to keep your little sister or old mum out.
It's really no different.
What it's different though is that on unix/linux you can do these things because you can, that is if needed, they are there. No fuss, just self evident that you have the tools you need (and added to that, yes, for you those who always keep saying acl/linux is a myth, it is not). On Windows ? One just keeps wishing the tools that exist are good enough to keep the darn thing safe and usable for a few months in a row, and even that longs for the Guinness.
I am putting myself to the fullest possible use, which is all I can think that any conscious entity can ever hope to do.
Try a product called Deep Freeze. Won't matter what they do to screw up the machine then...a reboot resets the drive to the original image state. We use it in labs and desktops now.
As the way it should be. This is the reason why I and I'm sure a lot of other people don't run windows. In Windows, anybody can muck up your system. In *NIX, it's a lot harder. Hell, the run as service doesn't even work very well in Windows. Speaking of, does anybody else notice how Windows is reverting back to UNIX? There is speculation that NT is based on VMS (VMS -> WNT is incrememnting a letter, check the safemode stuff with disk0/part1/ nix type stuff). further reading
Mount points have been supported since 2000 in Windows. And hardlinks. ACLs and multiple streams per file were supported almost from the very beginning.
Before bashing something you should at least RTFM, otherwise you just look like a typical teenage Linux zealot.
Anyone can sign thier manifes (assembly), but if its not from a trusted source, you get a warning saying the cert could not be verified.
You're thinking of what happens when the action for "Install unsigned software" is set to "Prompt". The worry is that Microsoft will set it out of the box to "Disable" rather than "Prompt".
Actually, some versions of Unix such as FreeBSD have support for access control lists. This is not in the kernel by default though.
Right on! There are dozens if not hundreds of programs that do not work unless they are run as administrator. Instead of fixing these applications, the vendors (eg. AutoDesk, SolidEdge) just says to give users Power Users (which is almost administrator) privileges.
I used to think this problem would go away as developers right with NT/2000/XP in mind but after more than 5 years since the release of 2000 this problem still exists, even with NEW applications.
IMO, this isn't a Microsoft problem, but lazy or ignorant 3rd party developers.
-sp-
Then you would be correct. Many of the original NT designers worked on VMS at DEC, including their lead architect.
Here's the story: http://www.windowsitpro.com/Articles/Index.cfm?Iss ueID=97&ArticleID=4494
This was why I had to drop Winamp. My choices were to either run Winamp as Administrator or not have access to the media library function.
Winamp is a TOTAL pain in the ass when it comes to running as a limited user, but there are a few ways to get it to work right without running as admin. The first, obviously, is to install Winamp to your user directory. This is not the most secure method, but with some care it can be (relatively) safe and certainly better than logging on as admin. The other way is a bit more complicated and involves a plugin and directions that can be found here.
If you use filemon and regmon like any decent admin you will quickly find what you need to make these work as the LPU. I work at a school and have spent days making games meant to run on win95 that wish to write anywhere and everywhere work for guest accounts on XP.
That's what /etc/fstab is for, specifically the user flag.
Most distros use the owner flag instead and set ownership of the device in a script when logging on from the console. There is no good reason to allow someone who isn't actually sitting at the console to mount or unmount removeable media, and plenty of reasons not to.
As far as installing as a regular user, you are absolutely right, as long as the program doesn't want to use ports under 1024.
- None can love freedom heartily, but good men; the rest love not freedom, but license. -- John Milton
Read Windows NT and VMS: The Rest of the Story
Just because marketing says it's "new technology" doesn't make it so. NT originally referred to the codename N-10 Intel i860 CPU that it was going to run on.
If I run a malware email attachment as a normal user on my Windows box, it can damage at most that user's profile. That user doesn't have permission to write to anything outside their profile, and so can't damage anything else. Before it can even run, the directory or hash for the binary can't be on SRP's blacklist and the user needs file execute permission.
Although SRP wasn't introduced until XP, everything else has been true since the first version of NT. Show me malware that can bring down an entire Windows system when run as a normal user.
If you're running it as admin, then that's the first problem, isn't it?
Let's go over this week's list of problems:
1) HP scanner software - as administrator, works fine. As user, press a button on the scanner and the software can't find the scanner (!).
2) Norton Systemworks - as administrator, updates just fine. As user, can't run updates.
3) Turbotax. Same as Systemworks.
And that's just this week!
I don't use systemworks or turbotax here. For your scanner, I'd try giving the Users group rights to the program directory and then have it update the children folders.
Also, make sure you're letting the company know that you don't like that their product was writen assuming an insecure machine. It's the developers fault, not MS.
Take palm for example. It's a real bitch to get set up to run as a user. The software for a blackberry, which does all the same things, and more, has no problem being installed by an admin and then running as a user.
2 & 3 - of course you have to be administrator to run updates.