Oh my, I'm replying to a lot of people now, am I not? Well well, here I go again...
For an untrusted application to run in a users homedirectory, the user first has to let it be chmod +x in the first place.Ohyeah. Since linux apps are so hard to install, there won't be an issue of running untrusted applications. Or if they're ran purposedly, they're being trusted huh? Nice way to get out of the real issue
If you could trojan a user into installing a keylogger as an xpi or something, it would infect a few people. However if anything like that happens, and similar things have happened in the past, there are many geeks on standby that are going to view the code out of interest, and will see it.Will these geeks also go clean up everyone's systems? Didn't think so. When something like that happens in windows, there are various anti-virus companies and a lot of geeks as well to check it out. That doesn't make the problem go away, it's just another step in the security process, you still need to recover from the infection. How do you get the infected people to fix their systems? The problem is same that exists with windows. It's only a bigger problem in windows because windows is more popular.
That system is not perfect, and your right: no system is. Nonetheless I have had more problems that "just arise" on Windows then any other operating system. When my laptop was running Windows the network stack would fuck up and stop letting anything work with TCP, UDP, or anything important. Restarting the adapter would fix this, however often it would stop responding, the stupid little taskbar icon, the window for "repair", or even if I tried doing it by just disabling and renableing the adapter. Other bizarre crashes and other things kept happening.Hardware or driver issue. I cannot see how this is different from using linux and running a proprietary driver. Due to how modern operating systems are designed, drivers have a little bit too much freedom to operate. I have a kind of "dream OS", which would involve a Xen-like approach of separating the guest OS and host OS, with drivers being in the simple host OS layer. And here, the drivers would run under some sort of JIT VM, bytecode, so they couldn't crash the damn system. Well, one can dream. Perhaps in future, once the .NET implementations get stronger, this kind of approach will become viable as well.
As for the comeing Longhorn and .NET objects behind it: This is a new model to use, and will probably create problems. Microsoft will probably end up using a load of legacy code to save time on the release (Microsoft always do).I cannot see any problem with using legacy code here. Once the stuff works, portions can be rewritten to be "more pure" if desired. However since the .NET will create a completely new machine abstraction level, anything that goes underneath it is not an issue. It's just the machine implementation, and it can be changed anytime without affecting stuff above it.
The other things with new models is it will attract new security flaws, and ideas in the darker areas of computing.I don't quite understand what you mean with this, are you saying that a beast you know is better than one you don't? Definitely there will be issues that need to be resolved, but with the VM being a single point of failure for many security related issues, you won't have to go running around patching all applications if a common security issue is found. It only has to be patched once, in the VM.
As for TCPA, it is the stupidest thing ever: It will allow users less control over there system. How the hell is that security? It is not security, its the biggest security hole I have ever heard of. What if someone does a man in the middle attack of the TCPA providers? Your fucked, and everyone else using it is as well.You are making some wild assumptions here, and I think it's because of the TCPA FUD that's been going around. You know, pretty much everything TCPA does can ALREADY be done with software. You don't think so? See Xen and what it does:
http://www.cl.cam.ac.uk/Research/SRG/netos/xen/ ... this same approach could be used to implement a lot of the TCPA functionality. However, a hardware support on some level is needed to make things straightforward. What's I've read about TCPA, it seems to be damn good stuff, and I can't wait to get to play with it.
Also I will point out that Microsoft Windows still has stupid methods of permissions, that are its biggest problems. Executables are executable via a silly file extension, which makes things MUCH easier for a hacker. Not only that but it hides in unsuspecting file extensions like .SCR for example.And if you unzip or tar x some file under linux, the executable metadata doesn't get propagated to the filesystem? Damn, it does. There you go. Ofcourse, the windows issue is that the metadata isn't for the OS, it's for the GUI. All files are potentially executables and you can CreateProcess() against even a .txt file.
However, the lack of metadata isn't the issue here. The issue is overloading of doubleclicking. In some cases, it runs the associated program. In some cases, it runs the file itself as a program. This isn't necessarily bad, but it requires user to know the difference, and in some cases, it gets relatively tough. Another example of the same issue is how command prompt overloads file execution. If you type a filename in cmd.exe, it first tries to CreateProcess() and then it tries to check for file associations and stuff. The problem is, CreateProcess() can start an executable no matter the filename. Try this: rename the extension of some exe to "txt", and try to run it in the command prompt. You'll see that it still runs it, since the extension resolution only happens afterwards.
So, the problem is overloading of different operations. This is definitely bad security, as seen elsewhere where it has happened. Another example of it would be Outlook's midi-executable hole that was found (and fixed) long ago. Attach an executable, and claim it has a .mid mime-type, then require it be played as a background sound. The implementation used some overloaded mechanism to process the file, that was able to do more than was required, and definitely more than was expected. Result: the damn file ran when mail was read.
I agree that this is bad design, however there's no going back in win32-land, since ShellExecute() and similar things are depended on by everyone. Getting to .NET is the ultimate solution to fix the mess, since that lets us drop the win32 crap behind.
Microsoft does not have anything that really compares to what runs on Linux, or what is being shipped with most good distros. Windows' shipped firewall is very backwards in most respects. With iptables you can put a lot more into the rules, you can restrict individual users, individual groups, and all kinds of stuff. Then there are things like snort which provide even better security because it actually looks at the data and works with that.Obviously you're only comparing the things that you want to. The windows native kernel is superior to that of linux, except in some specific things. Unfortunately, these specific things are quite significant, but the windows kernel still compares pretty damn well to linux. Yeah, I'd like better networking mechanisms, too, that's one thing where linux wins. If you want a router that performs complex traffic shaping (weighted round robin, for example), there aren't really any alternatives than using linux/iptables/tc and friends. This might be the only reason I'll ever get a linux system running at home, but for now I haven't had such a strong need for a traffic shaper.
What comes to snort, I've found it gives way too many false positives to be useful at all. It'd take a year to configure it to only show sane things.
Then there is SELinux, which also comes with Fedora Core 3 and probably other distros. SELinux is a lot more versatile then even an ACL setup.There have been some funny kernel patches for linux around for quite a while now, but I hadn't seen any real distro use any of it. I hadn't heard that FC3 ships with it by default, and that definitely makes things interesting. With such patches, you can actually have a linux system that I'll admit is more secure than Windows. However, for now, I'll wait to see these things actually get more widely used.
