(Is this your handiwork/did you create it? If so, I am very impressed!)
Yes, I am the author of SD Edit.
Thanks. I appreciate it:)
Your thoughts on my approach here are appreciated (as regards TheRaven64's questions about how to control access to ports & reserved ports (Tcp Parameters controls this latter part via its RESERVEDPORTS value (ephemeral ports on udp only, iirc))
What you and other posters have mentioned about port control (the port filtering control panel, ipsec rules, application level firewalls, ACLs on transport devices), plus the "Routing and Remote Access" service in server versions, cover everything I can think of. This is a white paper on TCP implementation notes and parameters you might find interesting.
Also, the object manager namespace can be browsed with winobj or winobjex.
Actually, the IO system has always been able to cancel IO operations, including by terminating the thread owning the operation. However, IO can only be canceled when the drivers owning the operation allow it to be, and Vista got rid of many of the places IO could block but couldn't be canceled in the standard drivers. MUP (which does UNC network host lookups) in particular.
I had the same idea about reaching the ACLs of objects without a convenient interface to them, so I wrote SD Edit. It even uses native functions when possible and supports case sensitivity. The ACLs on \Device\Tcp can be edited via sdedit t file tc ntapi n \Device\Tcp
One nitpick: while open sockets are indeed file objects, and starting with Server 2003 SP1 the endpoint drivers do support ACLs on open sockets, unopened sockets (i.e. the port numbers themselves) are not objects, and do not have ACLs. There are firewalls that can control access to socket operations on a per process basis, but they're implemented as special TDI filters with special rules, usually not standard ACLs.
I've spent some time implementing a security descriptor editor designed to expose ALL objects with NT ACLs, and if there was an program interface to apply ACLs to port numbers, I would jump at the chance to make it available.
The endpoint devices themselves, e.g. \Device\Tcp, DO have ACLs which are checked before allowing socket ops (at least in 2003 SP2). There is no standard interface to them, AFAIK. SD Edit can edit them with sdedit t file tc ntapi n \Device\Tcp or with Udp or Ip or Nwlink. The only thing you can really do is deny all network access on a transport, but that can still be quite useful. Execute + synchronize access is sufficient to open/create sockets. Read/write access allows reconfiguration of the transport.
The NT kernel provides a lot of facilities that are very useful for writing secure code. I often wonder if the application developers at Microsoft ever noticed that they weren't writing code on top of DOS anymore...
Ugh. I'm hearing you there. The momentum of DOS and Win95 single-user, no security software design is still a plague on Windows software.
Windows started wide open, and remained wide open for a long time, a lot of system software was written to be wide open, and even more importantly, a lot of system concepts, like activeX, were not designed with security in mind. Consequently, Windows security, such as it is, is an afterthought layer that was added to the original functionality, whereas *nix security, specifically linux security, is built in at the bedrock level.
Windows NT 3.1 was released in 1993, written from scratch. Even then it had a full multiuser security model, with security built into the base design. For that matter, the security model hasn't changed since then, except for the addition of a few axillary features: restricted tokens and auto-inheritance in Windows 2000 and integrity levels in Vista. Modern versions of Windows (2000, XP, 2003, Vista) are descendants of Windows NT, which is designed with a fairly rich security model, with ACLs and auditing for all sharable, nameable objects, centralized and local accounts, impersonation, granular privileges (i.e. not superuser or nothing).
Actually, most system services on Windows WERE designed with security in mind. Take a look at the filesystem, the registry, the security accounts manager, named pipes, or RPC. They all enforce security. ActiveX is the binary plugin model for inline objects in Internet Explorer. Mozilla/Firefox has its own binary extension system, same as most other browsers. The only mistake Microsoft made was in trusting users to not be stupid enough to install whatever extensions came their way.
Microsoft (and many OEMs) have made some bad default decisions, like making the first user in XP (likely to be the only one) an administrator. Some versions have left an excessive number of services open by default. Windows 9x didn't have any security, so ISVs have a lot of momentum invested in ignoring security features in the NT series. Maybe Microsoft could've done more to make those ISVs clean up their act, maybe not. Microsoft has had a long list of implementation failures that have been damaging to unprepared computers. However, these things are not security model or design issues.
If Windows's security model is so broken, and has been so broken, name a critical error in the Windows NT security system. Name something vital that its been missing since 1993, even before Linux was released 1.0. Since Windows uses such a different security model, one that has only recently been tacked on, being specific should be easy.
I don't know which books you've been reading, but Microsoft has had a logo program for Windows NT as long as it has been shipping that requires the multiuser design to be followed. I have an old.hlp file describing the Win32 API circa 1995 and it describes proper multiuser application design on Windows.
As for the registry and copying user settings: first, if you want to copy a user's profile to another computer, why not just copy the entire profile? Just copy the directory over, resetting permissions if necessary. That's what I'd do for a unix profile.
Second, OE has a fairly modular design (*gasp*). It uses MAPI (which itself is several pieces) for user identity, mailbox and storage, and it uses the user certificate store for user passwords and certificates. I know that the standard practice on unixes is to re-invent the wheel for each of those functions per mail client, but Microsoft decided create and document separate components. You have to make sure that the settings and data for each of these components, plus OE's own settings are copied. It's easier to either export the user's state (I do believe OE has a function for that), or just copy the entire user profile around.
There are a lot of advantages to breaking up a program into smaller pieces, but keeping track of all those parts (which tend to get spread out all over), is a major disadvantage. Just look at how complex the package management systems and package hierarchies of a major Linux distribution are.
BTW, I'm running Office 97 on WS2003 without issue as a limited user. Back in the day with the likes of NT3.51 and NT4.0, Office 97 was one of the best multiuser apps, even including special user workgrouping functions. I don't see why Vista would be any different.
Can you point to a single concrete example of where Windows "thinks it is better, wiser and more powerful than the user"? I've been using Windows for almost as long as I've been using Linux. (12 years and 15 years respectively.) I can't think what you might be referring to - could you be specific please?
Prior to vista, I can't think of any either. However, Vista introduces the concept of integrity levels, two of which are not directly accessible to admins, although there exist hacks to get around it. Restricted IE runs with Low integrity. Normal users run with Medium integrity. Elevated administrator processes run with High integrity. System integrity level is assigned to processes running as Local System. Protected integrity level is used for processes that touch/may touch protected content, including audiog and csrss. There is no documented way for an administrator to create or touch a protected integrity process (or object): a process has to either be a part of the OS or signed in a particular way to be allowed to run with protected integrity. This was apparently done for DRM. You can install a service to touch system integrity objects indirectly, though. Good luck creating an interactive process with system integrity.
Also, Vista requires you to jump through hoops to install unsigned kernel drivers, particularly in the x64 version. Prior to Vista, administrators had the authority to install whatever drivers without having to set any special (and potentially reduced functionality) modes.
It's true that there have been implementation flaws leading to vulnerabilities and the prorogation of worms. These were not caused by the actions of ISVs. Windows is not alone in having implementation flaws. However, implementation and design are two different things, and the topic of this story is UAC, Windows security design, and software that doesn't run with standard user privileges, which IS the fault of whomever wrote the software.
NT has always had local security. The Guest account, disabled by default, has even less privileges than members of the Users group. How would it be helpful for a full user to compromise that? NT 3.51 SP3 attained the Orange book C2 certification, which measures local security design. That wouldn't be possible if "any non-admin user could do anything to the system after login."
If you take a look at the database you'll see that the top death is listed as 2 civilians killed by "suicide oil trucks".
Picking the top item in the list is hardly a rigorous method of determining the relative causes of death. iraqbodycount.org doesn't seem to index by perpetrating party. So I found another source that does study the casualty rate caused by coalition forces, and they estimate 654965 extra dead over the same period, 26% of which civilian households attributed to coalition forces in 2006. However, they didn't study the circumstances of those deaths, i.e. whether the subject was combatant or not. So the question of how many people are combatant and is that what got them killed, is a very good question I'm not sure anyone has the answer to.
If you want to go back further in time, wasn't it the US government that put Saddam in power, and gave him those evil weapons of mass destruction?
No, and no. That's just another case of the America-caused-everything-bad-in-the-world silliness. Once a lie is repeated often enough, it comes to replace the truth.
I did not research that statement at all, and it shows. You're right: although we did give Saddam a handful of conventional weapons to fight Iran, the vast majority of them came from other countries, particularly the Soviet Union, China and France. The chemical agents also came from other countries. I apologize for spreading a baseless meme.
In the bombing of Berlin alone, more civilians were killed than in the entire Iraq war. Perspective is important. Civilians die, yes, and it's a horrible thing, but that's war.
You're right: on the grand scale of conflicts and wars, the 2003 invasion and occupation of Iraq is going well and is quite clean. However, all such conflicts are very expensive, deadly and wasteful. The alternatives have to be pretty bad before such a thing becomes the best choice.
If the US leaves, hundreds of thousands more die in sectarian violence, and Iraq turns into either an oppressive theocratic dictatorship, or it becomes a proxy state of Iran (same thing more or less).
Oh, I agree leaving now would be a disaster. This is going to take a while to finish. When I asked if it was worth it, I meant was it worth it to invade in the first place-- was invading really the best option?
Only in civilized societies. In Africa, and much of the middle east, a human life is worth less than a bullet. Don't be so quick to attribute your own moral judgements to the rest of the human race.
What's your point? Are you calling for moral relativism? That one person/one culture and its values is equally as good as another? It's nice that other societies care about life less. It's also irrelevant.
A soldier who kills a terrorist before the latter is able to trigger an explosive device in a crowded marketplace has just SAVED lives.
You can't tell me that all 60+k additional dead in Iraq post invasion were all enemy combatants about to blow up a marketplace. Suicide bombers are a tiny minority of the population, but the deaths there haven't been terribly discriminatory. The definition of a civilian is someone who is not involved in the fighting and posing no threat. The topic is civilian deaths, which compose the vast majority of violent deaths in Iraq right now. I have no problem with killing a suicide bomber to prevent him from carrying out his plans. I do have a problem with killing non-combatants just trying to get on with their lives.
If you blame every single Iraqi death on the US presence...
I don't. If you had read the two sources I put in the OP, they both are limited to counting civilian (i.e. no-combatant) violent deaths. The death rate has gone wayy up since the invasion. I quote from another source:
Key points of the study include the following:
An estimated 654,965 additional people died in Iraq between March 2003 and July 2006.
A majority of the additional deaths (91.8 percent) were caused by violence.
The proportion of deaths attributed to coalition forces diminished in 2006 to 26 percent.
Between March 2003 and July 2006, households attributed 31 percent of deaths to the coalition.
It's true that not all of the civilian deaths in Iraq can be directly attributed to coalition forces. Still, 26% of 63k is still 16k, a lot of dead people. Furthermore, the sectarian violence reponsible for so many deaths in Iraq between the Sunnis and Shiahs was definitely foreseeable as a consequence of invading the country. That puts part of the responsibility for those deaths on the invading force, too. Saddam at least had that violence under control.
Right now, our part is in setting into motion these events by choosing "invade" as the best option. That makes us partially (not totally) responsible for its effects. The way it's supposed to work is for the expected benefits to outweigh the costs that we'd be responsible for. I don't think it's working out that way.
If you want to go back further in time, wasn't it the US government that put Saddam in power, and gave him those evil weapons of mass destruction? Isn't the US govt. (at least partially) responsible for the people it puts into power?
Yeah, there's plenty of blame to go around. It's easy to lay it all on "them". Unfortunately, things aren't that simple or clean. Warring never is. Is it all worth it in this case?
It's true that military action, as ugly as it is, is sometimes the best option: when the benefits outweigh the costs. The costs of Iraq to both the Iraqi and American people has already been enormous, much more so than Bosnia or the others you mentioned. If the invasion and occupation of Iraq is really worth it, where are the benefits; benefits large enough to be worth the costs?
Oh, you don't think that the gang members are in any way responsible for recklessly shooting up the city? They shouldn't be held any more responsible than a good driver involved in a fatal accident? There's a reason that discharging a firearm inside city limits is illegal outside a firing range or special circumstances: firing guns in densely populated areas is known to be recklessly dangerous, and not just to your target. Invading countries is known to be very dangerous for its civilians. In order to have an accidents, there has to be a trade from known, acceptable risks for real benefit. Gang wars have none. Iraq has little at best.
One could hardly call our reasons for invading Iraq peacekeeping.
Still, you're right: killing for the sake of killing people (i.e. the Holocaust) is a little bit worse than killing people for idiotic reasons. One's premeditated murder, one's reckless murder. I shouldn't have lumped them in together so easily.
However, the damage per death caused is exactly the same, regardless of the motives of the killer. Murder is a high crime precisely because the death of a human being is a great loss. The issue becomes more a matter of how many people were killed than why, and the fact is that the US's invasion of Iraq has caused far more civilian deaths than Islamic terrorists have for American civilians plus Saddam's ethnic cleansing of the Kurds. Perhaps more even than all jihad suicide bombers. paranode seemed to be implying the opposite.
Regardless of the motives involved, our (US political) choices have resulted in a lot more dead, and therefore a lot more damage, than They(TM) ever have. With these amounts, why is secondary to how many.
You're right: malicious killing is worse than reckless killing. At least with reckless deaths, it's possible to have a higher goal to be working towards (than death itself). So, what is our high and mighty goal of Iraq anyway? Is it worth 60-600k innocent dead?
A death is an accident only if you're already doing (or not doing) what is reasonable to prevent casualties, leaving only a calculated, acceptable risk in exchange for some benefit. The invasion of Iraq itself is a big step in the wrong direction to be calling the deaths there from the invasion+occupation accidents.
These deaths were certainly foreseeable before the invasion started. Is malicious killing really so much worse than grossly wasteful killing? In the US legal system, second degree murder includes both intentional (but not premeditated) and reckless killing.
You're right, Iraq could be one level worse. There's a difference, but not a big one.
Oh yeah, because everyone knows there are no civiliancasualties in Iraq from US military actions. Civilian casualties are civilian casualties, be it from terrorism, military invasion, ethnic cleansing, whatever. The innocent are just as dead.
The forum was opened with the express purpose of getting feedback on pre-release versions of Vista. The topic categories range from "Windows User Experience", where the bulk of the posts are, including complaints that were definitely relevant to the Windows Experience (TM), "Windows Developers", the website itself, and misc.
I wasn't an official beta tester, either. I'm sure they had an official feedback method, and IDK if it was given more credence. Still, the Shell: Revealed forums were certainly an appropriate and official place to voice concerns.
You did say that the reason that "[Attacks on Windows] succeed so frequently because the security architecture of Windows is so poor." The only technical detail mentioned in the post was "A simple application like the IE web browser is tightly integrated into the operating system..." being a dumb idea. A link between them seemed to be implied.
If not that, then what exactly is so insecure about Windows's security architecture? I submit that the security design is more than adequate for a multi-user OS.
Just to get them out of the way, Windows certainly has a bad default of making the initial user an Administrator by default, and it's had its share of implementation flaws (same as most software). But these things aren't architectural flaws.
Microsoft tried that late in Vista development at the Shell: Revealed forums. We voiced many concerns, only a few of which got any attention, much of it hand-waving. No one from MS has posted there in a while now, so users have stopped too. A post about the new backup program, sdclt.exe and how much functionality it lacks compared to the old one, ntbackup.exe, was even deleted.
Someone at Microsoft thought it would be a good idea to get some public feedback on Vista development. Late, but good. But then, they didn't listen to our feedback. Some of the stuff we brought up should have been pretty easy to fix, but was blown off instead.
IE consists of a front-end launcher and a few shared libraries that implement parts of the back-end like an HTML renderer.
The only thing that the IE back-end is integrated with is parts of shell environment. It's a few shared libraries that are loaded into iexplore.exe, and explorer.exe when it needs to do HTML rendering. OSX has a similar architecture, called WebKit. KDE also shares Konqueror's back-end.
IE is just a few user mode shared libraries. It doesn't have hooks into the kernel. It runs with whatever privileges the user has; it doesn't have some magical security back door. It's not used by any system services. A vulnerability in IE can lead to the compromise of the process it is loaded into, but that's true of any library. IE's vulnerability record is awful, but it can only compromise the system as much as any of your other applications. If IE was a totally standalone program, its security track record would be exactly the same; it's (in)ability to compromise the machine exactly the same. If you run an app as admin, and its compromised, the entire machine is compromised. If you run an app as a normal user, and its compromised, only the user's account is compromised. IE has nothing to do with the security architecture of Windows.
In court, Microsoft said that IE was an integral part of the Windows experience, and that removing it would diminish that experience and break their right to sell a software package with whatever features they liked.
While I was in grade school, I was constantly told (especially by my parents) that school is the absolute top priority. Bar none. A program that eats all my time with steaming piles of busywork (to be completed 'because we said so') popularity contests (not that I cared much), with heaping sides of patronization and hypocrisy. Of course, learning was the official reason, but that always came off as hollow. They didn't didn't have the awareness or guts or something to be honest about what was really going on, and what the priorities really were.
I think you're absolutely right about people not taking education seriously. Teachers don't take it seriously; half of them just want something to keep the kids occupied, safe in making all of them suffer equally under BS assignments. Most people only care about how they're doing in comparison to their peers, so it's OK as long as everyone has to do it. I had more absolute standards. Referrals are useful to make kids that aren't compliant enough someone else's problem. At the peak, I received one a week, like clockwork, in 5th grade for noncompliance (they called it not being respectful and responsible to myself and others: the ambiguous catch-all rule). Most parents and teachers have no respect for kids, therefore the kids tend to not respect teachers, parents and one another. I did have a few teachers that were actually good, but they were the exception, not the rule. They also couldn't fix the system itself.
I was disruptive because I was bored, because I couldn't bring myself to work on endless pointless assignments, and because nobody was honest with me, knowing that official explanations (read:excuses) didn't add up. I preferred being disruptive to putting up with it. As it went on and on, I became numb and cynical. Maybe I lacked the maturity to see the big picture-- to put up with it, prepared to be different in the real world. Still, the only thing I would change is to use more intellectual forms of disruption, instead of just trying to escape it all. Maybe they would have listened more. Maybe not... and that's depressing.
As for bullies, by the time that was an issue, I was too numb to care what the other kids thought. Without the fear that most bullies thrive on, I was usually passed over. In middle school, one bully became a casual friend, and another caused more problems for me via the school admin. over a fight we had than he did personally. By high school, I wasn't even a target. I'm not sure know how the other kids fared in the same school. OTOH, I have problems making friends; connecting with people more than casually.
OpenGL was supported since around NT 3.51 (long before full Direct3d on NT). For games that used OpenGL + MCI for sound, NT was a fine platform for gaming. For example, the original Unreal runs great on NT 3.51.
I can think of a few things: the old backup program, ntbackup.exe, is no longer included. The replacement, sdclt.exe (Vista Backup) is a joke. You can't even select the files you want to backup, or put the output in a file of your choosing. It doesn't backup registry hives correctly and doesn't use volume shadow copies (both of which ntbakcup does). The ntbackup for XP or 2003 is incompatible with Vista.
Winhlp32.exe is no longer included (the file called winhlp32.exe is a stub that pops an error message telling you that a functional winhlp32 is no longer shipped), although for some reason its Win16 counterpart, winhelp.exe, is. Any program that uses.HLP files is broken. Some parts of the OS still use.HLP files for documentation (like the What's This? for the offline files share control page), so those links are broken now.
There are fixed promised, but OpenGL is still broken, or very slow with most video drivers.
The new sound system does not support any kind of hardware acceleration or features. Companies like Creative are scrambling to get game developers to adopt OpenAL with an end-run around the Vista sound system so that users aren't left with $300 sound cards equivalent to an AC'97. This does nothing for older games that depended on DirectSound for this.
UAC, for example, theoretically addresses user level access controls for applications, but realistically is presented by a UI that completely ignores what is needed to make it functional.
My point is that user access control has always been implemented in the NT line of Windows. The new features are for convenience, to make it easier to safely run low and high privilege processes side by side, for executables to tag what mode they should be run in, and a more automated interface. The back-end of UAC, the ability to run processes with different privilege levels even if based on the same user account, has always been present. The interface to it hasn't always been so great, but that's been fixed since 2000. You don't need pretty elevation dialogs or low and high privilege windows side by side-- you can use separate logons for that purpose, something that's always been supported.
Users care about results, even when they don't understand the mechanisms.
I agree completely. Unfortunately, there's no magic technological way for users who are willing to install anything and follow arbitrary instructions in the name of watching a funny video to have a secure system, short of a TCPA enforced whitelist of approved applications. User expectations in this regard are unreasonable. One must understand the system to use it properly and safely.
That said, I agree that UAC isn't implemented well. It'll just program users to click OK even more often then they already do, assuming that they don't just turn it off. There must be a better way of implementing it than Microsoft chose.
How much of that crappy software is developed with tools from MS that could encourage or discourage the proper methodology?
MS has always recommended that people follow proper multiuser security design. The "Designed for Windows NT" logo program has existed ever since the first release, IIRC. App developers have abused various parts of the OS in all kinds of gross and weird ways, and I can't think of any part of the docs or toolset that would encourage that kind of abuse, except perhaps that MS seems to have made a mistake in trusting the ISVs to be competent and to care about little things (like security). I've got an old.HLP describing the Win32 API circa 1995, and it's filled with information about the difference between user and machine resources, user and admin privileges, and securing objects. Unfortunately, it's safe to ignore the lot when programming for Win95 (safe in the sense that the programs will run on 95 but not NT), so that's what most ISVs have learned to do. It's easier.
The only reason that XP (and more importantly, most OEMs that preinstall XP) default to giving the user an admin account is for compatibility with all the 9x apps that don't follow the most basic tenants of multiuser programming. Microsoft (and the OEMs that went along with it) must have feared some kind of backlash from giving users standard accounts. Why else would they have done it?
You go to Google and type in "Vista unpatched escalation" among the top 10 results is sure enough CVE-2007-0843 an unpatched local escalation.
From CVE-2007-0843
The ReadDirectoryChangesW API function on Microsoft Windows 2000, XP, 2003, and Vista does not check permissions for child objects, which allows local users to bypass permissions by opening a directory with LIST (READ) access and using ReadDirectoryChangesW to monitor changes of files that do not have LIST permissions, which can be leveraged to determine filenames, access times, and other sensitive information.
This is by design, and it's been known about for a long time. Directory data belongs to the directory, not to the child files. Directory data includes a few pieces of metadata about files, including timestamps. Files do not have a list permission; the permission bit used for list children with a directory is the
Well, fine grained ACLs like the one they apply to IE, come to mind. A well defined userspace is easily supported by the kernel, for another, but is still iffy as their current implementation in Vista.
If you're referring to protected mode IE, it's implemented with restricted tokens and a mandatory integrity label, not an ACL. Both mechanisms are available to 3rd party developers since they were introduced (in 2000 and Vista, respectively). They were not dangling parts of the security model prior to their introduction. They are not necessary parts to a working multiuser security model. What necessary (to be useful and secure) parts of the NT security model are unimplemented or missing? How about in NT 3.1? Surely you can come up with more examples to the claim that "most of it is not implemented at all in any version of Windows" (emphasis mine).
Yeah, that's great, but because it was not the default setup for a normal user account to be created, they were rarely used and thus lots of things did not work when they did.
Actually, it was more because the 9x series had no security and very weak multi-user capabilities that sloppy programming in those regards just worked on the much more popular 9xes and gained momentum. At the time, almost all ISVs couldn't care less if the software ran properly on NT, let alone with LUA. The people who actually used NT at the time understood and used LUA. They just didn't have enough clout to insist on better quality software for the platform, unlike the Linux and OSX communities. The popular related OSes were the 9xes with no security, and users that didn't care. For that matter, most ISVs and users still don't care.
... there are several functions of MSOffice 2003 (mostly VB) that do not work unless you're an admin, and that is MS's fault.
I'm not aware of this issue, but if it's true, then you're absolutely right that Microsoft isn't following their own rules.
Still, I'm not aware of anything, aside from momentum in bad practices by ISVs, that makes writing software that correctly follows the standards of LUA and multiple users any harder on Windows than any other platform. Windows has about as much good software (that follows the OS design properly) as any other platform (most cross-platform apps fall into this category), but Windows also has a LOT more crappy software, which drags the average down.
There are a lot fewer malware programs in circulation and there are some technical hurdles it needs to get through that would not present if a user was logged in a root (which is not even something a normal user could probably figure out how to accomplish since the account is locked out by default.
Yeah, the app can ask the user for his password. If the user is, as I said before, giving the malware full consent, he will have no compunction sudoing the malware to root with a password prompt dialog. On my machine, I'd specifically have to select the malware for Run As... and select an admin user, with password. Is there some other hurdle I'm missing?
Umm, you might want to rethink that assumption. I don't think I've ever known a time when there was not at least one public, unpatched local escalation in Windows.
Ok, what's the one right now then? There have been some in the past, but not more than other desktop OSes AFAIK. Certainly not a state of constant publicly known vulnerability. Also, of the malware I've tested in a VM, not one has even attempted to escalate locally (or succeeded). They all assumed they would be run as an admin, and failed in strange ways when they were not.
More importantly, however, every OS that is not Windows has something in common. They have to give users what they want. If malware starts compromising machines, they have to adapt their OS to stop it or they lose money.
It's true that Microsoft is in a unique position not to care,
The NT core includes some great security framework, but most of it is not implemented at all in any version of Windows and it certainly is not brought to the average user in such a way as to make it of any real benefit.
What's not implemented, specifically? Although I agree that the interfaces to many security features are substandard.
You're talking about user level privileges, which are a step in the right direction (largely a finished step in Vista) but they are decades out of date as a sufficient security mechanism for today. MS is just now starting to motivate application developers to write for limited user accounts when 5 years ago they should have been motivating them to write for ACL limited application spaces with self-contained application bundles [...]
Windows NT 3.1, released in 1993, had full separation of user privileges. There were three classes of users by default (Administrators, Users and Guests), and new classes could be created with delegated rights and privileges. Tools that aren't specifically for administration have always been required to work properly with standard user privileges to obtain the "Designed for Windows NT" (or 2000 or XP...) logo. Microsoft can't force ISVs to write software that works properly with the security system, but Microsoft has been urging them to do so since the beginning. Microsoft's own software has been pretty good about following those requirements (except for the games department.) I remember specifically running Office 97 on Windows NT 3.51 as a limited user without issue.
It's always been possible to install stand-alone applications to a directory. Standard convention suggests you share common libraries with other programs that may use them, but they can always be put in the application's own directory instead. Since Windows 2000, the only supported method of installation is the Windows Installer, which indeed supports installation as a limited user for programs that support it (not many, I'm afraid).
This is not exactly a one to one comparison, since administrators on the different systems have different levels of privilege. Running as admin in OS X is still unlikely to ever result in you getting malware, even if you install pretty much anything you have any interest in with no research. That is not the case with Windows.
Is that because there is precious little malware developed specifically for OSX? If an administrative user were to give consent to installing a piece of malware on OSX, what technical barriers would prevent it from having free reign on the machine that don't exist on Windows? If it's in, it's in, be it root access on a unix or Administrators on Windows. (Yes, I know that an OSX admin != root, but an admin can certainly sudo malware to root, given the user's consent.) On Windows, I can try installing anything I want without admin access and not worry about infecting the machine or other user accounts. It's the same on other OSes with user privilege separation.
It was purely made from Marketing point of view because existing software wouldn't work anymore.
This is a solvable problem (mostly solved in Vista via a virtual registry). I'd argue letting the marketing department make design decisions is one of MS's biggest problems.
The virtual registry views and other API hacks like it are called compatibility shims, and there are indeed a lot of them to work around buggy and incorrect application behavior. It's hard to write them, and not all app behaviors can be fixed by a shim (e.g. games that insist on installing a kernel module for copy protection purposes). There is A LOT of software out there, and Microsoft can't (and shouldn't need to) fix it all. Even so, I'm not aware of any OS that goes to the lengths that Windows does in trying to make it all work all the time. If Microsoft makes too big a break, people will simply be instructed by the ISV to
NTVDM really does depend on the CPU being able to run in V86 and DPMI compatible modes. That's why the non x86 versions of NT couldn't run DOS or Win16 apps (but would have been able to if NTVDM was a full emulator, although the Alpha port did have a 486 emulator using unique Alpha features). Ntvdm.exe is a container for a Win16 or DOS environment instance, but it depends on the kernel NtVdmControl function to switch to V86 or 16-bit protected modes and setup traps as needed. Since NT doesn't allow user apps to access hardware as a matter of principle (unlike Win9x), NTVDM does indeed emulate some hardware components by trapping interrupt, IO and DMA requests.
I'm sure that Microsoft could write a full emulator if they really wanted to, ala DosBox, but I think they'd rather the whole thing just went away. When the VDM system was created for NT 3.1, full emulation would have been far too slow. The architecture has not changed since.
Slashdot Mirror
Thanks. I appreciate it
Also, the object manager namespace can be browsed with winobj or winobjex.
Actually, the IO system has always been able to cancel IO operations, including by terminating the thread owning the operation. However, IO can only be canceled when the drivers owning the operation allow it to be, and Vista got rid of many of the places IO could block but couldn't be canceled in the standard drivers. MUP (which does UNC network host lookups) in particular.
I had the same idea about reaching the ACLs of objects without a convenient interface to them, so I wrote SD Edit. It even uses native functions when possible and supports case sensitivity. The ACLs on \Device\Tcp can be edited via sdedit t file tc ntapi n \Device\Tcp
I've spent some time implementing a security descriptor editor designed to expose ALL objects with NT ACLs, and if there was an program interface to apply ACLs to port numbers, I would jump at the chance to make it available.
The endpoint devices themselves, e.g. \Device\Tcp, DO have ACLs which are checked before allowing socket ops (at least in 2003 SP2). There is no standard interface to them, AFAIK. SD Edit can edit them with sdedit t file tc ntapi n \Device\Tcp or with Udp or Ip or Nwlink. The only thing you can really do is deny all network access on a transport, but that can still be quite useful. Execute + synchronize access is sufficient to open/create sockets. Read/write access allows reconfiguration of the transport. Ugh. I'm hearing you there. The momentum of DOS and Win95 single-user, no security software design is still a plague on Windows software.
Actually, most system services on Windows WERE designed with security in mind. Take a look at the filesystem, the registry, the security accounts manager, named pipes, or RPC. They all enforce security. ActiveX is the binary plugin model for inline objects in Internet Explorer. Mozilla/Firefox has its own binary extension system, same as most other browsers. The only mistake Microsoft made was in trusting users to not be stupid enough to install whatever extensions came their way.
Microsoft (and many OEMs) have made some bad default decisions, like making the first user in XP (likely to be the only one) an administrator. Some versions have left an excessive number of services open by default. Windows 9x didn't have any security, so ISVs have a lot of momentum invested in ignoring security features in the NT series. Maybe Microsoft could've done more to make those ISVs clean up their act, maybe not. Microsoft has had a long list of implementation failures that have been damaging to unprepared computers. However, these things are not security model or design issues.
If Windows's security model is so broken, and has been so broken, name a critical error in the Windows NT security system. Name something vital that its been missing since 1993, even before Linux was released 1.0. Since Windows uses such a different security model, one that has only recently been tacked on, being specific should be easy.
I don't know which books you've been reading, but Microsoft has had a logo program for Windows NT as long as it has been shipping that requires the multiuser design to be followed. I have an old .hlp file describing the Win32 API circa 1995 and it describes proper multiuser application design on Windows.
As for the registry and copying user settings: first, if you want to copy a user's profile to another computer, why not just copy the entire profile? Just copy the directory over, resetting permissions if necessary. That's what I'd do for a unix profile.
Second, OE has a fairly modular design (*gasp*). It uses MAPI (which itself is several pieces) for user identity, mailbox and storage, and it uses the user certificate store for user passwords and certificates. I know that the standard practice on unixes is to re-invent the wheel for each of those functions per mail client, but Microsoft decided create and document separate components. You have to make sure that the settings and data for each of these components, plus OE's own settings are copied. It's easier to either export the user's state (I do believe OE has a function for that), or just copy the entire user profile around.
There are a lot of advantages to breaking up a program into smaller pieces, but keeping track of all those parts (which tend to get spread out all over), is a major disadvantage. Just look at how complex the package management systems and package hierarchies of a major Linux distribution are.
BTW, I'm running Office 97 on WS2003 without issue as a limited user. Back in the day with the likes of NT3.51 and NT4.0, Office 97 was one of the best multiuser apps, even including special user workgrouping functions. I don't see why Vista would be any different.
Also, Vista requires you to jump through hoops to install unsigned kernel drivers, particularly in the x64 version. Prior to Vista, administrators had the authority to install whatever drivers without having to set any special (and potentially reduced functionality) modes.
It's true that there have been implementation flaws leading to vulnerabilities and the prorogation of worms. These were not caused by the actions of ISVs. Windows is not alone in having implementation flaws. However, implementation and design are two different things, and the topic of this story is UAC, Windows security design, and software that doesn't run with standard user privileges, which IS the fault of whomever wrote the software.
NT has always had local security. The Guest account, disabled by default, has even less privileges than members of the Users group. How would it be helpful for a full user to compromise that? NT 3.51 SP3 attained the Orange book C2 certification, which measures local security design. That wouldn't be possible if "any non-admin user could do anything to the system after login."
- An estimated 654,965 additional people died in Iraq between March 2003 and July 2006.
- A majority of the additional deaths (91.8 percent) were caused by violence.
- The proportion of deaths attributed to coalition forces diminished in 2006 to 26 percent.
- Between March 2003 and July 2006, households attributed 31 percent of deaths to the coalition.
It's true that not all of the civilian deaths in Iraq can be directly attributed to coalition forces. Still, 26% of 63k is still 16k, a lot of dead people. Furthermore, the sectarian violence reponsible for so many deaths in Iraq between the Sunnis and Shiahs was definitely foreseeable as a consequence of invading the country. That puts part of the responsibility for those deaths on the invading force, too. Saddam at least had that violence under control.Right now, our part is in setting into motion these events by choosing "invade" as the best option. That makes us partially (not totally) responsible for its effects. The way it's supposed to work is for the expected benefits to outweigh the costs that we'd be responsible for. I don't think it's working out that way.
If you want to go back further in time, wasn't it the US government that put Saddam in power, and gave him those evil weapons of mass destruction? Isn't the US govt. (at least partially) responsible for the people it puts into power?
Yeah, there's plenty of blame to go around. It's easy to lay it all on "them". Unfortunately, things aren't that simple or clean. Warring never is. Is it all worth it in this case?
It's true that military action, as ugly as it is, is sometimes the best option: when the benefits outweigh the costs. The costs of Iraq to both the Iraqi and American people has already been enormous, much more so than Bosnia or the others you mentioned. If the invasion and occupation of Iraq is really worth it, where are the benefits; benefits large enough to be worth the costs?
Oh, you don't think that the gang members are in any way responsible for recklessly shooting up the city? They shouldn't be held any more responsible than a good driver involved in a fatal accident? There's a reason that discharging a firearm inside city limits is illegal outside a firing range or special circumstances: firing guns in densely populated areas is known to be recklessly dangerous, and not just to your target. Invading countries is known to be very dangerous for its civilians. In order to have an accidents, there has to be a trade from known, acceptable risks for real benefit. Gang wars have none. Iraq has little at best.
One could hardly call our reasons for invading Iraq peacekeeping.
Still, you're right: killing for the sake of killing people (i.e. the Holocaust) is a little bit worse than killing people for idiotic reasons. One's premeditated murder, one's reckless murder. I shouldn't have lumped them in together so easily.
However, the damage per death caused is exactly the same, regardless of the motives of the killer. Murder is a high crime precisely because the death of a human being is a great loss. The issue becomes more a matter of how many people were killed than why, and the fact is that the US's invasion of Iraq has caused far more civilian deaths than Islamic terrorists have for American civilians plus Saddam's ethnic cleansing of the Kurds. Perhaps more even than all jihad suicide bombers. paranode seemed to be implying the opposite.
Regardless of the motives involved, our (US political) choices have resulted in a lot more dead, and therefore a lot more damage, than They(TM) ever have. With these amounts, why is secondary to how many.
You're right: malicious killing is worse than reckless killing. At least with reckless deaths, it's possible to have a higher goal to be working towards (than death itself). So, what is our high and mighty goal of Iraq anyway? Is it worth 60-600k innocent dead?
A death is an accident only if you're already doing (or not doing) what is reasonable to prevent casualties, leaving only a calculated, acceptable risk in exchange for some benefit. The invasion of Iraq itself is a big step in the wrong direction to be calling the deaths there from the invasion+occupation accidents.
These deaths were certainly foreseeable before the invasion started. Is malicious killing really so much worse than grossly wasteful killing? In the US legal system, second degree murder includes both intentional (but not premeditated) and reckless killing.
You're right, Iraq could be one level worse. There's a difference, but not a big one.
Oh yeah, because everyone knows there are no civilian casualties in Iraq from US military actions. Civilian casualties are civilian casualties, be it from terrorism, military invasion, ethnic cleansing, whatever. The innocent are just as dead.
The forum was opened with the express purpose of getting feedback on pre-release versions of Vista. The topic categories range from "Windows User Experience", where the bulk of the posts are, including complaints that were definitely relevant to the Windows Experience (TM), "Windows Developers", the website itself, and misc.
I wasn't an official beta tester, either. I'm sure they had an official feedback method, and IDK if it was given more credence. Still, the Shell: Revealed forums were certainly an appropriate and official place to voice concerns.
You did say that the reason that "[Attacks on Windows] succeed so frequently because the security architecture of Windows is so poor." The only technical detail mentioned in the post was "A simple application like the IE web browser is tightly integrated into the operating system..." being a dumb idea. A link between them seemed to be implied.
If not that, then what exactly is so insecure about Windows's security architecture? I submit that the security design is more than adequate for a multi-user OS.
Just to get them out of the way, Windows certainly has a bad default of making the initial user an Administrator by default, and it's had its share of implementation flaws (same as most software). But these things aren't architectural flaws.
Microsoft tried that late in Vista development at the Shell: Revealed forums. We voiced many concerns, only a few of which got any attention, much of it hand-waving. No one from MS has posted there in a while now, so users have stopped too. A post about the new backup program, sdclt.exe and how much functionality it lacks compared to the old one, ntbackup.exe, was even deleted.
Someone at Microsoft thought it would be a good idea to get some public feedback on Vista development. Late, but good. But then, they didn't listen to our feedback. Some of the stuff we brought up should have been pretty easy to fix, but was blown off instead.
IE consists of a front-end launcher and a few shared libraries that implement parts of the back-end like an HTML renderer. The only thing that the IE back-end is integrated with is parts of shell environment. It's a few shared libraries that are loaded into iexplore.exe, and explorer.exe when it needs to do HTML rendering. OSX has a similar architecture, called WebKit. KDE also shares Konqueror's back-end.
IE is just a few user mode shared libraries. It doesn't have hooks into the kernel. It runs with whatever privileges the user has; it doesn't have some magical security back door. It's not used by any system services. A vulnerability in IE can lead to the compromise of the process it is loaded into, but that's true of any library. IE's vulnerability record is awful, but it can only compromise the system as much as any of your other applications. If IE was a totally standalone program, its security track record would be exactly the same; it's (in)ability to compromise the machine exactly the same. If you run an app as admin, and its compromised, the entire machine is compromised. If you run an app as a normal user, and its compromised, only the user's account is compromised. IE has nothing to do with the security architecture of Windows.
In court, Microsoft said that IE was an integral part of the Windows experience, and that removing it would diminish that experience and break their right to sell a software package with whatever features they liked.
While I was in grade school, I was constantly told (especially by my parents) that school is the absolute top priority. Bar none. A program that eats all my time with steaming piles of busywork (to be completed 'because we said so') popularity contests (not that I cared much), with heaping sides of patronization and hypocrisy. Of course, learning was the official reason, but that always came off as hollow. They didn't didn't have the awareness or guts or something to be honest about what was really going on, and what the priorities really were.
I think you're absolutely right about people not taking education seriously. Teachers don't take it seriously; half of them just want something to keep the kids occupied, safe in making all of them suffer equally under BS assignments. Most people only care about how they're doing in comparison to their peers, so it's OK as long as everyone has to do it. I had more absolute standards. Referrals are useful to make kids that aren't compliant enough someone else's problem. At the peak, I received one a week, like clockwork, in 5th grade for noncompliance (they called it not being respectful and responsible to myself and others: the ambiguous catch-all rule). Most parents and teachers have no respect for kids, therefore the kids tend to not respect teachers, parents and one another. I did have a few teachers that were actually good, but they were the exception, not the rule. They also couldn't fix the system itself.
I was disruptive because I was bored, because I couldn't bring myself to work on endless pointless assignments, and because nobody was honest with me, knowing that official explanations (read:excuses) didn't add up. I preferred being disruptive to putting up with it. As it went on and on, I became numb and cynical. Maybe I lacked the maturity to see the big picture-- to put up with it, prepared to be different in the real world. Still, the only thing I would change is to use more intellectual forms of disruption, instead of just trying to escape it all. Maybe they would have listened more. Maybe not... and that's depressing.
As for bullies, by the time that was an issue, I was too numb to care what the other kids thought. Without the fear that most bullies thrive on, I was usually passed over. In middle school, one bully became a casual friend, and another caused more problems for me via the school admin. over a fight we had than he did personally. By high school, I wasn't even a target. I'm not sure know how the other kids fared in the same school. OTOH, I have problems making friends; connecting with people more than casually.
OpenGL was supported since around NT 3.51 (long before full Direct3d on NT). For games that used OpenGL + MCI for sound, NT was a fine platform for gaming. For example, the original Unreal runs great on NT 3.51.
I can think of a few things: the old backup program, ntbackup.exe, is no longer included. The replacement, sdclt.exe (Vista Backup) is a joke. You can't even select the files you want to backup, or put the output in a file of your choosing. It doesn't backup registry hives correctly and doesn't use volume shadow copies (both of which ntbakcup does). The ntbackup for XP or 2003 is incompatible with Vista.
.HLP files is broken. Some parts of the OS still use .HLP files for documentation (like the What's This? for the offline files share control page), so those links are broken now.
Winhlp32.exe is no longer included (the file called winhlp32.exe is a stub that pops an error message telling you that a functional winhlp32 is no longer shipped), although for some reason its Win16 counterpart, winhelp.exe, is. Any program that uses
There are fixed promised, but OpenGL is still broken, or very slow with most video drivers.
The new sound system does not support any kind of hardware acceleration or features. Companies like Creative are scrambling to get game developers to adopt OpenAL with an end-run around the Vista sound system so that users aren't left with $300 sound cards equivalent to an AC'97. This does nothing for older games that depended on DirectSound for this.
Here's a list of more things.
My point is that user access control has always been implemented in the NT line of Windows. The new features are for convenience, to make it easier to safely run low and high privilege processes side by side, for executables to tag what mode they should be run in, and a more automated interface. The back-end of UAC, the ability to run processes with different privilege levels even if based on the same user account, has always been present. The interface to it hasn't always been so great, but that's been fixed since 2000. You don't need pretty elevation dialogs or low and high privilege windows side by side-- you can use separate logons for that purpose, something that's always been supported.
I agree completely. Unfortunately, there's no magic technological way for users who are willing to install anything and follow arbitrary instructions in the name of watching a funny video to have a secure system, short of a TCPA enforced whitelist of approved applications. User expectations in this regard are unreasonable. One must understand the system to use it properly and safely.
That said, I agree that UAC isn't implemented well. It'll just program users to click OK even more often then they already do, assuming that they don't just turn it off. There must be a better way of implementing it than Microsoft chose.
MS has always recommended that people follow proper multiuser security design. The "Designed for Windows NT" logo program has existed ever since the first release, IIRC. App developers have abused various parts of the OS in all kinds of gross and weird ways, and I can't think of any part of the docs or toolset that would encourage that kind of abuse, except perhaps that MS seems to have made a mistake in trusting the ISVs to be competent and to care about little things (like security). I've got an old .HLP describing the Win32 API circa 1995, and it's filled with information about the difference between user and machine resources, user and admin privileges, and securing objects. Unfortunately, it's safe to ignore the lot when programming for Win95 (safe in the sense that the programs will run on 95 but not NT), so that's what most ISVs have learned to do. It's easier.
The only reason that XP (and more importantly, most OEMs that preinstall XP) default to giving the user an admin account is for compatibility with all the 9x apps that don't follow the most basic tenants of multiuser programming. Microsoft (and the OEMs that went along with it) must have feared some kind of backlash from giving users standard accounts. Why else would they have done it?
From CVE-2007-0843
The ReadDirectoryChangesW API function on Microsoft Windows 2000, XP, 2003, and Vista does not check permissions for child objects, which allows local users to bypass permissions by opening a directory with LIST (READ) access and using ReadDirectoryChangesW to monitor changes of files that do not have LIST permissions, which can be leveraged to determine filenames, access times, and other sensitive information.
This is by design, and it's been known about for a long time. Directory data belongs to the directory, not to the child files. Directory data includes a few pieces of metadata about files, including timestamps. Files do not have a list permission; the permission bit used for list children with a directory is the
If you're referring to protected mode IE, it's implemented with restricted tokens and a mandatory integrity label, not an ACL. Both mechanisms are available to 3rd party developers since they were introduced (in 2000 and Vista, respectively). They were not dangling parts of the security model prior to their introduction. They are not necessary parts to a working multiuser security model. What necessary (to be useful and secure) parts of the NT security model are unimplemented or missing? How about in NT 3.1? Surely you can come up with more examples to the claim that "most of it is not implemented at all in any version of Windows" (emphasis mine).
Actually, it was more because the 9x series had no security and very weak multi-user capabilities that sloppy programming in those regards just worked on the much more popular 9xes and gained momentum. At the time, almost all ISVs couldn't care less if the software ran properly on NT, let alone with LUA. The people who actually used NT at the time understood and used LUA. They just didn't have enough clout to insist on better quality software for the platform, unlike the Linux and OSX communities. The popular related OSes were the 9xes with no security, and users that didn't care. For that matter, most ISVs and users still don't care.
I'm not aware of this issue, but if it's true, then you're absolutely right that Microsoft isn't following their own rules.
Still, I'm not aware of anything, aside from momentum in bad practices by ISVs, that makes writing software that correctly follows the standards of LUA and multiple users any harder on Windows than any other platform. Windows has about as much good software (that follows the OS design properly) as any other platform (most cross-platform apps fall into this category), but Windows also has a LOT more crappy software, which drags the average down.
Yeah, the app can ask the user for his password. If the user is, as I said before, giving the malware full consent, he will have no compunction sudoing the malware to root with a password prompt dialog. On my machine, I'd specifically have to select the malware for Run As... and select an admin user, with password. Is there some other hurdle I'm missing?
Ok, what's the one right now then? There have been some in the past, but not more than other desktop OSes AFAIK. Certainly not a state of constant publicly known vulnerability. Also, of the malware I've tested in a VM, not one has even attempted to escalate locally (or succeeded). They all assumed they would be run as an admin, and failed in strange ways when they were not.
It's true that Microsoft is in a unique position not to care,
What's not implemented, specifically? Although I agree that the interfaces to many security features are substandard.
Windows NT 3.1, released in 1993, had full separation of user privileges. There were three classes of users by default (Administrators, Users and Guests), and new classes could be created with delegated rights and privileges. Tools that aren't specifically for administration have always been required to work properly with standard user privileges to obtain the "Designed for Windows NT" (or 2000 or XP...) logo. Microsoft can't force ISVs to write software that works properly with the security system, but Microsoft has been urging them to do so since the beginning. Microsoft's own software has been pretty good about following those requirements (except for the games department.) I remember specifically running Office 97 on Windows NT 3.51 as a limited user without issue.
It's always been possible to install stand-alone applications to a directory. Standard convention suggests you share common libraries with other programs that may use them, but they can always be put in the application's own directory instead. Since Windows 2000, the only supported method of installation is the Windows Installer, which indeed supports installation as a limited user for programs that support it (not many, I'm afraid).
Is that because there is precious little malware developed specifically for OSX? If an administrative user were to give consent to installing a piece of malware on OSX, what technical barriers would prevent it from having free reign on the machine that don't exist on Windows? If it's in, it's in, be it root access on a unix or Administrators on Windows. (Yes, I know that an OSX admin != root, but an admin can certainly sudo malware to root, given the user's consent.) On Windows, I can try installing anything I want without admin access and not worry about infecting the machine or other user accounts. It's the same on other OSes with user privilege separation.
The virtual registry views and other API hacks like it are called compatibility shims, and there are indeed a lot of them to work around buggy and incorrect application behavior. It's hard to write them, and not all app behaviors can be fixed by a shim (e.g. games that insist on installing a kernel module for copy protection purposes). There is A LOT of software out there, and Microsoft can't (and shouldn't need to) fix it all. Even so, I'm not aware of any OS that goes to the lengths that Windows does in trying to make it all work all the time. If Microsoft makes too big a break, people will simply be instructed by the ISV to
NTVDM really does depend on the CPU being able to run in V86 and DPMI compatible modes. That's why the non x86 versions of NT couldn't run DOS or Win16 apps (but would have been able to if NTVDM was a full emulator, although the Alpha port did have a 486 emulator using unique Alpha features). Ntvdm.exe is a container for a Win16 or DOS environment instance, but it depends on the kernel NtVdmControl function to switch to V86 or 16-bit protected modes and setup traps as needed. Since NT doesn't allow user apps to access hardware as a matter of principle (unlike Win9x), NTVDM does indeed emulate some hardware components by trapping interrupt, IO and DMA requests.
I'm sure that Microsoft could write a full emulator if they really wanted to, ala DosBox, but I think they'd rather the whole thing just went away. When the VDM system was created for NT 3.1, full emulation would have been far too slow. The architecture has not changed since.
See also:
DOS from the ReactOS project
Writing a VDD
VDMSound
NTVDM Compatibility Drivers