NT itself has no problems with a normal copy on write fork; a call to NtCreateProcess with the SectionHandle argument set to 0 will cause the new process to inherit its address space from InheritFromProcessHandle, and you can specify copy on write access. The POSIX (or SFU) subsystem has no problems doing a real fork.
I guess the closest you can get using only Win32, is to make all the memory you want inherited in shared sections and have the child map it copy on write at the same addresses. This requires a different style of creating children, but will work just as well; not bad, just different. I think that Cygwin does something similar, although it doesn't set good security on the sections.
If a COW fork() is just a normal fork, what's a COC fork()? clone() perhaps?
(unless you're dealing with a platform like Windows where the process model simply isn't flexible enough to avoid throwing memory protection out the window).
I know that creating a process is considerably more expensive than creating a thread in Windows NT (mostly because you have to wait for the Win32 server; non-Win32 processes are much faster), but I wasn't aware of any limitations that prevent proper memory protection. New processes get their own address space. Shared memory is accomplished with sections, which can be mapped read only.
True, NT does favor threads vs processes as they are much lighter, but even more than that, NT favors a very small amount of threads running as asynchronous workers. NT inherited the heavily asynch IO model from VMS.
On NT, instead of creating 64* threads (or whatever the maximum number of concurrent clients will be, possibly hundreds) where one thread waits on each connected client, it would be better to create about 1 thread per CPU and have them take work items off of a completion port. Instead of blocking on IO, always do it asynchronously and have the result posted as another work item. Both files and sockets can be connected to completion ports. Always have a pending read on open sockets so when a packet is recieved, the OS posts a work item. Client wants dynamic content but you have to read something first? Start the read now and immediately go back to waiting for another work item in case you could be doing something else in the meantime. When it completes, the OS will post it and you can finish the operation: do the necessary processing, start an asynch write of the result to the socket and go back to waiting for more work. Client wants a static file? Start the transfer with TransmitFile (it's like UNIX sendfile) and immediately wait for another work item. The only thing you should be blocking on are locks to synchronize multiple threads. Never IO.
On a single processor machine, you might as well only have one worker thread since it should never be blocked except for lack of work: this means that nothing has to be threadsafe. The buggy PHP extensions could live in a happy single-threaded world without sacrificing any performance. Hopefully you can upgrade to better software if your server has multiple CPUs to take advantage of, or use one process per CPU.
* Apache has to have 200 threads if I ever expected that many clients to connect at one time, just in case? Can't they at least be started dynamically? No wonder it doesn't perform well on Windows. I just hope they aren't used round-robin.
I specifically said "bypass OS security" and you bring up this? Office is not a part of the operating system. A vulnerability in Office is not a vulnerability in the OS. Office cannot bypass system security including the execute permission. You've yet to show any exploits that will bypass system file ACLs, which is what you appear to have been referring to in an attempt to refute a execute deny ACL's effectiveness. If that's not what you were talking about, you need to be more clear. The only security settings I mentioned were file ACLs; if you wanted to bring up something else, you should say so. Yeah, I guess you are right; viruses could still spread across e-mail without needing any extra binary files when the client has a vulnerability. Still, preventing users from running arbitrary executables (at least the ones in the IE cache) would be helpful wouldn't it? Regardless, all of these have been patched. 3 years ago. If your patches are up-to-date, these vulns are moot. Vulnerabilities and patches are hardly something Microsoft has a monopoly on.
As for how this would be implemented, it is in the original post you replied to, DUH!
At that point, I wasn't sure what you were talking about.
And your post looks like a good outline to implement security on a Windows network for average users. Just curious, how well is your system working? Do you still have any virus/malware infections? Do you use the default permissions or do you apply a security template, perhaps a custom one? Do you implement a deny-execute ACE for normal users where they have write access? It won't prevent everything by itself, but will provide another layer of security. How do you deal with (poorly designed) apps that require excessive permissions just to run?
Actually, the
first step is preventing it from showing up in the first place.
By "it" do you mean viruses or the admin account or what? How do you propose that prevention be implemented?
That's because there have been previous exploits that bypass the security settings.
What sort of magical exploits are these that can bypass OS security on a patched system?
Are you saying that you haven't implemented this? If you had, the users would be unable to propagate e-mail virus attachments because they would be unable to run any attachments containing them.
Let me guess: every user on your network has local admin access. Not giving them admin is the first step in preventing this crap. If you are worried about users executing attachments directly, deny everyone execute access to the profiles directory ("\Documents and Settings"); stick that in a security template and publish it on the 'Directory. Better yet, deny everyone execute access in every directory they have write access to; surely you don't let them write to program directories? If the workstations were XP, the best solution would be to use Software Restriction Policies to create a whitelist of allowed executables by hash and publish that policy on the domain; if its MD5 isn't on the list, users can't run it. 2000 has something similar in the resource kit.
And then you have to come back every week and clean out the audit logs to avoid filling the drive with them... so there's more time spent babysitting the box...
Audit logs? First, in this situation, auditing probably isn't even needed, except maybe tracking logons. Second, you can control what is audited first by the types of objects and then by what specific objects. If something is generating excessive irrelevant audits, stop auditing it. Third, I doubt the hard drive is going to fill up with logs anytime soon and even if it was going to there are maximum log size settings; you can have the log overwrite itself when it fills up. I think the default is 64k. Fourth, if there is an internet connection, you can do all this remotely with MMC snap-ins or even resort to Remote Desktop or NetMeeting or VNC.
so to run windows securely you have to go in and spend at least an hour setting up auditing, installing new software,
If you have a standard set of things you do after every install, stick it in a script and have it run automatically as part of an unattended installation. Here's a nice page about running third-party installers during Windows setup. Here's a general how-to page about unattended installations. See also slipstreaming. Make registry patches. Customize a user profile and make it the default profile upon which new ones will be based; you can just copy the directory under \Documents and Settings\username. I don't know about you, but when I install any Linux distro, I have to spend at least an hour customizing it and getting it to work the way I want to. I personally don't bother with that stuff because I install once per computer. In the long term, setting it up correctly the first time is a small amount of time well spent.
Yes he should have firefox installed, but that isn't the point either, the point is if MS says their system is for "everyone" then they should make a system that doesn't require knowledge of open source at all, and can still be used for more than 4 minutes on the internet without being hacked.
I agree with you that Microsoft's marketing department makes their products out to be something they aren't. Unfortunately, at least 99% of all marketing by all companies do this (still doesn't make it right). They say that its so easy to use that you don't need to know anything and this is blantently false. Some of the defaults suck, like giving all new users at install time admin by default. Still, just because the marketing department sucks and the OOTB defaults have a few issues, does not mean the entire OS is unusable. Defaults can and should be changed; it's not hard.
How long would it take an unpatched RH9 install with the default packages and the firewall off to be comprimised? That's what putting an unpatched XP box on the 'net is like.
in windows you have to do x, y, z, and then the whole rest of the alphabet again, probably with additional aa, ab, ac steps as well...
Oh come on. How many things is it really? 26 * 2? Is there really anything you couldn't stick on a CD and have a batch file execute after install?
In a multitasking environment, if a process flags a semaphore, and crashes before releasing, how do you get rid of it? You reboot.
First, you shouldn't be using a semaphore in this type of situation; if an owner might die, use a mutex. When the owner of the mutex dies the next wait will return WAIT_ABANDONED. Worst case, destroy the semaphore object by closing all handles to it, possibly by closing all the processes that have it open, i.e. restart the shell. Rebooting is quite excessive as none of the system services open or even care about the shell's objects (including semaphors).
This is the joy of the of embedding your brower as a root level service.
Internet Explorer runs as a part of the shell entirely in the security context of the current user. No part is in the kernel or a system service.
Switching to Firefix has eliminated this frustration for me BTW.
Actually, I'm running Mozilla 1.7.3 to avoid the crap directed at IE and for its other features. More than once I've had it crash, taking all of its windows with it. I think its still more stable than IE though.
And the fact is, since Windows 2000 (even NT4) there has been built in user access control mechanisms for both filesystem and system resources.
All of these control mechanisms have existed since the very first version of WinNT, 3.1 released in 1993. They've had 11 years. Still, NT hasn't been marketed as a consumer OS until XP, only 3 years ago. I guess the only reasons it took this long to make NT the consumer OS is that it had too little compatibility (a lot of DOS stuff broke because it prevents direct hardware access) and the memory usage was too high. NT 3.1 required a minimum of 16MB or even 24 with a few things running while Win3.1 was more like 2MB and 95 a min of 4 (offically) or 8 with the same amount of paging.
I agree with and support everything you are saying.
Because even though it was physically on disk, there is no directory entry for it and nothing to spawn.
True. I wonder if you can spawn a new process based on just the inode... If that is possible and it respanwed itself from a inode file reference, this wouldn't work. It looks like all forms of exec() require a filename. Still, what would prevent the malware from creating a new copy of itself, based on an image of itself loaded into memory when it started, in its death code?
Does Win98/ME have ACL's for the registry?
Nope. In fact, 9x/ME has zero user level security. You either have to be really careful or move to a more secure OS.
This means you would have to deny administrator to those keys wich would probably kill MS Windows during shutdown/startup.
Windows doesn't need or use the Administrator account to start, or even the Administrators group. All of the critical startup processes run as SYSTEM; a token manufactured by the kernel and not from LSA like the others. (Any process with the SE_TCB privilege (or the kernel) can construct a security token with whatever local credentials)
So spyware and viruses are running as local admin.
There is another problem stemming from this: local admins (by default) get the SE_TAKE_OWNERSHIP privilege; this means that malware running as admin could forcefully take ownership of any object it is denied access to and since the owner can set the ACL, give itself full access. That is, if it is programmed to do that. A workaround would be to take this privilege away from the admins group. I guess it shows that once your machine is owned, it may be too late.
I don't know what to do about ignorant/incompetent users either.
But mostly, I hate Microsoft for allowing an app to hide a file from me when I'm running as local administrator.
When the system is infected under the authority of an administrator (or equivalent), it's too late. Every operating system is vulnerable to this. Microsoft isn't doing anything to 'let' applications hide files. Once the operating system itself is infected, the malware is in control and can do whatever it likes.
And why the hell does only RegLite show the file?
Wihtout having About:Blank in front of me, I can only speculate on its behavior, but it sounds like the Windows regedit can see the entry but regedit is apparently monitored by the malware while RegLite, being more obscure, is not.
The file is still there, taking up space, it just doesn't have an entry in that directoy anymore. Once the refcount reaches 0, i.e. no longer listed in any directories and not opened by anything, the space is de-allocated.
Just as MS windows doesn't wipe the free space, but just updates the file allocation table.
UNIX doesn't either; you have to use shred on it to clear the free space. Both OSes prevent you from reading old data from previously deallocated sectors (unless you resort to direct disk access). The OS just makes a write operation of all zeros to newly allocated space, usually cached. It would take forever to delete large files otherwise.
The problem with that is you get some spyware like vx2(I think that is the name), that monitors the registry.
Registry keys have ACLs. Take whatever user the malware process is running as and add a full deny, or at least a deny-write, entry for that user to the FileRenameOperations key. Add the delete ops with a different admin user. This should work unless the kernel is infected, in which case only booting from trusted media will work.
Also you might try if the spyware is monitoring stuff and can restart itself upon death is to suspend instead of kill the process; the death code won't be executed but the process will be just as useless. Process Explorer can suspend processes.
Still, cleaning up an infected system is a poor substitute for preventing infection in the first place. It is entirely possible; I've been able to do it on all of my own computers. The fist step is not running everything as admin all the time.
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.
I got it. I think it made sense, even if it wasn't the most insightful thing ever posted. MadMacSkillz was attempting to polarize the issue: if it's illegal then it's a mortal crime that must be punished, all the while stating untrue facts. You exposed the lies;)
"even if remote users can't see the console GUI, they can still access it". Riiiigggggghhhhhhhttttttt.
Hey, you suggested that "Even if they cannot hear the sound card, they can still access it." How is this any different?
You can just launch the game, move the window and kill the process?
You can stick the window on a non-console desktop and poll the window contents. VNC does the same thing, but doesn't look for desktops that aren't on the console out of the box.
And if telnet and ssh and so forth are not enabled? Well, that means that the machine needs to be rebooted with a recovery disk.
Any OS can be rendered unusable by making it deaf to all inputs. So what?
Actually, it does have a local console. I believe it is accessed via a 5250 connection.
The 5250 is a remote terminal. You can physically place it next to the box, but it's the same kind of terminal that every user uses. There is no special console connection.
Then it isn't Windows.
Then what is it? Do I have to have every service enabled or else it isn't an operating system anymore? FC2 ships with a console. A GUI console. If I disable X-Windows, does it cease to be Linux? No!
You keep trying to focus on ways to REMOVE the console GUI. Whatever.
It doesn't NEED a console GUI or any kind of GUI to be multiuser. If a GUI isn't needed to be multiuser, what's the problem with removing it?
With Citrix (a multi-user version of Windows) it is possible to still get a console even after all the damage you're trying to do to the box.
To disable the local console, change the Windows= part of the value "HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\SubSystems\Windows" from On to Off. I wasn't aware that a configuration change constituted "damage". No, there is no way to get the local console back from the local console.
What about sound support? If only the console user's applications get sound support and remote users don't, wouldn't that prevent the system from being multiuser? Last time I checked, FC2 provided local sound support but didn't provide remote sound support. Under your definition, it can't be multiuser because the console has a function that isn't provided remotely. FC2 ships with local sound support. In order for FC2 to be multi-user, it must provide that console sound support (which it ships with) to all concurrent users; it can't to remote users. How about video framebuffer access? This is only meaningful to the console user. How about plugging in USB devices? Can I do that from a remote machine? Can I plug a device in a remote machine and access it from the server as if it were connected locally? Functionaility provided only to console users.
The reason I'm going to guess that is because you're thinking in terms of telnet and such.
Services like a GUI? Both are a communications channel that applications use to commnicate with users. I'm bringing up services because you said that NT without TS wasn't multiuser becuase only the console got a GUI. That is the ONLY specific reason you have provided that NT isn't multiuser and it isn't valid because services do not make the system multiuser, as you said yourself.
They have
ALL of the functionality that the console has.
A text terminal on a serial port does not provide the GUI that the console can have, which is the exact reason you said NT wasn't multiuser:
Therefore, if only the console user has a GUI, the OS is not multi-user.
A text console from the network provides the same functionaility as a text console from a serial port or a text console in a local window or local fullscreen text, and you can have as many as you want concurrently, owned and operated by different users, Windows or Linux. You don't need TS to have as many concurrent text consoles of equal and full functionaility as you want.
A Linux box without ssh or telnet running or ANY OTHER SERVICE LIKE THAT is
STILL a multi-user operating system.
If no remote services are required for a multiuser system then a NT box without SSH or telnet or RDP or any other service is still a multi-user operating system.
Even if they cannot hear the sound card, they can still access it.
Ok then, even if remote users can't see the console GUI, they can still access it. Any process can get a handle to the local interactive desktop and create or manipluate windows there given the required permission, even if that process is owned by a user connected remotely.
Okay, what if? The console can still re-enable it and use it. That functionality is not available to others.
If the console is disabled, you can't use it to re-enable itself. When the OS starts, you get a black screen; all input from the keybard, mouse and USB HID devices are ignored. That's why it's called disabled. It must be re-enabled remotely by any user that has permission.
The AS/400 is a multi-user operating system.
And it has no console. All access must be done remotely, just like a NT box with the console disabled or a Linux box with the console disabled, or one of those with the console hardware removed.
Answer that yourself. The key was not a GUI, but whether every other user had access to all the features and functions that the console user has.
Multi-user means that every user has access to all features and functions as every other user at the same time.
Under that definition, a UNIX machine that is multiuser in every way except that the console has sound support and there is no remote sound support, becomes not-multiuser until I remove the sound card? It's a feature that not all clients have access to.
If only the local user has access to the removable drives physically on the system, does that also prevent the system from being multiuser?
Therefore, if only the console user has a GUI, the OS is not multi-user.
What if I disable the local Win32 GUI so no one can have it? What if I take the video card right out; unplug the keyboard and mouse so there is no console, only the network? (like an AS/400) You can have remote GUI sessions on NT 3.1 by running X-Windows client apps; is it multiuser then? Even if it's the only option available to all clients? These are normal and supported scenarios for Windows.
Good insight. There is no reason that (well designed) apps can't be run cross-platform natively or otherwise by virtulization. Forcing all users to have the same environment, in fact one out of the user's control, is an evil goal for DRM.
Although in this case, I'd say that since the computers at work are owned by the company, it isn't really your computer. Still, the "let's assume all the employees are incompetent: we must protect them" attitude sucks. They should get admin until they actually break their computer; either for themselves or as a node in the cluster. As long as they can keep it working properly, give it to them: company admin can have the last word, as the company owns the machines, but give delegation a chance.
In order for an OS to be multiuser, it must have those things. I still may not be multiuser, but before it can be, it must have those things; it's a prerequisite. You claimed that under my definition, DOS was multiuser too. I clairified my definition to include some prerequisites that DOS does not satisfy.
Win95 does not have privilages or users or access-controlled objects or full memory protection, but NT does. Are these things not needed for a multi-user system? Sure you can telnet to a 95 box, but normal user A on the system can kill user B's programs without permission; i.e. interfere. This would not be possible on a multiuser system like UNIX or NT.
Even Microsoft's web page admits it.
Microsoft said that as a marketing gimmic to get people to buy the product. It is the only way to get multiple GUI sessions via Win32, but graphical sessions are not a requirement of being multiuser. Just because marketing says it doesn't make it true. The article lies by omitting the fact that remote Win32 sessions are the only feature added by TS. You can have multiuser sessions through telnet on NT without TS, just like you can have multiuser sessions through telnet on UNIX without X-Windows.
Again, getting a telnet prompt is not the same as being multi-user.
I've yet to hear YOUR definition of multi-user, broken into explicit requirements. Tell me in your own words what you consider a multi-user system and specifically how NT does not meet those requirements.
Really? MS-DOS provided preemptive multitasking? No. MS-DOS provided and enforced object security? No. MS-DOS prevented processes from interfering with each other? It doesn't even HAVE processes. MS-DOS had privilages? No. MS-DOS had a user database and a protected component that authenticated users? No.
What's your definition of multi-user?
Actual multi-user functionality. That was added later by Citrix and eventually by Microsoft as "terminal services".
Specifics. I want names of services that UNIX provides that NT doesn't required for multi-user capibility. Name one multi-user thing that NT3.1 can't do that a UNIX server can.
The ONLY thing that Terminal Services provides is multiple graphical sessions through Win32. Multiple users logged on by the network with text sessions has always been suported.
Multi-user. As in multiple users logged on at the same time with different identities and privileges where normal users can't interfere with others or the system. Telnet, SSH, SMB, at and the like are services that take advantage of multi-user capabilities; I meant them as examples of things you could use to exploit NT's multiuser capabilities.
There are fully functional X servers and clients for Windows.
What does Windows NT lack in the first version (3.1), or any subsequent version that prevents it from being multi-user?
You can log in as many times as you want, remote or local. This has been true since the very first version of NT; NT has always been multi-user. See AT, telnet, any one of the many SSH servers, etc. Oh, you meant GUI sessions? Does UNIX require X to be multi-user?
One of the core kernel subsystems is the Object Manager. It handles all kernel objects accessible from user mode, handles to them and security on them; everything from files to events to mutexes to processes to memory sections. It has existed since the first version of NT and provides object security integrated in the system. A token object represents a process or thread's security identity and priviliges. TCB components can add whatever privilieges they want to them; elevate them to whatever level. Perhaps you just don't know how.
In addition to publishing software mentioned by others, there are Software Restriction Policies on XP and later: create a whitelist of allowed programs by hash and directory and distribute it by Active Directory. It can be more work to make a list of all the allowed binaries, but it provides a good amount of lockdown.
First of all, the Linux kernel contains nearly every single driver available for the GNU/Linux operating system. Windows XP does not. [...] It includes kernel modules for doing everything you could possibly imagine (and many things you can't).
This is an important question: are loadable modules that run in kernel mode actually part of the kernel? I'd say that they are in a somewhat grey area, close to being part of the kernel.
Windows's module system is more powerful than Linux's: NT's driver API is much more stable; you can use a driver from NT3.1 in Server2003. More components are available as modules, including boot drivers; all the drivers requried to boot must be compiled directly into a Linux kernel (not so with NT) and the HAL which provides a generic interface to interrupt, timer, and memory control (the Linux kernel does this directly, not as a seperate component).
If you count all the drivers included with WinXP, driver.cab expanded is over 344 megabytes. Of that, I only have about 28MB installed. (in system32\drivers) OTOH, the command console, which runs the full kernel and uses the same drivers as normal takes a total of 11MB expanded in 183 files. If you don't count all the keyboard layout and NLS files, the kernel is divided into 110 modules just for the text console, not all of which may be loaded depending on hardware. According to msinfo, I've got 120 seperate kernel modules currently loaded.
However the Linux Kernel does include most of the things desired in an operating system. Two fully working and implemented sound architectures are there (OSS and ALSA). A networking stack that is infinitely more robust than the Windows one.
There are NT kernel modules for Win32 including USER, GDI, DirectDraw, and Direct3d, DirectSound, protocol drivers such as TCP/IP and SMB, huge libraries of input and output devices.
What's so bad about tcpip.sys that makes it inferior to Linux's implementation? I was under the impression that it was based on BSD's stack. Or are you saying is it something fundamentally wrong with the IO architecture? NT's IO arch comes from VMS's asynch design. TCP is just another IO device that uses special IOCTL commands. IRPs are allocated and used just like disk access.
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.
Slashdot Mirror
NT itself has no problems with a normal copy on write fork; a call to NtCreateProcess with the SectionHandle argument set to 0 will cause the new process to inherit its address space from InheritFromProcessHandle, and you can specify copy on write access. The POSIX (or SFU) subsystem has no problems doing a real fork.
I guess the closest you can get using only Win32, is to make all the memory you want inherited in shared sections and have the child map it copy on write at the same addresses. This requires a different style of creating children, but will work just as well; not bad, just different. I think that Cygwin does something similar, although it doesn't set good security on the sections.
If a COW fork() is just a normal fork, what's a COC fork()? clone() perhaps?
True, NT does favor threads vs processes as they are much lighter, but even more than that, NT favors a very small amount of threads running as asynchronous workers. NT inherited the heavily asynch IO model from VMS.
On NT, instead of creating 64* threads (or whatever the maximum number of concurrent clients will be, possibly hundreds) where one thread waits on each connected client, it would be better to create about 1 thread per CPU and have them take work items off of a completion port. Instead of blocking on IO, always do it asynchronously and have the result posted as another work item.
Both files and sockets can be connected to completion ports. Always have a pending read on open sockets so when a packet is recieved, the OS posts a work item.
Client wants dynamic content but you have to read something first? Start the read now and immediately go back to waiting for another work item in case you could be doing something else in the meantime. When it completes, the OS will post it and you can finish the operation: do the necessary processing, start an asynch write of the result to the socket and go back to waiting for more work.
Client wants a static file? Start the transfer with TransmitFile (it's like UNIX sendfile) and immediately wait for another work item.
The only thing you should be blocking on are locks to synchronize multiple threads. Never IO.
On a single processor machine, you might as well only have one worker thread since it should never be blocked except for lack of work: this means that nothing has to be threadsafe. The buggy PHP extensions could live in a happy single-threaded world without sacrificing any performance. Hopefully you can upgrade to better software if your server has multiple CPUs to take advantage of, or use one process per CPU.
* Apache has to have 200 threads if I ever expected that many clients to connect at one time, just in case? Can't they at least be started dynamically? No wonder it doesn't perform well on Windows. I just hope they aren't used round-robin.
Office is not a part of the operating system. A vulnerability in Office is not a vulnerability in the OS. Office cannot bypass system security including the execute permission.
You've yet to show any exploits that will bypass system file ACLs, which is what you appear to have been referring to in an attempt to refute a execute deny ACL's effectiveness.
If that's not what you were talking about, you need to be more clear. The only security settings I mentioned were file ACLs; if you wanted to bring up something else, you should say so.
Yeah, I guess you are right; viruses could still spread across e-mail without needing any extra binary files when the client has a vulnerability. Still, preventing users from running arbitrary executables (at least the ones in the IE cache) would be helpful wouldn't it?
Regardless, all of these have been patched. 3 years ago. If your patches are up-to-date, these vulns are moot. Vulnerabilities and patches are hardly something Microsoft has a monopoly on.At that point, I wasn't sure what you were talking about.
And your post looks like a good outline to implement security on a Windows network for average users.
Just curious, how well is your system working? Do you still have any virus/malware infections? Do you use the default permissions or do you apply a security template, perhaps a custom one? Do you implement a deny-execute ACE for normal users where they have write access? It won't prevent everything by itself, but will provide another layer of security. How do you deal with (poorly designed) apps that require excessive permissions just to run?
Are you saying that you haven't implemented this? If you had, the users would be unable to propagate e-mail virus attachments because they would be unable to run any attachments containing them.
Let me guess: every user on your network has local admin access. Not giving them admin is the first step in preventing this crap. If you are worried about users executing attachments directly, deny everyone execute access to the profiles directory ("\Documents and Settings"); stick that in a security template and publish it on the 'Directory. Better yet, deny everyone execute access in every directory they have write access to; surely you don't let them write to program directories?
If the workstations were XP, the best solution would be to use Software Restriction Policies to create a whitelist of allowed executables by hash and publish that policy on the domain; if its MD5 isn't on the list, users can't run it. 2000 has something similar in the resource kit.
I don't know about you, but when I install any Linux distro, I have to spend at least an hour customizing it and getting it to work the way I want to.
I personally don't bother with that stuff because I install once per computer. In the long term, setting it up correctly the first time is a small amount of time well spent.I agree with you that Microsoft's marketing department makes their products out to be something they aren't. Unfortunately, at least 99% of all marketing by all companies do this (still doesn't make it right). They say that its so easy to use that you don't need to know anything and this is blantently false. Some of the defaults suck, like giving all new users at install time admin by default.
Still, just because the marketing department sucks and the OOTB defaults have a few issues, does not mean the entire OS is unusable. Defaults can and should be changed; it's not hard.
How long would it take an unpatched RH9 install with the default packages and the firewall off to be comprimised? That's what putting an unpatched XP box on the 'net is like.Oh come on. How many things is it really? 26 * 2? Is there really anything you couldn't stick on a CD and have a batch file execute after install?
Rebooting is quite excessive as none of the system services open or even care about the shell's objects (including semaphors).Internet Explorer runs as a part of the shell entirely in the security context of the current user. No part is in the kernel or a system service.Actually, I'm running Mozilla 1.7.3 to avoid the crap directed at IE and for its other features. More than once I've had it crash, taking all of its windows with it. I think its still more stable than IE though.
I agree with and support everything you are saying.
It looks like all forms of exec() require a filename. Still, what would prevent the malware from creating a new copy of itself, based on an image of itself loaded into memory when it started, in its death code?Nope. In fact, 9x/ME has zero user level security. You either have to be really careful or move to a more secure OS.Windows doesn't need or use the Administrator account to start, or even the Administrators group. All of the critical startup processes run as SYSTEM; a token manufactured by the kernel and not from LSA like the others. (Any process with the SE_TCB privilege (or the kernel) can construct a security token with whatever local credentials)There is another problem stemming from this: local admins (by default) get the SE_TAKE_OWNERSHIP privilege; this means that malware running as admin could forcefully take ownership of any object it is denied access to and since the owner can set the ACL, give itself full access. That is, if it is programmed to do that. A workaround would be to take this privilege away from the admins group. I guess it shows that once your machine is owned, it may be too late.
I don't know what to do about ignorant/incompetent users either.
Also you might try if the spyware is monitoring stuff and can restart itself upon death is to suspend instead of kill the process; the death code won't be executed but the process will be just as useless. Process Explorer can suspend processes.
Still, cleaning up an infected system is a poor substitute for preventing infection in the first place. It is entirely possible; I've been able to do it on all of my own computers. The fist step is not running everything as admin all the time.
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.
I got it. I think it made sense, even if it wasn't the most insightful thing ever posted. MadMacSkillz was attempting to polarize the issue: if it's illegal then it's a mortal crime that must be punished, all the while stating untrue facts. You exposed the lies ;)
FC2 ships with a console. A GUI console. If I disable X-Windows, does it cease to be Linux? No!It doesn't NEED a console GUI or any kind of GUI to be multiuser. If a GUI isn't needed to be multiuser, what's the problem with removing it?To disable the local console, change the Windows= part of the value "HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\SubSystems\Windows" from On to Off. I wasn't aware that a configuration change constituted "damage". No, there is no way to get the local console back from the local console.
What about sound support? If only the console user's applications get sound support and remote users don't, wouldn't that prevent the system from being multiuser? Last time I checked, FC2 provided local sound support but didn't provide remote sound support. Under your definition, it can't be multiuser because the console has a function that isn't provided remotely.
FC2 ships with local sound support. In order for FC2 to be multi-user, it must provide that console sound support (which it ships with) to all concurrent users; it can't to remote users.
How about video framebuffer access? This is only meaningful to the console user.
How about plugging in USB devices? Can I do that from a remote machine? Can I plug a device in a remote machine and access it from the server as if it were connected locally?
Functionaility provided only to console users.
I'm bringing up services because you said that NT without TS wasn't multiuser becuase only the console got a GUI. That is the ONLY specific reason you have provided that NT isn't multiuser and it isn't valid because services do not make the system multiuser, as you said yourself.A text terminal on a serial port does not provide the GUI that the console can have, which is the exact reason you said NT wasn't multiuser:A text console from the network provides the same functionaility as a text console from a serial port or a text console in a local window or local fullscreen text, and you can have as many as you want concurrently, owned and operated by different users, Windows or Linux. You don't need TS to have as many concurrent text consoles of equal and full functionaility as you want.If no remote services are required for a multiuser system then a NT box without SSH or telnet or RDP or any other service is still a multi-user operating system.Ok then, even if remote users can't see the console GUI, they can still access it. Any process can get a handle to the local interactive desktop and create or manipluate windows there given the required permission, even if that process is owned by a user connected remotely.If the console is disabled, you can't use it to re-enable itself. When the OS starts, you get a black screen; all input from the keybard, mouse and USB HID devices are ignored. That's why it's called disabled. It must be re-enabled remotely by any user that has permission.And it has no console. All access must be done remotely, just like a NT box with the console disabled or a Linux box with the console disabled, or one of those with the console hardware removed.And if there IS no console, what then?
If only the local user has access to the removable drives physically on the system, does that also prevent the system from being multiuser?What if I disable the local Win32 GUI so no one can have it? What if I take the video card right out; unplug the keyboard and mouse so there is no console, only the network? (like an AS/400) You can have remote GUI sessions on NT 3.1 by running X-Windows client apps; is it multiuser then? Even if it's the only option available to all clients? These are normal and supported scenarios for Windows.
Good insight. There is no reason that (well designed) apps can't be run cross-platform natively or otherwise by virtulization. Forcing all users to have the same environment, in fact one out of the user's control, is an evil goal for DRM.
Although in this case, I'd say that since the computers at work are owned by the company, it isn't really your computer.
Still, the "let's assume all the employees are incompetent: we must protect them" attitude sucks. They should get admin until they actually break their computer; either for themselves or as a node in the cluster. As long as they can keep it working properly, give it to them: company admin can have the last word, as the company owns the machines, but give delegation a chance.
You claimed that under my definition, DOS was multiuser too. I clairified my definition to include some prerequisites that DOS does not satisfy.
Win95 does not have privilages or users or access-controlled objects or full memory protection, but NT does. Are these things not needed for a multi-user system?
Sure you can telnet to a 95 box, but normal user A on the system can kill user B's programs without permission; i.e. interfere. This would not be possible on a multiuser system like UNIX or NT.Microsoft said that as a marketing gimmic to get people to buy the product. It is the only way to get multiple GUI sessions via Win32, but graphical sessions are not a requirement of being multiuser. Just because marketing says it doesn't make it true. The article lies by omitting the fact that remote Win32 sessions are the only feature added by TS.
You can have multiuser sessions through telnet on NT without TS, just like you can have multiuser sessions through telnet on UNIX without X-Windows.I've yet to hear YOUR definition of multi-user, broken into explicit requirements. Tell me in your own words what you consider a multi-user system and specifically how NT does not meet those requirements.
MS-DOS provided and enforced object security? No.
MS-DOS prevented processes from interfering with each other? It doesn't even HAVE processes.
MS-DOS had privilages? No.
MS-DOS had a user database and a protected component that authenticated users? No.
What's your definition of multi-user?Specifics. I want names of services that UNIX provides that NT doesn't required for multi-user capibility.
Name one multi-user thing that NT3.1 can't do that a UNIX server can.
The ONLY thing that Terminal Services provides is multiple graphical sessions through Win32. Multiple users logged on by the network with text sessions has always been suported.
Multi-user. As in multiple users logged on at the same time with different identities and privileges where normal users can't interfere with others or the system. Telnet, SSH, SMB, at and the like are services that take advantage of multi-user capabilities; I meant them as examples of things you could use to exploit NT's multiuser capabilities.
There are fully functional X servers and clients for Windows.
What does Windows NT lack in the first version (3.1), or any subsequent version that prevents it from being multi-user?
You can log in as many times as you want, remote or local. This has been true since the very first version of NT; NT has always been multi-user. See AT, telnet, any one of the many SSH servers, etc. Oh, you meant GUI sessions? Does UNIX require X to be multi-user?
One of the core kernel subsystems is the Object Manager. It handles all kernel objects accessible from user mode, handles to them and security on them; everything from files to events to mutexes to processes to memory sections. It has existed since the first version of NT and provides object security integrated in the system.
A token object represents a process or thread's security identity and priviliges. TCB components can add whatever privilieges they want to them; elevate them to whatever level. Perhaps you just don't know how.
In addition to publishing software mentioned by others, there are Software Restriction Policies on XP and later: create a whitelist of allowed programs by hash and directory and distribute it by Active Directory. It can be more work to make a list of all the allowed binaries, but it provides a good amount of lockdown.
Windows's module system is more powerful than Linux's: NT's driver API is much more stable; you can use a driver from NT3.1 in Server2003.
More components are available as modules, including boot drivers; all the drivers requried to boot must be compiled directly into a Linux kernel (not so with NT) and the HAL which provides a generic interface to interrupt, timer, and memory control (the Linux kernel does this directly, not as a seperate component).
If you count all the drivers included with WinXP, driver.cab expanded is over 344 megabytes. Of that, I only have about 28MB installed. (in system32\drivers) OTOH, the command console, which runs the full kernel and uses the same drivers as normal takes a total of 11MB expanded in 183 files. If you don't count all the keyboard layout and NLS files, the kernel is divided into 110 modules just for the text console, not all of which may be loaded depending on hardware. According to msinfo, I've got 120 seperate kernel modules currently loaded.There are NT kernel modules for Win32 including USER, GDI, DirectDraw, and Direct3d, DirectSound, protocol drivers such as TCP/IP and SMB, huge libraries of input and output devices.
What's so bad about tcpip.sys that makes it inferior to Linux's implementation? I was under the impression that it was based on BSD's stack. Or are you saying is it something fundamentally wrong with the IO architecture? NT's IO arch comes from VMS's asynch design. TCP is just another IO device that uses special IOCTL commands. IRPs are allocated and used just like disk access.
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.