Slashdot Mirror

Here are some good tools of their that I use frequently

Autoruns

http://www.sysinternals.com/ntw2k/freeware/autorun s.shtml shows a complete list of programs that start up automatically when windows starts. Filemon

http://www.sysinternals.com/ntw2k/source/filemon.s html Filemon shows all filesystem access, so you can see which files programs are accessing. I have found it very useful in diagnosing software problems and fighting spyware. Regmon

http://www.sysinternals.com/ntw2k/source/regmon.sh tml Like filemon, but for registry access. Shows keys being read and created. Pagedefrag

http://www.sysinternals.com/ntw2k/freeware/pagedef rag.shtml Defrags the registry hive (most of the registry is stored on disk but is not typically defragmented by many tools) and paging file. Also many others here

http://www.sysinternals.com/ntw2k/utilities.shtml

IMHO any windows admin should have this stuff installed. Many of the utils come with source code.

Here are some good tools of their that I use frequently

Autoruns

http://www.sysinternals.com/ntw2k/freeware/autorun s.shtml shows a complete list of programs that start up automatically when windows starts. Filemon

http://www.sysinternals.com/ntw2k/source/filemon.s html Filemon shows all filesystem access, so you can see which files programs are accessing. I have found it very useful in diagnosing software problems and fighting spyware. Regmon

http://www.sysinternals.com/ntw2k/source/regmon.sh tml Like filemon, but for registry access. Shows keys being read and created. Pagedefrag

http://www.sysinternals.com/ntw2k/freeware/pagedef rag.shtml Defrags the registry hive (most of the registry is stored on disk but is not typically defragmented by many tools) and paging file. Also many others here

http://www.sysinternals.com/ntw2k/utilities.shtml

IMHO any windows admin should have this stuff installed. Many of the utils come with source code.

Mark Russinovich and Bryce Cogswell have been providing invaluable tools for years. Even if Microsoft released a rootkit detection package tomorrow, I would still use sysinternal's over anything Microsoft provides because "there is no anonymous team of programmers or writers behind Sysinternals". They put their name on everything they give away and sell.

When it comes to trust, people put their names on things they know are trustworthy. I can't count the number of times I've felt betrayed by Microsoft's products not doing what they're supposed to do, only to discover a flaw in their product that they knew about but didn't tell so as not to affect sales. I also can't count the number of times utilities such as NTFS for DOS have saved my butt in the field.

Way to go Sysinternals.

Mark Russinovich and Bryce Cogswell have been providing invaluable tools for years. Even if Microsoft released a rootkit detection package tomorrow, I would still use sysinternal's over anything Microsoft provides because "there is no anonymous team of programmers or writers behind Sysinternals". They put their name on everything they give away and sell.

When it comes to trust, people put their names on things they know are trustworthy. I can't count the number of times I've felt betrayed by Microsoft's products not doing what they're supposed to do, only to discover a flaw in their product that they knew about but didn't tell so as not to affect sales. I also can't count the number of times utilities such as NTFS for DOS have saved my butt in the field.

Way to go Sysinternals.

No really, they have class utilities for free, thanks Sysinternals

In cases like this the SysInternals tool Process Explorer is massively handy -- it's taskman but much, much better, and has the ability to both display the process list heirarchally and list the actual commandline call, so it's easy to spot something dodgy. Combine that with TCPView, which shows all listening &/or open TCP ports, and you'll be able to find all but the proper rootkits.

Speaking of taskman clones, SpyBot actually has one built-in in the Tools section, though you have to be in "Advanced Mode": click on the header of the Tools list in the left-hand pane, then tick the checkbox next to the "Process List" icon in the right-hand pane (and tick some of the others, too, e.g. BHO's & ActiveX) and these items will now appear in the l-h pane - check them out, they're basic but very useful :) (It's a shame Spybot's UI's a bit wierd, I know plenty of people who didn't know these features were there!)

If you're more of a commandline person, the PSTools suite a little better - pslist will give you the process list, then pskill processname will despatch it (if it's really cheeky it'll respawn itself), and there are a few other useful ones there, too. XP actually has very similar commandline tools to the above, but that's no help if you're on 2000!

In cases like this the SysInternals tool Process Explorer is massively handy -- it's taskman but much, much better, and has the ability to both display the process list heirarchally and list the actual commandline call, so it's easy to spot something dodgy. Combine that with TCPView, which shows all listening &/or open TCP ports, and you'll be able to find all but the proper rootkits.

Speaking of taskman clones, SpyBot actually has one built-in in the Tools section, though you have to be in "Advanced Mode": click on the header of the Tools list in the left-hand pane, then tick the checkbox next to the "Process List" icon in the right-hand pane (and tick some of the others, too, e.g. BHO's & ActiveX) and these items will now appear in the l-h pane - check them out, they're basic but very useful :) (It's a shame Spybot's UI's a bit wierd, I know plenty of people who didn't know these features were there!)

If you're more of a commandline person, the PSTools suite a little better - pslist will give you the process list, then pskill processname will despatch it (if it's really cheeky it'll respawn itself), and there are a few other useful ones there, too. XP actually has very similar commandline tools to the above, but that's no help if you're on 2000!

In cases like this the SysInternals tool Process Explorer is massively handy -- it's taskman but much, much better, and has the ability to both display the process list heirarchally and list the actual commandline call, so it's easy to spot something dodgy. Combine that with TCPView, which shows all listening &/or open TCP ports, and you'll be able to find all but the proper rootkits.

Speaking of taskman clones, SpyBot actually has one built-in in the Tools section, though you have to be in "Advanced Mode": click on the header of the Tools list in the left-hand pane, then tick the checkbox next to the "Process List" icon in the right-hand pane (and tick some of the others, too, e.g. BHO's & ActiveX) and these items will now appear in the l-h pane - check them out, they're basic but very useful :) (It's a shame Spybot's UI's a bit wierd, I know plenty of people who didn't know these features were there!)

If you're more of a commandline person, the PSTools suite a little better - pslist will give you the process list, then pskill processname will despatch it (if it's really cheeky it'll respawn itself), and there are a few other useful ones there, too. XP actually has very similar commandline tools to the above, but that's no help if you're on 2000!

One of the computers I support had a very nasty piece of spyware. I am not sure if it was exploiting the same things described by Microsoft, but it had the following symptoms:
1. The process would not show up in task manager
2. The related files would not show up in Explorer
3. The related registry keys did not show up in regedit
4. It some how was being called by Winlogin, so it ran even in safe mode.

The way I detected it was by using several Sysinternals utilities http://www.sysinternals.com/. I have a script that uses pslist to monitor all processes on the network and this spyware was not smart enough to hide from that. A remote regedit session enabled you to see the related registry files. I had to use BartPE http://www.nu2.nu/pebuilder/ to mount the drive and clean out the related files and registry keys.

Actually. It is funny to see everyone claiming that IE is loaded at boot and this is why it loads so quickly.

But my boot process only takes a few seconds, so IE still loads faster than Mozilla or FireFox considering the whole OS is loaded at boot.

For facts, what part of IE is integrated into the OS? Or is it that IE uses integrated features (like mshtml.dll)?

Just because these DLLs exist it doesn't mean they are all loaded or integrated in the OS kernel. You can use any process explorer to verify what is loaded or not.

At least I can't see that Windows Explorer is loading mshtml.dll unless I choose to display a folder as a webpage.

And unless you are running a version of Apache from 1984 (or a version for AIX on windows), it never required cygwin... NEVER! In which case it begs the question: what the hell kind of comparison are you trying to make by comparing a recent version of IIS to a version of Apache thats 10 years old?!!

If it's that simple then why doesn't everyone do it? Hmmm? Why aren't all programs optimized for that and enabled to run at a command line? You'd think everyone would want this right? Faster apps, better functionality.

Apache doesn't need cygwin. Who the hell told you that? I run an install just fine without CYGWIN; you only need CYGWIN to use system calls. If you don't use them or find an alternate method or approach (which there are several), you don't need cygwin at all. :)

And Apache does not need 100 processes. I swear you Microsofties have some sweet crack over there that you guys are smoking to keep spitting out all this bullshit.

Regardless, it's still faster and more stable on Windows than IIS anyday :)

And just to make an additional point about memory availability.... do that control-alt-del again and take a look at physical memory and kernel memory, and look at total, available, paged, etc. Notice that the numbers are alot smaller than they should be? Go ahead. Take some time to do the math, I'll wait.

You can't shut down the Windows in Windows my friend.

PsExec can start a new process as admin with the password on the command line.
SU/SUD is a more flexible program, including a setuid equivalent function.
Also, SFU can launch Win32 processes as different users with su and can also do setuid.

You know, it's already there, most of what you ask for. It's just that there aren't that much programs written for the Windows NT Native API.

http://www.sysinternals.com/ntw2k/info/ntdll.shtml

with the IE api hooks into the kernel

That's why SFU isn't built on top of Win32, but the kernel's native API, which does fork() just fine. So does SFU; it uses the native API.
The NT kernel was designed from the beginning to support different environments, including POSIX and Win32. Each environment subsystem consists of a server process that maintains common state specific to the environment, and a set of client libraries that translate the environment's API to the native API and calls to the server. Win32 is an environment subsystem and so is SFU.

For some reason, cygwin (which debian-win32 uses) insists on using only Win32, so they have to resort to kludges to make certain things like fork() work.
Now that SFU is free, I don't see why debian-win32 couldn't use that instead of cygwin.

As it stands, Interop Systems has the best collection of packages for SFU. Most of the essential stuff is there, but it's still a far cry from Debian's library.

You can't just give yourself local administrator privilege to install and then take it away
"Run as..." can be accessed using an alternate click to impersonate any user when running any application. I have it on by default, so I can't tell which key combo; it's probably SHIFT + Right Click. Granted, some applications won't run because they think they're admin all the time and can do whatever they want, since they were installed as such. This is again an application issue.

so if you have an xp machine with more than one user, you choice is to not let those users use basic applications like Palm Desktop (it's a documented requirement, so it's 'not a bug' [yeah, right]) and cd/dvd burning software, or give everyone local administrator privilege -- which rather defeats the purpose of having a local administrator privilege
A solution is to find out which files your application requires access to and provide file-by-file access to users who need to run the program. You would do this for data files as well, so I don't see how this is any different. The complexity comes in when figuring out which files to "unlock". using a tool like filemon from http://www.sysinternals.com/ can help in that regard.
Nero as another example provides a tool to allow users without administrative privileges access to the DVD Burner. Their application is the problem, so they provided the solution. It's not up to MS to do this for them.

local administrators can delete or modify any locally stored file

You could theoretically make an account group with administrative-style privileges, and be able to lock this entire group out from folders. In my case, I have a laptop connected to a corporate LAN. noone logged in from that lan (including network admins!) can access primary shares on my drive. However, I've given read-only access to non-network systems so I can get stuff I need from any test computer (which are never logged on to the network).

In summary, you should think again about being admin yourself, since you don't understand the basic principles of administration. These same techniques (with variations of course) equally apply to any other OS. Unfortunately MS makes it look like it's easier than it really is.

Cite please?

Do you really mean what you are saying? I've looked through all the Native APIs listed at http://www.sysinternals.com/ntw2k/info/ntdll.shtml and I can't seem to find any mention of Internet Explorer.

1. The Object Manager provides a single tree for all named objects, including files. Win32 has its own directory in the OM of symbolic links that connect the DOS compatible drive letters to the actual devices. For files, Win32 just sticks \DosDevices\ on the front of the path before handing it to the native (syscall) api. \DosDevices\C: is commonly a symlink to \Device\HarddiskVolume1, equivalent to /dev/hda1.
2. The OM can be extended by any kernel mode component by adding a new object type. One thing that an object type can do is be reparsable; extending the namespace into an object as if it were a directory. One of the object types that the IO Manager exports are device objects. Device objects are reparsable and are used to extend the root namespace into filesystems that will return file objects.
3. Everything in UNIX that is a file is also a file object in NT, and many more kinds of things are also objects. Browsing through \Device with winobj I see a beep device, null, my cdrom, the gameport, my harddisk partitions, the keyboard, sysaudio, the video device, several protocols (IP, TCP, UDP, NwLnkIpx, NwLnkSpx), the named pipe filesystem (npfs.sys), the mailslot filesystem (msfs.sys), NFS and SMB server and client devices, and tons of other stuff. Each of these are device objects that produce file objects for client processes; objects under the IO Manager's domain. You can use the same read, write and ioctl functions on all of them. Some, like TCP rely heavily on ioctls but you can still use read and write on a socket handle (which is really a file open under \Device\TCP)
4. Win32 does not support fork directly (and neither do many popular shared Win32 libaries), but NT itself has no problems with any of those functions. Environment subsystems like SFU use the same syscall interface that Win32 does to make processes and such.
5. I don't think that this is really a requirement of UNIX. Yes, it should provide compatibility as needed for the old style permissions but there are UNIXes that use ACLs internally.

1. The Object Manager provides a single tree for all named objects, including files. Win32 has its own directory in the OM of symbolic links that connect the DOS compatible drive letters to the actual devices. For files, Win32 just sticks \DosDevices\ on the front of the path before handing it to the native (syscall) api. \DosDevices\C: is commonly a symlink to \Device\HarddiskVolume1, equivalent to /dev/hda1.
2. The OM can be extended by any kernel mode component by adding a new object type. One thing that an object type can do is be reparsable; extending the namespace into an object as if it were a directory. One of the object types that the IO Manager exports are device objects. Device objects are reparsable and are used to extend the root namespace into filesystems that will return file objects.
3. Everything in UNIX that is a file is also a file object in NT, and many more kinds of things are also objects. Browsing through \Device with winobj I see a beep device, null, my cdrom, the gameport, my harddisk partitions, the keyboard, sysaudio, the video device, several protocols (IP, TCP, UDP, NwLnkIpx, NwLnkSpx), the named pipe filesystem (npfs.sys), the mailslot filesystem (msfs.sys), NFS and SMB server and client devices, and tons of other stuff. Each of these are device objects that produce file objects for client processes; objects under the IO Manager's domain. You can use the same read, write and ioctl functions on all of them. Some, like TCP rely heavily on ioctls but you can still use read and write on a socket handle (which is really a file open under \Device\TCP)
4. Win32 does not support fork directly (and neither do many popular shared Win32 libaries), but NT itself has no problems with any of those functions. Environment subsystems like SFU use the same syscall interface that Win32 does to make processes and such.
5. I don't think that this is really a requirement of UNIX. Yes, it should provide compatibility as needed for the old style permissions but there are UNIXes that use ACLs internally.

Have you looked at Process Explorer? It's a task manager type progam that provides tons of extra information: for each process you can see its parent, the startup options, a list of every kernel handle it has open, every library it has loaded, a cpu and memory usage graph, a list of threads with stack and status for each, what services (if any) are running inside it (for the svchosts mainly), what sockets are open, environment variable information, image strings and more. Lots of other tools at sysinternals.com too.

I use psexec (and the other excellent pstools) a lot and this question has come up before - Sysinternals give away the source, and they would be wonderful to have on Linux, but I've yet to see them ported.

Ah, but that's the nice thing about Windows, you don't even have to install a telnet server (or some other remote execution server) to be able to run processes remotely -- have a look at psexec. Extremely handy.

If you trust the software, just grant the Users group extra permissions & file a bug report for what you had to do. In environments where I trust the users, I am lazy & grant users the same permission for the apparently relevant files and directories as the accounts that can run the software. On some occasions, this includes changing permissions of dlls outside of the installation directory. I use listdlls to do this. In less trusted environments, I will gradually add read+execute access for the users to the programs & dlls users need. If I get sick of trying to fix it, I usually reevaluate the need to install the program or the level of trust to grant the users.

Underneath the Win32 API is the NT Native API. NtCreateProcess can be called with the SectionHandle parameter set to NULL which produces a new process with the same address space as the ParentProcess handle, mapped copy-on-write just like fork. CreateProcess from win32 calls this function to create a new process but does not expose all of the functionaility.
SFU and the POSIX subsystem have to use NtCreateProcess too, but take advantage of SectionHandle=NULL.

Cygwin uses copy-on-create to simulate copy-on-write by copying the entire address space to the child. This is slow and wastes memory. The cygwin mailing lists have had endless arguments on why they don't take advantage of NtCreateProcess. Here's a small thread.
Also, there is the problem that Win32 does a lot more than just call NtCreateProcess: the native function creates a new process but nothing else. It allocates no memory, creates no threads, and loads no libraries. When you call CreateProcess from Win32, it does all that for you. Since Cygwin implements Posix (and related) over Win32, not Posix over NT (as opposed to SFU which is over NT), they feel compelled to use only Win32 functions.
It would be nice to have a cygwin fork that creates its own subsystem, an open-source SFU, that would take advantage of this kind of thing.

Depending on fork to provide stability is a workaround for the real problem: the app crashing.
Besides, if your data areas are well defined, you can put them in shared memory sections and have the children map that copy-on-write at the same addresses.

top - pslist
ptree - pslist
w - psloggedon
ls -al - dir /adhs, fsutil (both standard)
finger - finger (standard)
unzip - expand (standard, for CABs), cygwin unzip, rar
mount - (automatic), fsutil, linkd (from resource kit)
make - make (comes with SDK)
grep - find (standard)
piping with | > < are the same
perl
cygwin for other UNIX processing utils.

top - pslist
ptree - pslist
w - psloggedon
ls -al - dir /adhs, fsutil (both standard)
finger - finger (standard)
unzip - expand (standard, for CABs), cygwin unzip, rar
mount - (automatic), fsutil, linkd (from resource kit)
make - make (comes with SDK)
grep - find (standard)
piping with | > < are the same
perl
cygwin for other UNIX processing utils.

top - pslist
ptree - pslist
w - psloggedon
ls -al - dir /adhs, fsutil (both standard)
finger - finger (standard)
unzip - expand (standard, for CABs), cygwin unzip, rar
mount - (automatic), fsutil, linkd (from resource kit)
make - make (comes with SDK)
grep - find (standard)
piping with | > < are the same
perl
cygwin for other UNIX processing utils.

Does anyone else use procxp from Sysinternals? It's the most needed thing to help you weed out file handle ghosts so that you don't have to reboot your whole system to delete a darn file... oh yes, sysinternals does offer pretty nifty stuff.

Back when I was using windows (errr... about a year ago? I don't remember) I found the utilities written by Sysinternals very handy. They're probably not of use to everyone, but there were a few times when they were invaluable.
-ReK

For power users, mostly (because they'll confuse your grandma)

• Startup Monitor. Priceless for dealing with crap like Real or Quicktime that always want to setup stubs to run at boot. The popup warning is pretty non-descriptive, though.
• Startup Control Panel, also from Mike Lin (the Startup Monitor guy). Similar to msconfig's Startup tab, but more powerful.
• Pretty much anything from Sysinternals. And they provide source!

Assuming you are running Win32 (as opposed the Win64), try turning DEP off via boot.ini (look under /noexecute).

But to the OS the file is gone.

Just as MS windows doesn't wipe the free space, but just updates the file allocation table.

The problem with that is you get some spyware like vx2(I think that is the name), that monitors the registry.

Yeah, the inability to delete a filename but leave the underlying inode (like UNIX does) is annoying.

To work around this, the session manager (smss.exe: it's like the init process) provides a nice feature. In the registry key HKLM\System\CurrentControlSet\Control\Session Manager\PendingFileRenameOperations there is a list of files to be moved or deleted the next time the OS starts. The value name is the source file and the value data is the destination. An empty destination means delete. This happens before any other processes are started, before Win32 starts, and even before the pagefile is created.

Sysinternals has a couple of command line tools that can be used with this: movefile which adds new move operations and pendmoves which lists existing ones.
See also the MOVEFILE_DELAY_UNTIL_REBOOT flag of MoveFileEx, which does the same thing from a program.

If you find out where the updates are installing, both in the file system and in the registry you can explicitly allow users access to those registry keys and folders. Then they will be able to isntall files. I find Sysinternals software invaluable for figuring out where software is trying to write.

The NT kernel supports multiple syscall tables. Any kernel mode component can add its own table. Since NT4, Win32 has its own syscall table because it has less overhead than an out of process LPC port to CSRSS (what was used before), but the kernel's native API is seperate.

You may say that this is a trivial difference; that since the Win32 server runs in kernel mode and has a syscall table, it might as well be in the kernel. It wasn't much different before: the Win32 server ran as SYSTEM, the most priviliged account. Although it didn't have it's own syscall table, any app could send messages to it along the LPC port (\Windows\ApiPort). The same functions exported on the LPC port were simply moved to a syscall table. Most of winsrv.dll's functions were moved to win32k.sys. Nothing else in kernel mode, save video drivers, even care about win32k.

autoruns from sysinternals.com is a much better way compared to using regedit by hand.

It shows you ALL the locations where programs are automatically started (there are lots of them!) It shows you the path to the executable, and can show you its properties (filename, description, module name, version, etc. -- all the info fields embedded in the .exe), and lets you remove the entry with a single click.

autoruns from sysinternals.com is a much better way compared to using regedit by hand.

It shows you ALL the locations where programs are automatically started (there are lots of them!) It shows you the path to the executable, and can show you its properties (filename, description, module name, version, etc. -- all the info fields embedded in the .exe), and lets you remove the entry with a single click.

But it also runs in starup... I use tools like msconfig, autoruns, Process Explorer, Security Task Manager, BootVis etc. I know exactly which processes run on my system, so if something new shows up I know it did the bad thing.

But it also runs in starup... I use tools like msconfig, autoruns, Process Explorer, Security Task Manager, BootVis etc. I know exactly which processes run on my system, so if something new shows up I know it did the bad thing.

Try Process Explorer. A property tab lists every service running in a process, among many other things, like every handle and network port opened by a process.

You don't know what any of these programs are sending, or how often they send it.

I did run AdAware and SpyBot once, but they were able to find nothing. And going with the bad analgies, I do lock the safe; it's called running as a normal user. Things like Process Explorer tell me what's inside.

Besides, if the kernel is compromised properly, even a malware detector can't help you. Nothing short of booting from trusted media can.

Yes, there is a tool to tell you what process has is holding a lock on a file - you mentioned it in your article too!

Use process explorer from Sysinternals. (free download)

If you use the "find handle" function, and enter the filename, or partial filename, it will list the processes that have this file opened. The find dll function is similar, but finds all processes that have loaded the specified DLL. Very handy for spyware that lives in a dll and has loaded itself with rundll.exe...

Its an incredibly useful tool. Its one of the first apps I install after a rebuild.

with the IE api hooks into the kernel

But then NTFS is a chore to acess from a "dead" system...

Not in the slightest.

The Run key in the registry is only one of many places that spyware can be installed. To get all of them, use a tool like AutoRuns, from System Internals, which is free and works great (disclaimer: I haven't tried the just-released version 6.0). AutoRuns looks in several places, and allows you to easily disable or re-enable entries. I'm not sure that their disabling works reliably vs. spyware, because spyware will re-enable itself, but it's a start.

Also, sysinternals.com has a pretty decent process explorer.
http://www.sysinternals.com/ntw2k/freeware/procexp .shtml

Technically, in a really literal minded sense, that's correct. Technically, any Win32 component or control can be replaced. In practice, the way that Microsoft has built the system too much depends on the HTML control and Windows Explorer.

For the latter, instead of mounting devices like my Jornada in the file system, they're shown on the desktop but are only there via a plugin for Windows Explorer, so without it I can't browse my Pocket PC.

I can't have a great deal of faith in that design. There's just too much shared state between components of Windows, and too little control over the implementation of security boundaries: every component seems to have its own call gates, with multiple independent implementations of the same security and sanity checks on arguments and objects.

The NT kernel's design has all kinds of wonderful possibilities for building a secure OS around. I really wish Microsoft would do it.

So do I. Maybe Reactos?

The Win32 subsystem, however, is inherently insecure. And without the Win32 subsystem, NT is not a complete OS.

Yes, Win32 IS insecure, to a point. Window station, desktop and job objects are securable objects that NT adds that can be used to partition Win32 into sandboxes. They just aren't used much.

Win32, includes not just the GUI but the equivalent of all the UNIX daemons and system services, and large parts of what in UNIX would be kernel modules. Take that out and you're left with less than the UNIX kernel.

Most built in services are written for the Win32 subsystem since the user mode service control manager's interface is part of win32, but several have only superficial dependencies. The SMB client and server come to mind.

I thought that the NT had more, not less things running in kernel mode. Nothing in kernel mode depends on win32, ever. The only thing related to win32 that runs in kernel mode is win32k.sys, the server part of win32. Nothing in the kernel depends on win32, or can even use win32. Moving win32 into kernel mode didn't change that.

What, specifically, in Windows is implemented as a user-mode win32 dependent service that would normally be a kernel module in UNIX?

Also, there is no such thing as THE UNIX kernel. There are UNIX kernels such as Linux or OpenBSD's kernel, but no one 'true' UNIX kernel.
Compared to Linux, the NT kernel and executive services (ntoskrnl.exe) do a couple of things that Linux doesn't: the Configuration Manager AKA the Registry; a database for configuration info, the extensible Object Manager (althought the VFS comes close), and a dedicated local proceduce call facility (you can use pipes under either, but only NT has LPC) If you include all the modules that run in kernel mode (besides win32), there is more: SMB: the client is in mrxsmb.sys and the server is in srv.sys, MUP (mup.sys), CD burning support (as a filesystem), audio processing, the mailslot filesystem (msfs.sys), the named pipe filesystem (npfs.sys), plus all the things you'd expect: filesystems, bus drivers, USB drivers, and network stuff.

If you were logged on to an NT workstation as a normal user, first of all, you're more likely to be infected by a virus in the first place because the design of the Win32 subsystem practically invites them in.

Invites? How's that?

Secondly, there's a lot more opportunities for an application to boost security to Administrator or even LOCALSYSTEM: not only is the security model very complex, but you have to have all the rights any application you run is ever going to need.

NT isn't any more vulnerable to privilege escilation than UNIX is. Just because the security model is complex, doesn't mean it is broken. It may be harder to use, but it also provides much granularity (if you use it). For the last part, I don't understand what you are trying to say; how is this different from any other security model? Define a user's permissions so that they can do everything they need to. ACLs can be changed, but you should be able to set them up once.

To top it all off, there's no hard "system call" interface between different security domains.

Sure there is. It's called the Native API. The only way to request services of the kernel is through the system call interrupt, and all those functions are exported by ntdll.dll. Win32k adds an extra function table, though; it exports the services that used to be in us