Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com Message-ID: <4360A973.168A2014@dessent.net> Date: Thu, 27 Oct 2005 03:18:27 -0700 From: Brian Dessent MIME-Version: 1.0 To: cygwin AT cygwin DOT com Subject: Re: AllVersions: Running Cygwin X w/ Registy Entries References: <1130262948 DOT 435e71a4abd76 AT webmail DOT mail DOT gatech DOT edu> <1130283941 DOT 435ec3a5672f2 AT webmail DOT mail DOT gatech DOT edu> <4kmnzwxkibr0.1rd655owgqdi6$.dlg AT 40tude DOT net> <20051026143731 DOT GA1936 AT trixie DOT casa DOT cgf DOT cx> <1g329hewnak2$.1knc01godo1ld DOT dlg AT 40tude DOT net> <435FB109 DOT 30506 AT equate DOT dyndns DOT org> <4360A2BA DOT 8070704 AT equate DOT dyndns DOT org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Reply-To: cygwin AT cygwin DOT com 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. I suppose you could allow specific write access to those keys that known programs need to access, and deny everything else. But that would be an enormous amount of work, and by the time you're done you'd have granted access to a large portion of HKCU. 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." > 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. The point here is that there is no such thing as "blocking direct access" while still "letting some programs write to the registry." Either it's writeable or it's not. If it is, then the user can make arbitrary changes. There's no middle ground. > Your method is flawed and destroys the existing setup, which is bad. > I disable ALL aspects of regedit and other tools, and I know I'm not > alone in this. It's perfectly normal and *common* to do it. You can disable every piece of software that has ever existed in the known universe, and I will still be able to make arbitrary registry changes if I want -- provided that the desired HKCU key is writeable. > The (l)user should *never* be allowed to edit the registry themselves. > That's a recipe for disaster. If you think it is possible to block "direct" editing of the registry while still allowing HKCU to be writeable, then you are clearly mistaken at how windows security works. > 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 other. Brian -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/