Re: Q on restricting connections from some applications

Leopold The Cat <leopold_the_cat@yahoo.com> wrote: >Several times I've seen the request to disallow connections or restrict >connections to read-only based on what host and application the user is >trying to connect from. The typical argument goes like this: > >I've installed this (accounting, whatever) application that both reads and >writes data. Application connects with userid of the user that runs it. I >would not want the users to be able to write the data (or connect at all) >when they are not using this application. There is a driver that allows me >to restrict what the users can do. Why can't yours? > >I would like to understand a bit more about this. The two parameters (in >addition to userid and password) API can get at are computer name (Win32: >GetComputerName() or WS2 gethostname()) and process module names (NT PSAPI >EnumerateProcessModules(), what's on Win95?). It would not be difficult to >call the stored procedure when the connection is established that database >administrator could modify to reject connection or force read uncommitted >transaction level (which would preclude writing to the database in databases >created with log). The price is that, well, stored procedure would have to >be called on every connection attempt. Also, the list of modules is not >indicative. Application that we want to write to the database can be an ASP. >What prevents the user from replacing one ASP with another? > >The alternative is of course to run the application with distinguished >userid. After all, if it needs to store information on what user modified >the record, it can have userid field. Is it a problem? Why? > >If you feel strongly about it or have some ideas/caveats, would you post >them, please? The fundamental problem with having processes identify themselves is that you have to trust the process to identify themselves accurately. However, the chances are that any API you use will allow a program to abuse it and masquerade as a trusted program. Certainly, preventing such masquerades is the hard part of any security system that identifies an application. The most secure way for the DBMS to know that the correct application is be used is to store and run the application itself. This does not translate well in a networked environment, needless to say. So, yes, something should be done to help with this, but really and truly getting the system secure is going to be hard -- especially on a Win95 type system where there is no real trusted kernel, but even Unix wouldn't be much (if at all) better. I'm not certain about NT; it has a real kernel and might be better, but ... All the systems I've ever devised can be abused by a sufficiently knowledgeable user -- and you have to assume that those intent on subverting such security systems are sufficiently knowledgeable. I haven't spent much time working out whether it can be done with some sort of public-key signing of the executable; if the executable has to report on whether it is secure or not, you can probably devise a way to subvert the security system. If the program does not know the secret that is required to be valid, but simply is given a challenge of some sort and has to provide an answer to that challenge based in part on its text, then maybe something can be done. For example, and thinking off the top of my head, maybe the program can be required to produce an MD5 checksum of its executable with the challenge string as some sort of random number which prevents the application from pre-determining what the answer should be, and if the DBMS can compute the same checksum for the executable, then any attempt to cheat would probably be detectable. You then have to worry about the shared libraries that the program is expected to use, as well. That can quickly get unmanageable, even if not intrinsically intractable. It means that any new program would have to be registered with the DBMS by some carefully controlled mechanism. The DBA would have to validate each program that was added. How the DBA ensures there are no backdoors or trojan horses in the code becomes tricky. Hmmm...probably not a practical solution, even though it might, in principle, work. Yours, Jonathan Leffler (jleffler@informix.com) #include <witticism.h> Guardian of DBD::Informix v0.60 (v0.61_02) -- http://www.perl.com/CPAN Informix IDN for D4GL & Linux -- http://www.informix.com/idn