This is the mail archive of the
mailing list for the cygwin project.
RE: AllVersions: Running Cygwin X w/ Registy Entries
- From: "Dave Korn" <dave dot korn at artimi dot com>
- To: "'take it to the talk list'" <cygwin-talk at cygwin dot com>
- Date: Thu, 27 Oct 2005 14:29:56 +0100
- Subject: RE: AllVersions: Running Cygwin X w/ Registy Entries
- Reply-to: The Cygwin-Talk Malingering List <cygwin-talk at cygwin dot com>
[ Thread TITTTL'd. Bock-bock! ]
Brian Dessent wrote:
> Chris Taylor wrote:
>> When I say editing the registry, I'm talking about the ability to
>> directly manipulate it with .reg files, regedit, or other registry
>> editing tools.
> You can block access to certain known tools like regedit. This does
> *nothing* to block access to the registry itself, except for amateur
> users that think regedit is the only way to access the registry.
> Registry keys are full NT objects each with their own ACL, and so if you
> *really* want to prevent someone from being able to edit the registry,
> this is the *only* way. And doing so breaks lots of programs that
> expect to be able to store their settings in HKCU.
Not necessarily "breaks" at all. Most stuff works fine, but of course won't
remember any *changes* you make to the settings, won't update MRU lists, etc.
After all, the sterotypical paradigm for using the registry is:
- Program startup: read all settings from registry key.
- Operation: do stuff, repecting settings. allow user to change settings.
- Shutdown time: Write update settings back to registry key.
The first two stages will still work fine, and most apps will silently
ignore 'Can't write' errors when they're terminating anyway.
BTW, if you've ever had the state of shown/collapsed programs on your start
menu 'just so', and wanted it to stay that way, and known that it'll get
messed up when you start to use other apps, setting your UserAssist key to
read-only is a handy trick to know!
> The point here is that regedit is only *one* way of arbitrarily
> manipulating the registry, and a user that knows what he's doing will
> *always* be able to get around this. Disabling regedit is *not* a form
> of security, unless you define security as "keeping out casual users but
> nothing else."
You're confusing "security" and "reliability" here. Disabling regedit isn't
about security, it's about keeping systems maintainable and reliable by
preventing casual experimentation (aka 'tampering'!)
>> Yes, you are able to make changes to HKCU, but not *directly*.
> echo "1" > /proc/registry/HKEY_CURRENT_USER/Software/Foobar
> Oh look, I just edited the registry directly. Okay, so you don't allow
> Cygwin. So I compile a C program that takes a key+value on the command
> line and calls RegSetValueEx(). Oh, so you disallow that filename or
> checksum. So I make a different C program and call it something else.
> There are an infinite number of programs that I can write and it's
> impossible to block them all.
... although intercepting the NTApi calls with a kernel-mode driver is a
pretty good start ...
>> Using a command that alters the registry as part of it's function, but
>> does not allow the user to directly alter it is a very different
>> ballgame. mount would be permissable. Some console app to directly edit
>> the registry would not be.
> There is absolutely no way for a sysadmin to block one and not the
The point of the above paragraph is that there's no need to block both,
since the "command that alters the registry as part of it's function, but does
not allow the user to directly alter it" is very strictly circumscribed in
what changes it will make and where, and therefore more predictable and
controllable, than allowing them free rein with regedit.
Can't think of a witty .sigline today....