I agree that EA has some really crappy games now, but back in the commodore 64 days, they had some of the best games: Ultimate Wizard, Sky Fox... What happened? Seems like the same story with Accolade.
I did some more research. You can't disable the RPC service without breaking A LOT of things. Almost all other services depend on it. Even the clipboard depends on it. It always has open ports on the network and has been the target of most of the Win NT worms. Anyways, I think you were right that Windows has vulnerable network services that can't be practically disabled since they provide basic functionality.
SMB is implemented as the 'lanmanserver' and 'lanmanworkstation' services. I can stop and diable them. I can delete the files that implement them: srvsvc.dll srv.sys
wkssvc.dll mrxsmb.sys Windows still starts, but without SMB file sharing, and named pipes.(and any other services that depend on them) As for remote control, it is implemented as terminal services. Some of it is in the core, but no more than a multiuser unix has. XP has no more terminal services components embedded in it than NT3.51 does. I can disable remote connections in the system control panel, and I can delete the remote components, like rdpdr.sys and it will only impact remote connections; nothing else.
Part of the core operating system? I guess that depends on how you define 'core operating system'. Microsoft likes to think that everything on the Windows CD is part of the core operating system, but that really isn't true. I consider the core operating system to be the kernel, HAL, executive services (like the configuration manager) and the session manager. No daemons. Outside of the core are device drivers, subsystem APIs (like win32), LSA (local security authority), RPC, the service control manager...
What specific security vulnerability exsists in what you define as the core of windows?
Add on to that the fact that windows [security] flaws are systemic and linux flaws tend to be in indvidual daemons which may or may not have system level security (See apache running in it's own user/group, same with mysql, etc).
Care to name an example of a 'systemic' security flaw in Windows? Windows security flaws are in services (daemons) too.
Yes, Windows has a bad habit of running things with too many priveleges by default. However, XP and later also have unpreviliged accounts that many services run in, and Apache can run in it's own user/group just as easily as it does in Linux.
Nothing in user mode can hog the cpu without showing up as cpu usage. Actually, cpu usage is measured as 100% minus the amount of time spent in the idle thread, according to the scheduler. Only something in kernel mode (a kernel driver) can hog the cpu like you described (3% usage reported); by sitting at a high IRQL. Try updating, or changing to alternative drivers (if possible).
Not exactly; NT was originally written for an upcoming Intel cpu called the N-10. Intel took forever to supply MS with prototypes, and the product ended up flopping. It was ported to MIPS before the 386. The original kernel designers wanted to avoid tying NT to a single cpu. It sucks that MS stopped supporting RISC processors, but they are a buisness, and spending money on products that don't sell is stupid.
This is a good idea. However, making copies of it in that fasion is a violation of the licence agreement, and if you are going to ignore that, you might as well pirate the volume licenced version that has no activation. Not to mention how slow it will be under Bochs.
You can use the terminal client on Win98 and XP, both of which support booting from a bootp server, when configured correctly. If the computers can boot from CDs, you could make a Windows PE (pre-installation environment; search the web for bart pe) CD that will auto boot into the RDP client. You could even use Linux as the client with rdp. About licences, I don't think that MS charges anything for educational use. For commercial application however, the licences are expensive.
Oh but you CAN have fast switching at the same time. 1. Disable the welcome screen(from control panel).
2. Open the registry editor. 3. Browse to HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon 4. Find the DWORD value AllowMultipleTSSessions. 5. Set it to 1. 6. Reboot.
Now you can use the users tab of task manager to switch between sessions: Right click the current user and select 'disconnect' to get back to the logon screen without logging off. From there you can create new sessions or connect to existing ones. If current user is a member of 'Remote desktop users' then they can also see what other users are logged on in the users tab. Selecting connect from the right-click context menu will prompt for that user's password so you can connect to that session.
It's not officially supported by MS, but I have been using it for a long time, with many concurrent sessions with zero problems. It is, after all, the same way that WS2003 manages multiple sessions.
Nelson uses open-source software to run all 110 Riverdale student terminals.
They go on to compare that to full Windows workstations. They are comparing workstations to an application server. Of course the app server will be cheaper. This is true regardless of Windows or Linux. Windows has Terminal Services. Is there some reason they couldn't compare apples to apples?
Um, contemporary Windows only runs on 386 derivatives, AMD64 and Itanium. But Windows used to support Alpha, MIPS, and PPC too. Yes, it is bad that MS doesn't support those anymore, but you can still run Windows on them. Besides, standard interfaces like PCI and USB can be used, regardless of CPU architecture. Or were you thinking of some other kind of hardware difference?
Even better, just ghost the install over the network every night; reformat & reinstall automatically.
Here is a product that does something similar: Deep Freeze
You can do mostly anything* on the computer, but upon restart, the contents of the hard disk are restored exactly to the same state as when the system was frozen. It also provides provisions for execptions so you can still make official changes. My college uses it, and all of the computers are in a consistent, crapware free state when you turn them on. It's a nice feeling.
*Normal users run as an administrator, but cannot debug other processes, install drivers or services.
In general, no. It all depends on what is actually wrong with the app. I agree that with most apps (on Windows), reinstallation is a standard way to fix things. This is not a good thing. I usually try to fix them without resorting to reinstallation.
I don't want to install kernel-mode software just to run some app that should run entirely in user mode. CoLinux requires a kernel mode component. If you distribute the app with CoLinux as a requirement, the end user will have to install a driver.
And in Windows, you don't even need another partition: explicitly deny everyone execute access for everything in their profile. Or wherever they can create files.
Well in Windows NT every object has a seperate ACL, and in at least v5 (win2k), you can have multiple sessions; each one has a seperate branch in the Object Manager's namespace: these are links to all the devices used by the win32 subsystem. In theory, you could run each process in a seperate session, but the overhead would be disgusting. You could at least provide a seperate user account for each program you planned to run, giving it explicit minimal permissions.
My point is that some of these things already exist in some form, even if they are badly implented and supported. What I am looking forward to is ReactOS: An open source WinNT clone. And in the mean time, what is also needed is a tool that analyzes the minimum access required for something and can be used to easily apply the settings.
That's a good idea, if Mozilla isn't already associated with opening internet files. But if Outlook just launches IE directly, without consulting shell associations or anything else in the registry, it won't work. In that case, mabye IE's filename is located in one of Outlook's string resources; you could use a resource editor like ResHack to change them.
Looking in the registry, IE is still associated with html files, even though I told the 'program access defaults' control panel that I wanted to use Mozilla.
Slashdot Mirror
Hey, SCO duped their customers into buying licences in the first place, mabye SCO thinks they can convince their customers to settle.
I agree that EA has some really crappy games now, but back in the commodore 64 days, they had some of the best games: Ultimate Wizard, Sky Fox...
What happened?
Seems like the same story with Accolade.
I did some more research. You can't disable the RPC service without breaking A LOT of things. Almost all other services depend on it. Even the clipboard depends on it. It always has open ports on the network and has been the target of most of the Win NT worms.
Anyways, I think you were right that Windows has vulnerable network services that can't be practically disabled since they provide basic functionality.
SMB is implemented as the 'lanmanserver' and 'lanmanworkstation' services. I can stop and diable them. I can delete the files that implement them:
srvsvc.dll
srv.sys
wkssvc.dll
mrxsmb.sys
Windows still starts, but without SMB file sharing, and named pipes.(and any other services that depend on them)
As for remote control, it is implemented as terminal services. Some of it is in the core, but no more than a multiuser unix has. XP has no more terminal services components embedded in it than NT3.51 does. I can disable remote connections in the system control panel, and I can delete the remote components, like rdpdr.sys and it will only impact remote connections; nothing else.
Give me an example.
The components that I consider to be the core do not depend on any daemons.
Part of the core operating system? I guess that depends on how you define 'core operating system'. Microsoft likes to think that everything on the Windows CD is part of the core operating system, but that really isn't true.
I consider the core operating system to be the kernel, HAL, executive services (like the configuration manager) and the session manager. No daemons. Outside of the core are device drivers, subsystem APIs (like win32), LSA (local security authority), RPC, the service control manager...
What specific security vulnerability exsists in what you define as the core of windows?
Windows security flaws are in services (daemons) too.
Yes, Windows has a bad habit of running things with too many priveleges by default. However, XP and later also have unpreviliged accounts that many services run in, and Apache can run in it's own user/group just as easily as it does in Linux.
Microsoft is notorious for bundling things to cause lock-in.
How are they going to balance that with creating a light version of XP?
Nothing in user mode can hog the cpu without showing up as cpu usage. Actually, cpu usage is measured as 100% minus the amount of time spent in the idle thread, according to the scheduler. Only something in kernel mode (a kernel driver) can hog the cpu like you described (3% usage reported); by sitting at a high IRQL.
Try updating, or changing to alternative drivers (if possible).
Not exactly; NT was originally written for an upcoming Intel cpu called the N-10. Intel took forever to supply MS with prototypes, and the product ended up flopping. It was ported to MIPS before the 386. The original kernel designers wanted to avoid tying NT to a single cpu.
It sucks that MS stopped supporting RISC processors, but they are a buisness, and spending money on products that don't sell is stupid.
This is a good idea.
However, making copies of it in that fasion is a violation of the licence agreement, and if you are going to ignore that, you might as well pirate the volume licenced version that has no activation. Not to mention how slow it will be under Bochs.
You can use the terminal client on Win98 and XP, both of which support booting from a bootp server, when configured correctly. If the computers can boot from CDs, you could make a Windows PE (pre-installation environment; search the web for bart pe) CD that will auto boot into the RDP client. You could even use Linux as the client with rdp.
About licences, I don't think that MS charges anything for educational use. For commercial application however, the licences are expensive.
Oh but you CAN have fast switching at the same time.
1. Disable the welcome screen(from control panel).
2. Open the registry editor.
3. Browse to HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon
4. Find the DWORD value AllowMultipleTSSessions.
5. Set it to 1.
6. Reboot.
Now you can use the users tab of task manager to switch between sessions: Right click the current user and select 'disconnect' to get back to the logon screen without logging off. From there you can create new sessions or connect to existing ones. If current user is a member of 'Remote desktop users' then they can also see what other users are logged on in the users tab. Selecting connect from the right-click context menu will prompt for that user's password so you can connect to that session.
It's not officially supported by MS, but I have been using it for a long time, with many concurrent sessions with zero problems. It is, after all, the same way that WS2003 manages multiple sessions.
Um, contemporary Windows only runs on 386 derivatives, AMD64 and Itanium. But Windows used to support Alpha, MIPS, and PPC too. Yes, it is bad that MS doesn't support those anymore, but you can still run Windows on them.
Besides, standard interfaces like PCI and USB can be used, regardless of CPU architecture. Or were you thinking of some other kind of hardware difference?
You can do mostly anything* on the computer, but upon restart, the contents of the hard disk are restored exactly to the same state as when the system was frozen.
It also provides provisions for execptions so you can still make official changes. My college uses it, and all of the computers are in a consistent, crapware free state when you turn them on. It's a nice feeling.
*Normal users run as an administrator, but cannot debug other processes, install drivers or services.
In general, no. It all depends on what is actually wrong with the app.
I agree that with most apps (on Windows), reinstallation is a standard way to fix things. This is not a good thing. I usually try to fix them without resorting to reinstallation.
You can export .reg files, copy those and import them in an automated way. There is also a remote registry service.
I don't want to install kernel-mode software just to run some app that should run entirely in user mode.
CoLinux requires a kernel mode component.
If you distribute the app with CoLinux as a requirement, the end user will have to install a driver.
OH and stupid users are going to know how to configure a UNIX machine securely and correctly?
And in Windows, you don't even need another partition: explicitly deny everyone execute access for everything in their profile. Or wherever they can create files.
Well in Windows NT every object has a seperate ACL, and in at least v5 (win2k), you can have multiple sessions; each one has a seperate branch in the Object Manager's namespace: these are links to all the devices used by the win32 subsystem. In theory, you could run each process in a seperate session, but the overhead would be disgusting. You could at least provide a seperate user account for each program you planned to run, giving it explicit minimal permissions.
My point is that some of these things already exist in some form, even if they are badly implented and supported. What I am looking forward to is ReactOS: An open source WinNT clone.
And in the mean time, what is also needed is a tool that analyzes the minimum access required for something and can be used to easily apply the settings.
A format for creating configuration databases? How about one that is supported by the OS? Sounds like Windows registry hives.
That's a good idea, if Mozilla isn't already associated with opening internet files. But if Outlook just launches IE directly, without consulting shell associations or anything else in the registry, it won't work. In that case, mabye IE's filename is located in one of Outlook's string resources; you could use a resource editor like ResHack to change them.
Looking in the registry, IE is still associated with html files, even though I told the 'program access defaults' control panel that I wanted to use Mozilla.