Registry is the single major source of pain and the biggest security loophole, because the registry is essentially a secondary/parallel file system with far inferior performance, inferior security model and most of all, inferior built-in tools to access it or keep an eye on. This partially explains why adware/spyware loves registry: registry for adware is what Tora-Bora was for Taliban.
Wide proliferation of various registry "cleaners" and "doctors" didn't happen without a reason.
Moreover, the way registry is used often calls for complex GUIs to configure/backup/restore anything, denying you a reasonable shot of simple automated scripting: a Windows application of average complexity usually consists of a mesh of various DLLs hooked up together via non-trivial pile of registry entries. Replicating non-trivial configuration of a Windows server onto a fresh box has never been easy, whereas on Linux it's never a problem to write a script for nearly everything.
This is why I also consider Gnome config (registry-like turd) to be a major, major issue: various "Gnome hacks" already painfully resemble Windows in their call for idiotic GUIs where I'm supposed to find some obscure branch in a big-ass tree and change some binary value from 1 to 0 just to disable something, as opposed to editing a simple, plain, sane ASCII file, preferably programmatically.
And finally, starting approx. 5 years ago I've noticed a change in tone in Microsoft's own MSDN documentation: slowly but steadily they're discouraging developers from using registry in favor of your own XML/text files in user's home directory to store application configuration, just compare configuration-related classes in MFC (old school) and .NET2+ (new way).
I have some issues with SVCHOST also but the registry issue alone should be enough for one post.
Well, security is all I do, and I think the superior security of the Unix config model is a huge myth. And again: I'm a Unix person.
First, there are just as many places to backdoor on a Unix desktop (of comparable functionality) as there are in Windows. The difference is that there's one place to monitor and scan in Win32, and a zillion in Unix --- you literally can't know everything (or even 80%) of what you need to monitor in Unix.
Second, it's not as if the Unix permissions model is any more flexible than the Win32 model. If you can edit files in /etc, you own the box. If you can edit files in ~, you own the user. It's the same scenario in Win32.
Third, the reasons there are "cleaners" and "doctors" for Windows are twofold:
---- (1) Windows users have been sold the bill of goods that they need to keep their registries swept. Unix users don't give a shit. I have Evolution config files from 2000 in my homedir, on my Macbook.
---- (2) Windows users get a disproportionate share of all viruses and trojans, because Windows desktops are more than 90% of the outstanding population of hosts, and are nowhere near tapped out for attackers yet.
As for the rest of it:
* show me a registry subtree on Windows that you think is a bad example of sane, automatable, declarative configuration, and I'll find a comparably bad Unix configuration file.
* every enterprise in the world has a standard Win32 build/replication system that covers the registry, and most of the ones I've seen are homebrew, so all my evidence is that this is a solved problem. On the other hand, a lot of my clients don't have a well-managed automated Solaris build.
Thomas, I'm debating the usefulness of registry as a centralized, binary storage of system/application configuration and I'm much less interested in yet another Windows vs Unix war.
My previous post could be shorter: if you want a binary tree-like storage, it already exists and it's called the file system. Each OS has one, and it is standard, comes with a bunch of tools, is familiar to users. Thus I just don't get why Microsoft felt the need for implementing yet another proprietary FS (registry), especially when it's inferior to NTFS or Ext3 in every way, including security, reliability and performance. Perhaps it made sense in FAT/Win16 days.
But I hear you, good tools can be misused and bad ones can be improved upon
Because there was no API common to all Windows applications that reads and writes structured key-value configuration, and without a central registry you have to solve the chicken-and-egg problem of figuring out where to put your configuration files in the first place. And, obviously, the registry predates NTFS on mainstream Win32 platforms.
If there is one place to monitor on Windows, that's a slight advantage. But, it wouldn't take many edits to that one place to cause permanent damage to the system (i.e. programs are now screwed up, you have to reinstall Windows; good luck).
Maybe it is harder to notice a breach on Unix, but it is also correspondingly unlikely that the breach will affect all programs and make the system unusable. The closest thing to the frailty of the registry would be something like hacking /etc/ld.so.conf on a Unix system.
I think the problem with this logic is that you're thinking about filenames and not credentials. There's one place to go to cripple a Windows box (a parallel filesystem), and there's one set of credentials you need to cripple a Unix box (the capability to write /etc, or /usr/share, or /usr/local/mysql, or ~/Library, or...).
I admit to not knowing how the Windows registry's various parts are protected. But individual files/directories can be protected separately on Unix-like systems (whether they are is another question).
If the Unix root user is not enabled, especially for remote access, and assuming you don't have access to the physical device, then it's a question of which Unix accounts and groups you do have access to. Also, technically directory write permission is all that's needed to compromise a Unix file, so all files in the same directory are equally vulnerable. (Even this assumes base permissions and not ACLs, etc.)
First, taking OSX as an example desktop Unix (desktop Linux has the same problem), if you own my UID, you also own my ~/Library, and thus my account and arbitrary code execution under my credentials.
Second, the registry is privileged the same way; write access to one part of the registry doesn't give you write access to all of it.
Third, it is notoriously hard to keep permissions straight on configuration files, especially when you're trying to manage multiple roles (for MySQL, qmail, and root, for instance). So most people screw it up.
But I mean, I don't think this is a huge problem. I just think I can knock down a lot of arguments about how the Win32 registry is an abomination. There's a lot not to like about it, but it isn't crazy.
Wide proliferation of various registry "cleaners" and "doctors" didn't happen without a reason.
Moreover, the way registry is used often calls for complex GUIs to configure/backup/restore anything, denying you a reasonable shot of simple automated scripting: a Windows application of average complexity usually consists of a mesh of various DLLs hooked up together via non-trivial pile of registry entries. Replicating non-trivial configuration of a Windows server onto a fresh box has never been easy, whereas on Linux it's never a problem to write a script for nearly everything.
This is why I also consider Gnome config (registry-like turd) to be a major, major issue: various "Gnome hacks" already painfully resemble Windows in their call for idiotic GUIs where I'm supposed to find some obscure branch in a big-ass tree and change some binary value from 1 to 0 just to disable something, as opposed to editing a simple, plain, sane ASCII file, preferably programmatically.
And finally, starting approx. 5 years ago I've noticed a change in tone in Microsoft's own MSDN documentation: slowly but steadily they're discouraging developers from using registry in favor of your own XML/text files in user's home directory to store application configuration, just compare configuration-related classes in MFC (old school) and .NET2+ (new way).
I have some issues with SVCHOST also but the registry issue alone should be enough for one post.