RE: [Full-Disclosure] M$ - so what should they do?

• Previous message: joe: "RE: [Full-Disclosure] M$ - so what should they do?"
• In reply to: Eric Paynter: "RE: [Full-Disclosure] M$ - so what should they do?"
• Next in thread: Valdis.Kletnieks_at_vt.edu: "Re: [Full-Disclosure] M$ - so what should they do?"
• Reply: Valdis.Kletnieks_at_vt.edu: "Re: [Full-Disclosure] M$ - so what should they do?"
• Reply: Eric Paynter: "RE: [Full-Disclosure] M$ - so what should they do?"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]

To: <full-disclosure@lists.netsys.com>
Date: Mon, 21 Jun 2004 18:55:55 -0400

I am not so much in agreement here.

You say you can use any editor to look at the config and you don't need a
proprietary editor. What you mean is you can use any editor that uses the
file system API to open and display the config files. With the registry you
can you use any editor that uses the registry API to open and display the
configurations. 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.

I don't like the idea really of any system that jams all of the stuff in the
same place. You have worries of uniqueness and allowing access to the right
files for the right people. Plus if something happens to that one place be
it the registry or the /etc folder, you have the same resulting issue.

However on the flip side, you do want something that is somehow tied
together so auditing a system (or systems) isn't quite as harsh as scanning
through directory after directory looking for all of the config files.

So what would work. I actually like the idea of breaking everything out into
individual folders, but then you need some centralized registration scheme
so that for security sake, you can quickly ascertain what is going on. Is
the answer some combination of what MS is doing with what is the answer on
*nix? Admins can register something for the whole system, users can only
register things for themselves. The registry simply maintains pointers to
the true registration info held in the folders? 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?

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.

-----Original Message-----
From: full-disclosure-admin@lists.netsys.com
[mailto:full-disclosure-admin@lists.netsys.com] On Behalf Of Eric Paynter
Sent: Monday, June 21, 2004 4:31 PM
To: full-disclosure@lists.netsys.com
Subject: RE: [Full-Disclosure] M$ - so what should they do?

On Mon, June 21, 2004 12:07 pm, joe said:
> For the first one, what do you propose as an answer? Obviously going
> to a bunch of separate text files you have to configure gets away from
> that single point of failure of a single registry but adds all sorts
> of management issues and having to chase all over to gather info about
> what is on your machine. What is the right answer to this one?

Having all the configs as text files in /etc works fine for Unix-like
systems. You can use any editor to look at the config - no need for some
proprietary editor (regedit). Automating config changes is as easy as
writing a simple shell script. Each config is named after its application,
so it's easy to know which is which, and if you need to restore an
application, just install the app then copy your backup config file into
place. As a matter of fact, an entire system can be restored by
re-installing the apps and only restoring /etc (configs) and /home (user
data) from backup. Try that on Windows. Have you ever had a successful
Windows restore without a full system backup or without re-configuring
everything from scratch? It is extremely difficult. Why? Because of the
registry...

The "config file mess" is an excuse made up by MS to sell the registry
concept. The registry does not make it easier to manage application
configuration. Instead, it makes it considerably more complex.

The real reason for the registry is to make it difficult to copy an
application from one machine to another. In other words, it's a copy
proctection scheme. Remember in the days of Win 3.1, you could do that? It
all broke in Win95 with the registry.

-Eric

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html

• Previous message: joe: "RE: [Full-Disclosure] M$ - so what should they do?"
• In reply to: Eric Paynter: "RE: [Full-Disclosure] M$ - so what should they do?"
• Next in thread: Valdis.Kletnieks_at_vt.edu: "Re: [Full-Disclosure] M$ - so what should they do?"
• Reply: Valdis.Kletnieks_at_vt.edu: "Re: [Full-Disclosure] M$ - so what should they do?"
• Reply: Eric Paynter: "RE: [Full-Disclosure] M$ - so what should they do?"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]