why on earth would anyone have to change the default filesystem permissions?
Indeed, why? Default permissions on Win2K and XP are such that normal users only have read & execute rights to %windir% and %programfiles%. No need to change anything - it's already locked down.
The reason is that windows has no concept, and never did, of paritioning user data from system data. In any unix, the filesystem is sensibly laid out such that removing write access to huge swathes of it do absolutely nothing to hinder it's usability. Not so in windows, everything's mixed together in one big steaming mess.
Hmm... On Windows, user data goes to My Documents. Per-user application data goes to HKCU\Software or %appdata%. Machine wide application data goes to HKLM\Software or %programfiles%.
All the infrastructure is there, the only problem is with the stupid apps that don't use it (and I haven't seen many such apps lately).
Do you know anything about software development? Or how OSs work?
If the kernel crashes it is a kernel bug. PERIOD!
Sigh... What about crashes caused by the 3rd party drivers? Are they kernel bugs too?
You DO NOT know whether your XP crash was caused by a bug in the kernel or something else. You might know if you weren't lazy and looked at the crash dump. But you didn't. So stop spreading FUD.
IIS also is (partially) kernel-mode. ISAPI filters are handed pointers to kernel memory...
Not true. IIS6 does have a kernel mode component, but all application code runs in user mode. There is no way for an ISAPI dll to access kernel memory.
You can 'blue screen' Win2k with an ISAPI filter.
First of all, IIS6 doesn't run on Win2k. Second, you can't do that even on Win2k3 (unless you run as SYSTEM and do something bad intentionally, like killing csrss).
As I have no access to winXP source, I couldn't investigate.
So you're just going to assume every crash is MS problem?
As a matter of fact, you CAN diagnose majority of NT crashes without having access to the source. All you need to do is load the dump into debugger and type.symfix, !analyze -v. If you can't even do that, I doubt that having source code would help you.
When closing a window inside of XFree, I could get a blue screen every time. It was a rendering bug in XFree86, but because it ran at kernel level, it spread.
What ran at kernel level? I'm not familiar with XFree86 - does it have kernel mode components? If so then of course it can crash the system - it's no different from installing a buggy driver.
If you're saying that a bug in user mode program was causing a system crash, then it's a different matter. Can you provide more details (like a crash dump or steps to reproduce the problem)?
The WinNT kernel and its derivatives contain all the code to draw buttons, scrollbars, and other gui widgets
Ya wanna back that up with some cold hard facts, or are you just another uninformed teenager zealot who r0xx0rz with Linux and only uses Windows to play cool games*?
Take a look at win32k.sys in the kernel debugger - you'll see things like win32k!DrawPushButton, win32k!DrawRoundedRectangularShadow and so on.
Any sort of oops in the GUI code is an oops at kernel level, which means it can trash any memory and cause a crash.
Now this is definitely wrong - a bug in your MFC program can't blue screen the system (just like calling CreateProcess incorrectly cannot cause system crash...)
Also, the claim that this significantly increases kernel size is wrong. First of all, win32k is not (technically) the kernel - it's a separate component that runs in the kernel mode. Second, it's only about 1.5 MB in size.
Information about components that in the normal course of operation send information to or receive information from one or more sites on the Internet....
Information about components that routinely display buttons or links that make it easy for a user to initiate communication with one or more sites on the Internet...
Brief descriptions of components like Microsoft Internet Explorer and Microsoft Outlook® Express that are designed to communicate with the Internet...
I wonder if he's counting the 3-10 times a week my XP machine says it's sending a bug report back to Microsoft.
Actually, this just shows that some of his arguments are still true, even though the interview is from 1995, and XP was released in 2001.
Most users simply wouldn't bother submitting a bug report if for example IE crashed on them. This is exactly why automatic error reporting was introduced in XP.
Would you submit 3 bug reports every week if XP wasn't doing it for you?
If you note my post I indicated that I am using the "Home Edition" of XP. This version has been modified to disable access to such niceties as the user manager and ACLs on individual files and directories.
ACL UI might be disabled, but you still should be able to use cacls.exe.
About the only case I can think of where a debugger is the best choice is in diagnosing a deadlock
As well as memory corruptions, CPU hogging and various exceptions that can't be debugged given only a stack trace.
and even then, that's not always an option if it happened at a customer site (they generally need to restart and get back to business rather than wait for you to start a remote debugging session
They can create a memory dump and send it to you. All they have to do is run ntsd -pv -p [pid] -c ".dump -mfh foo.dmp;q".
not to mention MS remote dbg sucks
What exactly sucks? Latest NT debuggers have very good remote debugging capabilities, IMO.
Anti-intrusion systems should be built into the OS. "This binary has been tampered with, refusing to run it" is what we need, but somewhere in a happy medium between that and the "trusted computing" that is creating fear amoungst the geek comunity.
The problem is, once you allow hostile code to run with enough permissions to change system binaries, it's already game over. The first thing this code would do is disable the intrusion detection system.
The only way to solve this (besides the obvious "don't run untrusted code with administrator/root permissions") is to implement some form of hardware based protection - think XBox/Palladium.
IBM... when Microsoft stole the code to make NT...
Tell that to Dave Cutler and other guys from Digital who started working on NT in 1988. I'm sure they would be surprized to know that they stole their code from IBM.
Come on, this is just stupid. To add to what siliconjunkie02 said, you're assuming that there's a rule that allows anything named 'notepad.exe'. Of course nobody in their right mind would do that. That's what hash or certificate rules are for. As I mentioned in my other posts in this thread, it would still be possible to bypass them in some cases, but it wouldn't be so easy.
Also, no amount of VBA scripting will give you admin access if the box is properly patched. And local elevation of privilege bugs are not that common. IE scripting bugs definitely aren't going to make you an admin, they can only destroy your own files.
Oh, and to be able to use kernel debugger you have to be an admin already.
As for permissions control based on the filenames - yes, this is stupid. You should control access to resources, not executables. Normal NT security model is just for that. Software Restriction policies are for administration, not for security.
If you lockdown a machine with NTFS ACLs and Software Restiction Policies, there's no way a normal user can run arbitrary code. Try it on a test domain - Give a user write access to only his MyDocs folder, and do SRP rule that bans any exe's in MyDocs.
I can immediately see several problems with this setup:
1. Since the only rule that we have is to block anything from MyDocs, the user can still run any program from system32. So he can use for example ntsd.exe to write arbitrary data into one of his own processes (like his shell). If he can do this, it's game over.
To prevent this you'd have to carefully examine every system executable and disable the bad ones, or replace the shell so that users can't even try to run them. This setup would be closer to a kiosk than a normal workstation though.
2. How do you create your path rule? Are you sure there are no path canonicalization issues with it? (most likely there are)
3. Unless you go out of your way to prevent it, users can change their registry and profile settings, so they can try to manipulate them to cause a crash in the shell or some other process that runs as the user. Most software is not tested very well to protect against this scenario (users trying to crash or corrupt their own processes). It's quite likely that you could find bugs leading to code execution.
4. How do you make sure MyDocs is the only place where users can create files? It's not trivial. Do you know that by default there are places other than %userprofile% that are writable by normal users?
Sure, it's possible to lock things down so that it will be very difficult for users to run arbitrary code. But it's not easy and if you also want to allow other programs besides the shell, you're almost guaranteed to get it wrong.
Note that I'm not saying that SRPs are not useful - they are. But they shouldn't be your only line of defense.
In windows you have to options: either you allow people to do everything or you allow them to do nothing. The policy editor just stops working once you allow someone to run an.exe from his desktop since he can break the system (with one of the numerous exploit that for example the GUI gives you).
What the hell is this supposed to mean? On a properly patched system users can run executables from their desktops all they want, and this won't allow them to bypass security related group policy settings (I'm talking about things like user privileges and group membership, not UI stuff like access to Start menu).
You can completely lock down a machine so that cmd.exe doesn't work no matter what and the only.exe's that do work are the ones you specify.
But this is not.
If you're talking about Software Restriction policies, they only protect users from shooting themselves in the foot. A determined user will still be able to run arbitrary code if he really wants to. Truly secure code restriction would require hardware support (like XBox).
Software restriction policies are useful but please don't depend on them for security. That's what proper user rights and ACLs are for.
Besides the fact that COM is not portable, the main problem with COM is that the runtime layer is too thin and can't provide many services that are available in.NET environment. When you call an in-proc COM method, you basically execute raw native code. Which makes it nearly impossible to implement all the cool features like sandbox-type security, transparent cross-language exceptions, garbage collection, reflection etc.
(And by the way, COM runtime - ole32.dll etc - can't be used in kernel mode. WMI providers are user-mode.)
My point is you really can't trust microsoft. There codebase is getting more and more bloated by the day. I predict that longhorn will be more unstable then XP and the os after so on..
I remember when NT4 came out people where screaming about the bloat and instability caused by moving GDI and USER into kernel mode.
Then win2k came out and it was declared even more bloated and unstable than NT4.
Then when XP came out, win2k was suddenly renamed "the most stable Windows ever" and XP was the new leader in bloat and instability.
Do you see the pattern? I predict that by the time Longhorn is released, XP (or.NET Server) will become "the most stable Windows ever".
IE and Outlook run as *you*. If you run as root (administrator) then it's your problem.
Even if for some reason you often need administrative rights and you're too lazy to use runas so you run as an admin all the time you can still easily run IE without admin privileges. Right-click the shortcut, select RunAs, check the "Protect my computer blah blah" option.
Slashdot Mirror
I've never used XP Home, so I'm curious... Is Power Users really gone (like, doesn't show up in 'net localgroup') or is it just hidden from the UI?
I suspect it's the latter which means you can still use it.
BTW, I hope you realize that if somebody is a Power User they can easily become an admin...
Indeed, why? Default permissions on Win2K and XP are such that normal users only have read & execute rights to %windir% and %programfiles%. No need to change anything - it's already locked down.
The reason is that windows has no concept, and never did, of paritioning user data from system data. In any unix, the filesystem is sensibly laid out such that removing write access to huge swathes of it do absolutely nothing to hinder it's usability. Not so in windows, everything's mixed together in one big steaming mess.
Hmm... On Windows, user data goes to My Documents. Per-user application data goes to HKCU\Software or %appdata%. Machine wide application data goes to HKLM\Software or %programfiles%.
All the infrastructure is there, the only problem is with the stupid apps that don't use it (and I haven't seen many such apps lately).
Sigh... What about crashes caused by the 3rd party drivers? Are they kernel bugs too?
You DO NOT know whether your XP crash was caused by a bug in the kernel or something else. You might know if you weren't lazy and looked at the crash dump. But you didn't. So stop spreading FUD.
Not true. IIS6 does have a kernel mode component, but all application code runs in user mode. There is no way for an ISAPI dll to access kernel memory.
You can 'blue screen' Win2k with an ISAPI filter.
First of all, IIS6 doesn't run on Win2k. Second, you can't do that even on Win2k3 (unless you run as SYSTEM and do something bad intentionally, like killing csrss).
How do you know it wasn't the video driver? Or something else? Did you analyze the dump? Oh, you don't even have a debugger...
I see. Must be an MS problem then.
So you're just going to assume every crash is MS problem?
As a matter of fact, you CAN diagnose majority of NT crashes without having access to the source. All you need to do is load the dump into debugger and type .symfix, !analyze -v. If you can't even do that, I doubt that having source code would help you.
What ran at kernel level? I'm not familiar with XFree86 - does it have kernel mode components? If so then of course it can crash the system - it's no different from installing a buggy driver.
If you're saying that a bug in user mode program was causing a system crash, then it's a different matter. Can you provide more details (like a crash dump or steps to reproduce the problem)?
Take a look at win32k.sys in the kernel debugger - you'll see things like win32k!DrawPushButton, win32k!DrawRoundedRectangularShadow and so on.
Now this is definitely wrong - a bug in your MFC program can't blue screen the system (just like calling CreateProcess incorrectly cannot cause system crash...)
Also, the claim that this significantly increases kernel size is wrong. First of all, win32k is not (technically) the kernel - it's a separate component that runs in the kernel mode. Second, it's only about 1.5 MB in size.
Controlling Communication with the Internet
http://www.kuro5hin.org/story/2001/6/19/05641/7357
Actually, this just shows that some of his arguments are still true, even though the interview is from 1995, and XP was released in 2001.
Most users simply wouldn't bother submitting a bug report if for example IE crashed on them. This is exactly why automatic error reporting was introduced in XP.
Would you submit 3 bug reports every week if XP wasn't doing it for you?
Could it be because you actually need 'net localgroup' ?
Actually, I can write up a VB app if there is an API that will do the trick...
You can do it in 3 lines of VBScript/JScript:
Create a Local Group on a Computer
ACL UI might be disabled, but you still should be able to use cacls.exe.
This is simply not true. See this article for details.
As well as memory corruptions, CPU hogging and various exceptions that can't be debugged given only a stack trace.
and even then, that's not always an option if it happened at a customer site (they generally need to restart and get back to business rather than wait for you to start a remote debugging session
They can create a memory dump and send it to you. All they have to do is run ntsd -pv -p [pid] -c ".dump -mfh foo.dmp;q".
not to mention MS remote dbg sucks
What exactly sucks? Latest NT debuggers have very good remote debugging capabilities, IMO.
The problem is, once you allow hostile code to run with enough permissions to change system binaries, it's already game over. The first thing this code would do is disable the intrusion detection system.
The only way to solve this (besides the obvious "don't run untrusted code with administrator/root permissions") is to implement some form of hardware based protection - think XBox/Palladium.
No I mean NT.
For details see Windows NT and VMS: The Rest of the Story
Tell that to Dave Cutler and other guys from Digital who started working on NT in 1988. I'm sure they would be surprized to know that they stole their code from IBM.
Also, no amount of VBA scripting will give you admin access if the box is properly patched. And local elevation of privilege bugs are not that common. IE scripting bugs definitely aren't going to make you an admin, they can only destroy your own files.
Oh, and to be able to use kernel debugger you have to be an admin already.
As for permissions control based on the filenames - yes, this is stupid. You should control access to resources, not executables. Normal NT security model is just for that. Software Restriction policies are for administration, not for security.
I can immediately see several problems with this setup:
1. Since the only rule that we have is to block anything from MyDocs, the user can still run any program from system32. So he can use for example ntsd.exe to write arbitrary data into one of his own processes (like his shell). If he can do this, it's game over.
To prevent this you'd have to carefully examine every system executable and disable the bad ones, or replace the shell so that users can't even try to run them. This setup would be closer to a kiosk than a normal workstation though.
2. How do you create your path rule? Are you sure there are no path canonicalization issues with it? (most likely there are)
3. Unless you go out of your way to prevent it, users can change their registry and profile settings, so they can try to manipulate them to cause a crash in the shell or some other process that runs as the user. Most software is not tested very well to protect against this scenario (users trying to crash or corrupt their own processes). It's quite likely that you could find bugs leading to code execution.
4. How do you make sure MyDocs is the only place where users can create files? It's not trivial. Do you know that by default there are places other than %userprofile% that are writable by normal users?
Sure, it's possible to lock things down so that it will be very difficult for users to run arbitrary code. But it's not easy and if you also want to allow other programs besides the shell, you're almost guaranteed to get it wrong.
Note that I'm not saying that SRPs are not useful - they are. But they shouldn't be your only line of defense.
What the hell is this supposed to mean? On a properly patched system users can run executables from their desktops all they want, and this won't allow them to bypass security related group policy settings (I'm talking about things like user privileges and group membership, not UI stuff like access to Start menu).
This is true...
You can completely lock down a machine so that cmd.exe doesn't work no matter what and the only .exe's that do work are the ones you specify.
But this is not.
If you're talking about Software Restriction policies, they only protect users from shooting themselves in the foot. A determined user will still be able to run arbitrary code if he really wants to. Truly secure code restriction would require hardware support (like XBox).
Software restriction policies are useful but please don't depend on them for security. That's what proper user rights and ACLs are for.
(And by the way, COM runtime - ole32.dll etc - can't be used in kernel mode. WMI providers are user-mode.)
I remember when NT4 came out people where screaming about the bloat and instability caused by moving GDI and USER into kernel mode.
Then win2k came out and it was declared even more bloated and unstable than NT4.
Then when XP came out, win2k was suddenly renamed "the most stable Windows ever" and XP was the new leader in bloat and instability.
Do you see the pattern? I predict that by the time Longhorn is released, XP (or .NET Server) will become "the most stable Windows ever".
IE and Outlook run as *you*. If you run as root (administrator) then it's your problem.
Even if for some reason you often need administrative rights and you're too lazy to use runas so you run as an admin all the time you can still easily run IE without admin privileges. Right-click the shortcut, select RunAs, check the "Protect my computer blah blah" option.