I'm not arguing about the whole security issue.
But the Linux kernel vs Windows kernel I can be sure they're about the same complexity as the Win one. But comparing a kernel to the whole source of something? Don't you think that's a bit unfair?
Printable View
I'm not arguing about the whole security issue.
But the Linux kernel vs Windows kernel I can be sure they're about the same complexity as the Win one. But comparing a kernel to the whole source of something? Don't you think that's a bit unfair?
Well, my point is, the whole Windows codebase is security-critical, whereas in Linux, only the core is.
That makes Microsoft's job a lot harder, and their OS more insecure (more buggy) as a result.
Ah right.
But then again, Windows was written way ago and Microsoft hasn't dared to make such changes to the kernel since it would break pretty much all the stuff out there.
True. Not saying Microsoft's job is easy :).
I am not sure how Windows is organized, but I meant everything, including the UI frontends.
I don't agree with this in either direction. A large portion of the Windows codebase is not security critical. Sure, having the UI provide the user with information during a potentially harmful change of system settings may make more of the system security-critical. But in essence, I think that's still only a very small part of the system that has (direct) security implications, just like it is in Linux.
Of course, all parts of the system that has access to kernel level is essentially security critical. But seeing as the Linux kernel opens up the system to the user-mode graphics subsystem [at least it ALLOWS it to be opened up, if the user-mode graphics driver "does the right things"], it also opens up a big can of worms of security in graphics drivers, made harder by the fact that the major manufacturers drivers are not part of the open source.
--
Mats
Patently untrue. UI code in Windows is allowed to do no more or less than UI code in Linux: access the OS APIs. That most programs in Windows still very often runs with administrator rights is independent of that.
Also untrue. Every single program that runs as root under Linux and has some interface to the non-root world (a socket, a pipe, a DBUS interface, even a configuration file that may have the wrong permissions, etc.), which means probably all daemons and then some, is security-critical. A code injection exploit in those programs leads to a privilege escalation, and once code runs as root, it can do absolutely anything - for example, it can inject code into the kernel via a module.
Can you name an example of a Windows GUI that is more prone to priviledge escalation bugs than it's Linux equivalent ? Even potentially ? Or an example of being less strict ?
You seem to know a lot of vague stuff about Windows, but none of it really hits home. Yes, I think Linux is more secure than Windows because of it's smaller user base and different priorities concerning security vs user friendliness. But if you spend a little effort that I'd expect from someone using *nix systems, Windows can be pretty secure. A well administered Windows system is probably more secure than a Linux box setup by a normal user. Because the core that both are build on is fine.
Hmm. I stand corrected then. Learned something here.
I guess, as said above, the real problem comes from the fact that Windows practically requires running as admin, whereas it's conventional for UNIX users to use a non-root user.
Let's say Windows applications (including some by Microsoft) require you to run as admin (which is bad) :)
Most just require you to install as admin. You can run under any authorized account.
On Vista the situation is improved by the VirtualStore thing (if I understood correctly, it transparently redirects writes to system folders to a user folder using copy-on-write). On XP many applications require running as admin because they write user data in the program's folder in "Program Files", which requires admin access.
Now you've finally gone and done it. Saying Vista is better.Quote:
On Vista the situation is improved by the VirtualStore thing ...