Full Disclosure mailing list archives
RE: M$ - so what should they do?
From: "Eric Paynter" <eric () arcticbears com>
Date: Mon, 21 Jun 2004 21:21:26 -0700 (PDT)
On Mon, June 21, 2004 3:55 pm, joe said:
I have written several registry editor type apps for customers, it is simply another API. For me writing a text editor is the same as writing a registry editor, in fact, the classes I put together treat them both very similarly from code use perspective.
You missed one significant point, though. In my 15 years of computer programming, I have never *had* to write a text editor. Whereas, you have had to write *several* (your word) registry editors. And the only person who needs to know anything about a filesystem API is a compiler programmer. The rest of us mere humans use the standard library of open(), close(), read(), and write() commands if we want to access files programmatically. One more thing, because of the complexity of the registry and removing it from the filesysem, in Windows, you need to learn the filesystem API (whatever that means to you) to get at the filesystem, the registry API to get at the registry, the COM API if you want to communicate between processes, and several application-specific APIs to programmatically configure most applications. In Unix systems, it's all treated as files. You use a common interface to use them all - open(), close(), read(), write(). How much simpler can it be? And the simpler it is, the less margin for error. And the less margin for error, the less risk of exploit. And that means better security... something to think about. And before you say you *can* configure apps by directly editing the registry, removing the need to learn all of those unique APIs (although still leaving you without a nice local IPC interface), you'd better check your support agreement on that. Even Windows is not supported by MS if you directly edit the registry. Most app vendors say you're on your own too if you do that... So good luck! Any bad move in the registry is like open heart surgery. The box may never boot again - I know, I've done it more than once.
10 people on one machine all load the same app... Here is where the pain comes in. That could be a terrible waste of space and resources, but from a security standpoint, maybe they should all maintain all of their own info for each instance.... But now what about security updates? You
would > be updating 10 instances. Hmmm point/counterpoint. What wins? Wow, that is a problem. Thank God it simply doesn't exist on Unix systems. The system-wide configs go into /etc and the user-customized portions go into /home/username/.appname (remember earlier I said all you need to backup is /etc and /home to restore a Unix machine?). Users don't install their own applications because they simply cannot. If they want an app, they ask the sysadmin to give it to them. If you are the sysadmin, you install it in the system area and the users get access to it as required. Don't forget, Unix systems were multi-user over a decade before DOS was even conceived. All of these problems have long since been solved. The biggest problem with Windows is that it is a multi-user system built on a single-user foundation. (Yes, I know, the NT kernel was built from the ground up the be multi-user, but the system layout did not change to be consistent with that, so maintaining it still has the same problems.)
I think your copy protection scheme might be pushing it a bit. It isn't much more work to capture registry mods and apply them to other machines. One of my old jobs had a large part of my time making up software dist packages that did just that. You capture the reg changes made, you capture the file changes made, you throw it into a package to be deployed by SMS or the perl dist method of your choice. If they were intending that to be wholly magical and to block software copying, there wouldn't be APIs the public would have available to go into it. This is more FUD/conspiracy thinking.
Yes, yes. I know. I did electronic software distribution in a windows environment of several thousand machines for many years. We started with sysdiff (remember that?), and then moved on to the SMS Installer. And we used GHOST to take full images for mass deployment of desktops. I know a million ways to capture an installation difference. But how many home users do? It was meant to be a deterrent, not a 100% success. Remember that before the registry, we didn't need tools like sysdiff. Anyhow, all that noise aside, I think it's safe to say that whatever the registry was intended to be, it was a complete and utter failure. There are more headaches over trying to figure some part of the registry than there ever were worrying about all those lost .ini files. And for some reason, large Unix systems with thousands of users don't have any of these problems. Go figure... Back to the topic: What should they do? They should do like Apple did: stop trying to re-invent the wheel and adopt a tried-and-true model that works. The Unix-like systems are simply easier to manage and safer. And Apple has made them as easy to learn as Windows, while being as easy to administer as Unix. By the way, I'm not saying we should all have Linux systems, or FreeBSD, or any one particular system. I think we should have a diverse set of systems from several vendors, but that can interoperate and have similar interfaces to ease the burden of management. Solaris and Linux come from a completely different code-base. They are vulnerable to completely different types of attacks. Yet the administration of the two is almost identical. A good blend of Unixes in an environment makes it safer. Windows adds complexity simply by being so different, never mind all the problems described above. -Eric _______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
Current thread:
- Re: M$ - so what should they do?, (continued)
- Re: M$ - so what should they do? Bruce Ediger (Jun 21)
- Re: M$ - so what should they do? KF (lists) (Jun 21)
- RE: M$ - so what should they do? joe (Jun 21)
- Re: M$ - so what should they do? Valdis . Kletnieks (Jun 21)
- RE: M$ - so what should they do? Bruce Ediger (Jun 21)
- Re: M$ - so what should they do? Valdis . Kletnieks (Jun 22)
- RE: M$ - so what should they do? joe (Jun 21)
- RE: M$ - so what should they do? Eric Paynter (Jun 21)
- RE: M$ - so what should they do? joe (Jun 21)
- Re: M$ - so what should they do? Valdis . Kletnieks (Jun 21)
- RE: M$ - so what should they do? Eric Paynter (Jun 21)
- Re: PLEASE QUIT YACKING ABOUT M$ Steffen Schumacher (Jun 22)
- Re: PLEASE QUIT YACKING ABOUT M$ Billy B. Bilano (Jun 22)
- RE: PLEASE QUIT YACKING ABOUT M$ Sean Crawford (Jun 22)
- Re: M$ - so what should they do? Aditya, ALD [ Aditya Lalit Deshmukh ] (Jun 22)
- RE: M$ - so what should they do? Ron DuFresne (Jun 21)
- RE: M$ - so what should they do? joe (Jun 21)
- Re: M$ - so what should they do? Valdis . Kletnieks (Jun 21)
- Re: M$ - so what should they do? Valdis . Kletnieks (Jun 21)
- Re: M$ - so what should they do? Nick FitzGerald (Jun 21)
- Re: M$ - so what should they do? Aditya, ALD [ Aditya Lalit Deshmukh ] (Jun 22)