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."
I think that it's a good start and may well make a big difference in companies which use Windows as their desktop platform and have system administrators who can control user accounts.
This section from the article seems to have a good point: A strictly enforced LUA model could make it harder for worms and viruses to take over Windows systems. But Microsoft may have a tough time changing user and developer behaviour, even with new features that support the LUA regime in Longhorn, experts warn.
On home systems, we still currently have enough problems trying to convince people not to open dubious attachments, or with people giving sites permission to install practically anything on their machines. It will take a big shift in attitudes (or Microsoft forcing the user to jump though hoops) to make many home users have anything but admin-privilege accounts.
The permissions will permanently be set to 777.
The problem has never been a lack of permissions in NTFS, just that no one uses them well.
Windows permissions are better in the sence "more advanced", but more advanced may also be translated to harder to use. Unix security is great for system files but not as good for user files where more advanced ACLs have the advantage. Most security is in the system files and it should be kept simple for the sake of correctnes.
Unix are beginning to get ACLs now with some implementations but I don't ever see it going down to the system files.
Note that the discussion isn't about using literal Unix-style permissions -- the title is rather misleading. NTFS permissions are very good; in some ways, they are superior to classic Unix permissions (but not necessarily to Posix ACLs).
Instead, the Windows security model is (apparently) going to be more Unix-like, in that the demarcation between administrator (root) and normal user will be more strict. Mostly, this means making software developers allow their programs to be installed and run with limited permissions, unlike the current admin-fest.
There are many ways that Microsoft could fuck this up, but I hope they don't. Unlike some people, I have no investment in constantly repairing ruined systems.
While this has been a long time in coming, problems are bound to accompany a change of this large a scale. I see the biggest problem being older apps that do the job, but aren't under development anymore. As well, it would be great if MS could implement something that follows along the same lines as the su command for *nix. Just a quick userswitch at the command line, install a program, and bam, done.
Expectations are for the unprepared.
I'd like to add that I hope that some of the software developers will start to consider that people will be running their software under another account other than "owner". I have a game, that no matter what I do to the permissions, will not run under any account other than the owner/administrator. /. regarding Windows security and permissions and I haven't had my machine corrupted - yet (knocks on head) Knock on wood.
I'd also like to point out that I've been following all of the suggestions and tips on
Thanks guys!
But here's something that worries me more about manifests:
Based only on this part, it appears that an application manifest must be published by an entity that can afford three figures USD per year for a code signing license. Developers of free software and proprietary freeware often cannot afford this annual fee. My worry is that Longhorn Home Edition may not permit users to install customized deployment manifests, locking users into using only programs with an application manifest, that is, proprietary commercial software.
...maybe now someone could introduce them to the concept of mount points?
The gift of death metal does not smile on the good looking.
I guess what they'll have to be innovative at is implementing it in such a way that it'll be secure, without breaking old software, but breaking old user/developer habits which caused the mess that requires them to implement this now.
AC comments get piped to
After reading the article *gasp*, I wouldn't say Microsoft is moving towards a UNIX-like security system. Rather they are moving away from a stupid security system.
There's nothing inherently UNIX-ish about not giving normal users administrative privileges. Unless you're defining UNIX as any multi-user operating system. The idea of limiting normal users is standard in any decent multi-user operating system.
From the article:
"90 percent of Windows software can't be installed without administrator access to Windows"
This is a problem?
Installing software is an administrative task, not a user task. Software installation *should* require admin access.
Just one more example of MS not understanding the difference between administration and use.
This isn't Windows switching from their ACL model to a UNIX permission model.
/finally/, forcing the issue.
One, they are pushing for 3rd-party developers to finally stop requiring simple apps like kid's software and low-end desktop publishing to be run with escalated privileges.
I mean, these application developers have had since '98 or '99 to work this out. But Window's lax defaults and lack of user education didn't force the issue. Microsoft is finally,
Two, it is Microsoft finally realigning their default ACLs to be at once more secure and more common sense.
It makes no sense for a home user to not be able to control their power settings or change their system time unless they have escalated privileges.
Really, this isn't so much Windows following UNIX as it is Windows following OS X.
Finally, and this is IMHO, going to a permission model would be a *huge* step backwards. I know UNIX die-hards will flame me for this, but it is my experience that ACLs are much more flexible and lucid than permissions.
obviously no deficiencies vs. no obvious deficiencies
Unix permissions _do suck, they're too simplistic and ACLs solve a lot of the problems inherent to it. For example, if I want to define a class of groups where each group defines a set of people allowed certain permissions to a directory, recursively, there's simply no way unless you use a filesystem that has an ACL extension (or something like XFS which has ACLs built in).
The article poster's saying "Unix Permissions" was being misinformative; Windows will never use the setuid-user-group-world style permissions, it has an ACL-like system. I think what's really meant is that this system will actually be USED in the future, it's pretty much ignored right now for most Windows desktops. As I read this, Microsoft will just be actually enforcing and organizing their own system -- which is a good idea.
If you say "here goes my karma" I will bite you!!!
Seriously, the security community as been screaming about this for years just so MS could have parity with other multi-user systems. Of course, the big issue will be pushing other software vendors to compliance. Regardless, at least average users may finally not (by default) browse the web with an admin priveleged account. That should cut down on a lot of the malware issues that are encountered.
Just as the login process forks and drops its root privileges before running your shell, the file manager or window manager would fork and drop its full user privileges before running an application that was supposed to wear a certain hat.
I'd love to blame Microsoft for their own operating system problems, but really, the blame is mostly on the third party developers.
It has been this way from the beginning... as far back as I can see, developers skirted the BIOS because BIOS calls were too slow -- that was back when the BIOS was part of the OS. This is not a Microsoft problem, but it adds to understanding of how the culture evolved. "Forget about standards and interoperability, we need to deliver performance!" The error in judgement has been costly.
Today developers continue to write code that uses and exploits bugs and irregularities in the MS Windows operating system environment. If I learned nothing else from reading the comments found in the Windows Source code scandals, I learned that Microsoft became obliged to add code to emulate bugs and irregularities for specific applications to continue to run properly. In a perfect world, the app writers would write code using the APIs as documented. (And when bugs and irregularities were found, Microsoft would FIX them to discourage developers from utilizing the strange or buggy behaviors)
Developers should be mature enough to realize that any bug or irregularity found in an OS API should be considered subject to change and could break their software once it is fixed. It kinda bugs me that these "paid professionals" were and continue to be so short-sighted.... (meanwhile, these Open Source Amateurs rely almost exclusively on documented API functions and features simply because bugs and irregularities are often fixed quickly enough that to write code against them would mean they would need to update their code AGAIN.)
I think this kind of speaks volumes about where the real weakness in commericial software development lies -- in the motivation.
This doesn't solve all problems for Microsoft, just changes them.
While this will be a certain benefit to corporate environments with IT security policies and IT departments to come install/upgrade software for employees while at the same time ensuring that new version of FreeCell you got from a friend doesn't infect the whole corporate network, the issues become more troublesome for home users.
A home user will either end up running their system as an Administrator, thus circumventing the access permissions model, and/or they will become frustrated with the inability to install/update/access/delete files on their own computer.
How many times has the home user faced a property configuration wizard that tells them to contact their "system/network administrator" for more information.
My mother is not a "system administrator", but yet, to change her ISP, she had to put on that hat or call me to talk her through it.
No disrespect to Linux, but Microsoft would do well to study Apple's model for system security on a home implementation. Apple has, successfulyl in my opinion, abstracted much of the user security model to allow the home user to know nothing about CHMOD while still providing appropriate security when needed - like entering an administrative password (SUDOing the application) for installations and upgrades.
Last on the list of needed changes to the windows security model is to provide far more robust error/exception handling when a user does something like tries to rename a file that is open. Consider this closing argument:
"The file cannot be renamed because it is in use by another application."
versus
"The file 'foo.doc' cannot be renamed to 'bar.doc' because it is opened by 'Word.exe' would you like to:
- Cancel the renaming
- Save the document changes in Word and rename the file
- Discard the document changes in Word and rename the file"
I only came here to do two things; kick some ass, and drink some beer...looks like we're almost out of beer.
The problem I've always had with Windows permissions is that it's damned-near impossible to debug permissions problems. After two or three attempts with completely uphelpful error messages, I don't have the time to figure the exactly proper config, so Full Control it is.
If it were easy to tell what the problem was, it would be easier to have a secure system.
You have to be root to install almost anything.
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.
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.
In reality that is what drive naming convention does. Especially using F: for a networked folder \\filer\production Behind the mask of C/D/E could be the \\devicename\partition\ Just windows gives you the convience of the drive name.
----- You know you have ego issues when you register a domain in your name.
I can easily see Microsoft patenting this technology once they have it implemented.
This can only further limit other OS's.
To me it feels more like a race between MS and OSS programmers to get the technology out there to be 'previous art' before we get shut out in the cold by our own legal system.
Get paid to code OSS
Unix permissions are actually better anyway because they are much easier to work with. It's very easy to write shell scripts that deals with user/group/other permission, see what the permissions are in output from ls, modify in GUI dialogs (see Finder's Info panel for example). If also lets the entire be specified in a fixed-size integer in the inode, which makes file access faster.
... with the + to indicate ACLs are present for the file.
What's needed is old unix permissions + ACLs to handle the exceptions. So the ls output might be: drwxr-xr-x+
# cat
Damn, my RAM is full of llamas.
...but getting older programs working in XP was bad enough. Something like this is probably going to break 3/4 of the old Windows software out there, a nightmare for those of us in the corporate worlds. Cause, you know, Sue in Financials has 10 years worth of expense reports locked up in PeachTree Accounting 4.4 for Windows 95 and doesn't see why she should use anything else, and Doug in Facilities has a master key database in dBase 2.5 for DOS that nothing on the fucking planet can read any more.
Ugh, I'm already seeing the problems.
The one nifty thing Windows had over Unix in terms of security was VMS-like "Access Control Lists." While overkill for your average file server, when you get involved in large multi-user environments they REALLY help manage resources.
They are likely doing away with ACL's because they really slow down performance. Instead of checking two bytes in the file entry, you have do a database lookup, that can chain on and on if you have a complex set of rules.
(I implemented an object oriented ACL system for a website. If that qualified me to have a technical opinion.)
"Learning is not compulsory... neither is survival."
--Dr.W.Edwards Deming
The problem with the NT security model is that they violate an important principle of security: they aren't simple. Simple security systems are not only more likely to be correct, but they are easier to use. Ever ask *why* so much Windows software doesn't bother using the security mechanism? Ever try to code to it? It's ugly and complicated!
A deep unwavering belief is a sure sign you're missing something...
Nothing in the article says that MS is getting rid of ACL's, just that they are going to start writing software that is function with local admin. Slashdot title is misleading (what a shocker).
Tons of software from MS & others on Windows won't work correctly unless user is admin (and support for su equivalent from Windows is weak).
It is like running everything as dba, sure its convenient, but you are just begging for trouble. Worse, when all software is written assuming dba, changing it to run as a regular user is painful. This is the same situation as most windows software is in. Pain will be worse the XP/SP2 by far.
MS should also added chroot to Windows if they are serious about security. Such a simple concept, such a valuable addition. Of course, much windows software goes boom if you introduce chroot, but they should still add it to Windows.
I never gave a damn if my drivers were signed or not - i wanted the device to work, and if that was the only driver i could use, screw windows. :D
But sensoring the internet isn't always the solution. They sensor us here at work (I'm a developer), whereas most of the blocked sites probably should be blocked for normal users, but for our job it is getting harder and harder to get help or find examples and such when programming on a project. Google groups are blocked, all msdn blogs are blocked, most sites with the word "forum" are blocked. And it isn't like they are going to unblock these sites for us because they are useful for us.
For those of you sitting behind the proxy - don't forget that some people probably legitimately need access to the site you just blocked.
Sleep: A completely inadequate substitution for Caffeine.
The broader concept is that of putting processes in little restricted-filesystem "jails," which is perfectly applicable to Windows. A process could think that it's dealing with C:\blah when it's actually in C:\Program Files\Applications\Thing\blah. Expanding on the idea, you could expose a CD drive, but keep the DVD burner hidden, and so on. Perhaps you could even hide your Internet connection from a less-than-totally-trusted process that shouldn't need it.
Mind the Gap
Tons of software? Not sure on that one. Only app I know that can't be made to run as user is Quickbooks. The rest just usually need an ini file (that developers put into the system root) or need write access to the particular program directory.
My network has everyone run as User, even the developers. All the tools and programs run just fine with a tweak here or there.
Microsoft had a version of the driver in the OS and on the Windows update site with a lot of OpenGL features stripped. It worked, but was a little broken and very slow, but Direct3D worked fine.
Holy shit, that's evil -- and shows exactly why Microsoft should have been broken up ala Ma Bell. MS has shown time and again that they will impede progress/interoperability to further their monopoly. Why do users stand for it?
The drivers that came with my motherboard are not signed, the driver for my monitor is not signed (it's quite old), I forget about the graphics card.. printer drivers not signed - what am i supposed to do? use my computer with the "default" monitor at much lower resolution and refresh rate than my monitor is capable of, and never print anything?
Can you be Even More Awesome?!
While many gamers are Windows users, very few Windows users are gamers. Unless the user is a gamer, the odds are good they'll never know there was a problem. If the user is a gamer, they're downloading the nVidia drivers from nVidia, and ignoring the older ones available on Windows Update.
End of lesson. You may press the button.
"Light-years ahead of anything Linux is offering" is only true if you're entirely ignorant of any security work done on linux. SELinux and grsecurity both offer features that NT entirely lacks.
And, as a response to my former post explained, "*incredibly* fine-grained" is also untrue. It's only fine-grained in comparison to UNIX permissions bits.
developers skirted the BIOS because BIOS calls were too slow -- that was back when the BIOS was part of the OS. This is not a Microsoft problem
... as if this memory mapped display was a 300 baud terminal!
It bloody well is a Microsoft problem. They had the ability to improve the performance of the BIOS, ANSI.SYS was frequently ten to a hundred times faster than the BIOS on a typical computer... all they needed to do was intercept the BIOS calls and perform the same operations they did with ANSI.SYS and they would immediately remove any need for people to go around them.
But they didn't. So your choice was ANSI.SYS, or direct hardware access. I went with the BIOS for my terminal program and half my code was "curses" style optimizations to avoid making extra trips into the BIOS
Similarly, the current mess with applications needing to write to %SYSTEMROOT% to install is Microsoft's fault, because for many years they recommended that applications do that... as near as I can tell so they could ship DLL updates through application vendors instead of coming up with their own update mechanism. The result of that? Administrator-level installers, DLL Hell, and viruses being REINSTALLED back into %SYSTEMROOT% by the system restore tools they created to try and work around the problems...
Not Microsoft's fault? Like hell it's not!
The idea of shielding applications is in the right direction, but the idea of virtual paths does not seem too usefull to me.
I would love to have the OS install an application, and then put restrictions on it. Games do not need to know what's in the "My Documents" folder; a Word processor should not be able to take over the screen like a game does. So we need to put applications within groups, and put default permissions on them (which the application can overwrite with the permission of the user).
Types of restrictions: memory uses, number of processes, threads, sockets, number of windows (and other widgets), file system access, calls to other processes etc. etc.
For this to work the OS will have to be on a different level then the current operating systems though, which are little more than glorified disk operating systems with a GUI. I mean, any install on Windows can mess up any other install, what's that about? And if the deinstaller is badly written, it can mess things up as well. Don't even think about talking dynamic link libraries, because that's what's really badly implemented.
Yes, there are many improvements in newer operating system, and I look forward to the new features in Longhorn, and I'll try out OS X out soon as well. Linux seems to be stuck with its age-old file based ideas, with applications spread out all over the disk. They are still more secure than Windows though, and SE linux is a good idea.
I'm a UNIX guy and I agree with you, actually. If the VMS security model is implemented properly on Longhorn (or if it was implemented on WNT), MS would have something legitimate to gloat over when talking about how 'archaic' UNIX systems are. But MS couldn't do that with WNT or Windows XP and it won't be able to do that with Longhorn.
Backwards compatibility for applications is one piece of the puzzle, but not the most interesting one. You can run applications in a virtual machine or a sandbox and solve most of the problems. Think of something between chroot and WINE as the new 'Operating Environment' for pre-Longhorn applications that need to think they're running as Admin when they really can't be trusted with Admin-level access. This is nothing new, and MS could have done it in the original WNT.
The main problem for MS is that they feel the need to talk down to their users. The command line is too complex for their intended audience, so they have deprecated it and made it less powerful in favor of endless graphical wizards that walk you through everything. VMS style privileges are too complex, so they completely ignore the issue until their users are screaming at them, then they cruft on UNIX-style privileges and ignore the better but more complex VMS model originally part of their design.
MS thinks everyone who uses their OSes, even sysadmins, is unskilled labor. That is why they don't give people powerful tools: Powerful tools are complex, and liable to turn in your hand if you don't understand them.
(The unansked question is why Linux or the BSDs haven't adopted the VMS privilege model yet. I hope that becomes an option someday.)
How can you use my intestines as a gift? -Actual Hong Kong subtitle.