Why can't you check windows? Because you don't know x86 asm? Oh my. Most users don't know C and can't check linux kernel.
As was said earlier, you're quite adept at comparing apples to toasters. You're trying to tell me how sparse documentation and debugger output are all you need to fix the source. You're out of your mind - you HAVE to have access to a compiler
and the sources in order to modify the kernel. At least with Linux, I have full and ready access to both from the get-go. Last I checked, you had to shell out a few c-notes to
guarantee the functionality of a Windows system, and that's not something I - nor any sysop for that matter - should feel compelled to do.
There have been countless holes in linux and it's still full of bugs. Check any changelog to see for yourself.
Et tu? Can you count how many of those were negligible? Last time I checked, every Windows exploit was system-level
or better.
You can't know your linux systems are secure for sure.
Fair enough, but at least I can
try.
I bet you must remember the openssh holes and how it gained the nickname of "Super Security Hole"? Yeah. Hole after hole, again and again. In source that was available for everyone to read... And this was a source that people were interested in reading. Yet, it always took some time for the next exploit to come around.
Okay, while we're on the topic of "old and oft-exploited avenues of attack," how about ActiveX? Is Downloader.Ject patched yet, or are IE users who dare use Microsoft's "wunderkind" applet code
still subject to this malicious misuse of a potentially decent language? Even you yourself admit to not running MSIE with Java enabled, that would suggest to me that you're somewhat less-than-confident about Microsoft's ability to maintain a functional browser. Then again, they haven't done
that since they acquired it from Mosaic way back when.
Security holes aren't always obvious in the source, they require some damn skilled people to find them. Microsoft has damn skilled people.
...who
still can't make THEIR OWN APPLETS secure. Why should I trust the company - and by connection, its products - if I can't trust its output?
I don't quite get your point anyway. You say windows has undetected issues, and then say linux equivalent has fixes and patches. To undetected issues? How do you fix an undetected issue? If your immediate response is "my thoughts exactly" or similar, we're going nowhere as this has nothing to do with windows anymore.
This has
everything to do with Windows, and I congratulate your effort to dilute the issue. The issue here is that, if this vulnerability exists in Windows,
nobody has noticed it yet. That doesn't mean it doesn't exist; as I said in an earlier analogy: just because the door is closed, that doesn't mean the house is secure. At least in Linux, this issue has been noticed
and recommendations provided for treating it.
If you were however still referring to forkbombs, the issues aren't undetected in windows. Just because you are ignorant about them doesn't make them unknown to others.
My congratulations on the
ad hominem above, but that doesn't work as readily as you might think.
Windows has a lot of issues regarding resource management and such, to great extent because windows systems are rarely used as multiuser interactive shells. The kernel has support for per-process quotas for resources, but you don't typically see these used on your usual windows systems. I'm not sure if there's per-user accounting for these resource quotas, though. I'd have to do some research.
I fail to see what disk management has to do with core vulnerabilities. Way to toss out a red herring to me there, though.
If someone has experience administrating a windows server and knows about the resource quotas, I'd like to know. I really haven't used windows as a multiuser server setup for untrusted binaries, and thus am not confident about all the aspects related to it.
I have, so don't go thinking you're talking to some pseudo-intellectual the next time you formulate a reply. I've tried the quotas, and found them to be - at the least - ineffectual; at the most, a persistent annoyance to my primary users. I also don't use IIS or any of the similar technologies. I suspect that I, like you, am intelligent enough to use UNIX-emulating server technologies, which makes for a nice level of confusion amongst those attempting to exploit the shared box.
The difference lies at the point where I noticed that maybe, just maybe, software
designed for a server OS might actually run better - natively, one might say - on a kernel
designed to replicate the functions of that OS. If I have to explain the differences between "emulated" and "native" then there's been a breakdown of communication and we need to start this conversation anew.
