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."
Whilst this is a step in the right direction, Id be willing to bet that Microsoft will put a hefty fee on the LUA Pricniples program, putting it out of the reach of a lot of smaller software houses.
If this is the case, then users will once again become used to just allowing any old piece of software to install with higher privileges, totally defeating the purpose of this.
How many people do you think abort the installation of unsigned drivers, even when XP warns them that they are unsigned. I'd presume it is a very high percentage.
You can lead a horse to water, but you cant make it drink.
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.
It's about damned time this issue gets addressed. Every day at work I have to fight with this M$ limitation. Chief among the offenders are:
- Kodak Share software
- Autocad
- Any serial port emulation program
- PowerDVD
Most users must be elevated to Power User status on their machines to allow them to do anything nowadays, while there are plenty of programs (like the ones listed above) that will malfunction or simply refuse to work with anything less than full Admin rights. Sometimes, I have no choice but to give a user full Admin rights...I grind my teeth as I do so, knowing full well I'll be called to disinfect the machine of countless spyware programs within weeks, if not days.
____
~ |rip/\/\aster /\/\onkey
Microsoft also proposes application manifests, which allow developers to define the permissions an application needs to operate properly
I recall a few years ago when all applications even MS Office came with this type of documentation so that Netware administrators could install the software and configure the "rights" properly.
I had recently encountered a few Windows applications where permissions were a problem and I was reminiscing about just that. Serendipity?
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.
This might not change much, windows users are generally lazy. I see most people will just log in as an administrator and stay that way forever. The article didn't mention how easy it would be to switch to an administrator either like unix's su. No matter what microsoft does security will always be a huge problem, users don't want to change they like it easy.
No the Microsoft permissions in Longhorn will be different from Unix permissions... :-)
They'll be patented.
well, it will once MS finally patents them like they did sudo.
http://taint.org/2004/08/20/024522a.html
--
Check out my music video!
--
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.
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.
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.
The Tao of math: The numbers you can count are not the real numbers.
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!!!
NTFS already has mount points. The interface to use them isn't entirely obvious, but they're there.
(Not that I don't agree with the general sentiment that Windows-style drive letters should be eliminated.)
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.
I think the idea here is that the user could install a program to their "My Programs" folder - much like how when you run ./configure under [li|u]nix, you can pass --prefix=~ to install it in your own personal directory instead of system wide. May increase disk space requirements, but I personally would love it - each user can install their own software without affecting each other - great for terminal services environments... (IMHO)
. Define sqrt(x) as something really evil like (x / rand()), and bury it deep. Watch your coworkers go nuts.
Thank God. I can't count the number of times I've had to deal with the stupid permission settings in Windows. Even for a simple thing like sharing files and folders over a home network. Their system is so convoluted and just completely stupid - pointing and clicking through various menus to set attributes... conflicting attribues... and all kinds of other crap. I was trying to set up access permissions on a home networked machine whereby it would authenticate against another machine on the same network. But you can't do that with "Workgroups". Only "Domains". All I have is a small home network of 3 machines - I have to set up a Domain Controller now? Why the distinction? All the "features" that microsoft has for their permissions system are simply inane and counterintuitive. To keep myself from pulling out all my hair, I just set the permissions to Everyone so that everyone and their mom on the home network can access the folder. But since it's just me at home, that's alright. And even then I've had trouble with that.
I'm glad they've decided to scrap it and move to a more unix-like. The next thing they should do is change their "automated task scheduler" tool. Make it more like cron. "at" just sucks.
Vivin Suresh Paliath
http://vivin.net
I like
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.
After all, the next Windows will be a version of BSD, a rip-off of Mac OSX. Claims of BSD's death are greatly exaggerated.
The Uncoveror: It's the real news.
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.
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
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+
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!
For those who have never really thought about this issue (drive letters vs mount points), here are a few of my thoughts on the issue. I'd welcome people to comment on why they think drive letters might be a good idea. Does anyone know why drive letters were originated? An inability of early DOS-like systems to do mount points that never died?
..Docs & Settings\myuser, the network would gain more transparency. If you change jobs, you don't have to learn a new drive letter scheme (no big deal for us, but think of the users...won't someone think of the users?).
Although *nix has had the problem of strange names (a legacy thing) and changing naming conventions (/srv, etc) the idea that for the most part, you always go to the same location for the same thing is great. With drive letters, sometimes a cdrom is D sometimes E, somethings xyz...when you get into network drives, things are at the whim of the guy that setup the scheme in the first place. Is my user drive F or G (my workplace currently maps both).
If instead the user drive was always mapped to
Anything that can be done to make things seem more transparent to a user without obfuscating other aspects of the system is good imo.
-Ben
# cat
Damn, my RAM is full of llamas.
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.
...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.
I think Microsoft needs a cattle prod for their Longhorn, to get it out the door.
Nice to see they're considering adding features added to other OS's 20 years ago, though.
+++OK ATH
Microsoft is excellent at deflecting criticism by promising fixes, then delivering what are only modest improvements.
When Microsoft software has an obvious problem that competitive software does not, the general pattern is that a) Microsoft claims the next release will fix it; b) the next release falls far short of a fix but is nevertheless a noticeable improvement; c) applause from Microsoft fanboys drowns out those would observe they still haven't achieved parity with the non-Microsoft state-of-the-art.
Since Microsoft users live in a sealed universe--they're too busy keeping up with security patches, changes in API's, and evolving purchase and licensing plans to have the time to ever use any non-Microsoft software--Microsoft gets away with this pattern of "big promise, partial delivery"
Complaints about Windows 3.0 instability were met by the assertion that you "would never see a UAE in Windows 3.1."
Complaints about FAT fragmentation were met by assertions that NTFS would not require defragmentation.
Comments that Windows 3.X was far less usable than the Mac OS were met by assertions that Windows 95 would be just as good as the Mac.
Complaints that installing software under NT 3.x were met by assertions that NT 4.0 would not require rebooting....
"How to Do Nothing," kids activities, back in print!
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.
There are no trails. There are no trees out here.
It is a problem. A user should be able to bring their own software to a system, sit down, and use it.
What they shouldn't be able to do is harm the system in any way by doing so.
"Who is the Journal of Quantum Physics going to believe?" --Stephen Hawking
Unix permissions _do suck, they're too simplistic and ACLs solve a lot of the problems inherent to it.
The UNIX® permissions model has had access control lists pretty much forever. Every user can belong to one or more lists of users called "groups", and each file designates a set of permissions ("Access Control") for a group ("List"). Some file systems allow for more sophisticated ACL behavior by specifying more than (access control, group) tuple.
But ACLs are broken anyway; the next wave of permissions architecture is capabilities, as seen in EROS and other research operating systems.
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...
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".
Those who don't understand UNIX are doomed to reimplement it. Poorly.
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.
Blah. It's a good thing iTunes rocks.
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
Adding a meaningful permissions scheme will either kill many of my kids games, force a repurchase, or give me loads of headaches. When we got an XP box, I thought "Great, no crap installed by teenagers." Then I found that none of their games would play without write ability to the game directory in 'Program Files'. So guess what? They are administrators, too. We're not talking small stuff or fly-by-night companies. My kids have worked very hard to keep EA Games in business. I'm glad they will be out of my house when Longhorn comes around. Let the university's tech support sort it out with them.
There were similar problems with Eudora which my wife uses for email. So, she's an admistrator, too. And Eudora had its own headache under XP--she and I could not share mailboxes as we had done under Win98, even if the mailboxes were in a shared directory.
Good thing I have my own Linux box. When the kids and their games leave, I'm getting the Mrs. a Mac and shinning on we're-all-administrators-here Windows for good.
"Love is a familiar; Love is a devil: there is no evil angel but Love." --William Shakespeare ('Love's Labors Lost')
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.
Who is going to be the admin for home users?
What's the difference when you look at the end result? Very little. Users are still able to install Banzai Buddy, Gator, My Cool Search, $20/min. dialer programs, etc. The only difference is that instead of ghosting to restore a hosed system, you only have to delete the users profile/home directory after backing up the data files. Big whoop. You just saved a 1/2 hour of downtime for the user and 10 min. of administrative time involved in ghosting.
Ideally, only admins can install programs. Users home directories are for storing all their user data. If you need to lock it down further and prevent executables that don't need to be installed, you can use group policy to lock down allowed executables. The technology for doing these things is there. The problem is software developers with no sense of security. This is a developer problem and will exist regardless of the platform. If Windows had the luxury of having the majority of their users and developers being geeks with an iota of security concern, Windows wouldn't have such a bad rap.
-Lucas
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
"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.
I know I'm going to get flamed horribly for this, But I consider this a downgrade. The Windows permission system (which is essentially the VMS permission system) is far better than the one for Unix offering much better controls especially for large scale servers where administrative responsibilities are divided between teams. I think the real problem with Windows is that it didn't go far enough in implementing the VMS permissions model. On VMS its common for highly privileged users to run in an unprivileged state with few privileges except the power to grant themselves most privileges and then do the following:
a) Run in an unprivileged state until they get a privilege error
b) Determine if they really want to do the thing that caused the error
c) If yes temporarily grant themselves permission to do this thing. This is sort of like sudo but only grants one particular type of privilege not everything at once
d) Try again. If they get another permissions error on another permission repeat steps b and c.
e) Once successful (or they decide not to complete the action) then lower their permissions back down to their normal level.
The closest analogy for people haven't used VMS or a mainframe would be OSX when it asks you specifically before you do an administrative task.
This is way safer than Unix's system of permissions. The problem is that applications just fail for lack of privilege and the interface doesn't make it easy to bump all over the place. Frankly I think adopting the Unix model with less fine grained privileges is a major downgrade to NT. The problem is with the applications (including those written by Microsoft) not the OS.
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.
On another forum I noted the howls of indignation and protest when Mac users who were used to the old System software took the leap to OS X with Unix permissions and accesses.
A number of us did our best to try to dissuade users from operating in "root" or god mode because it is dangerous. I recall being flamed for having tried to tell one poor soul about how he had regularly and routinely messed up his system by doing that and that if he decided to simply create a user who could administrate the computer, he'd be fine.
"I realize you want the operating system to 'be good' and work that way, but it doesn't. Sorry about that."
And now Microsoft is going to adopt Unix permissions. How wonderful. Apple has a pretty smaller user-installed base. I believe it's growing due to their hardware, like the iPod and their new Mac Mini but it took some patience from Apple gurus as well as Apple to help people over that "permissions things" hump.
Compared to that little dustup, Microsoft's adoption of Unix permissions should be a lot like dropping a 20 gigaton thermonuclear device on the computing world. Apple released a "Repair Permissions" script which should be run regularly after updates to verify and change back any mangled permissions. I'd imagine Microsoft will do the same -- in about three years
Gods don't kill people, people with gods kill people.