Q on restricting connections from some applications

Folks, 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? Thanks, Leopold

In article <7o50ou$msi1@webint.na.informix.com>, "Leopold The Cat" <leopold_the_cat@yahoo.com> wrote: > Folks, > > 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? > > Thanks, > Leopold > > Leopold I contributed to an earlier discussion regarding the above. We have a third party application to which the user connects via a shared memory connection with a unique UNIX userid. In order for the application to succeed, all users need all permissions to all tables. Given that the user knows his UNIX userid and password, there is nothing we can do to prevent him obtaining an ODBC driver then use his MS Office applications (corporate standard) to execute an SQL statement such as "delete from <tablename>". Therein is our problem. We believe what we need is the ability to detect that a database call has come from ODBC - this would at least be a start. Forgive me if I have misunderstood, but I don't believe your solution above (elegant though it is!) would help us. Regards Glyn Balmer -- If it always works, why don't parachutists pull the emergency 'chute first? Sent via Deja.com http://www.deja.com/ Share what you know. Learn what you don't.

[ posted and mailed ] Leopold The Cat 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? That's a question I've asked numerous times. An additional problem I have with I-NET's approach to user identification and -validation is that you need a valid system account to connect to the database (so there is no such thing as database-only access) and that the .rhosts mechanism (or, even worse, /etc/hosts.equiv) is used to validate access rights over the net. This is something that is definitely worse than what the O-word has to offer. The gaping security hole in this approach is two-fold: The users have a login and password that should normally take them into the application only and not give them shell access. Well, shit happens, and a user may willingly or unwillingly suddenly find himself in the shell where he could cause harm. Even worse, anybody can install an ODBC driver on any machine in the network he has access to and then use the login and password he knows to gain read/write access to the database and wreak havoc. This gives me the creeps! Of course, the newer versions of the database and frontend tools offer methods to alleviate these security problems: The CONNECT statement and the use of ROLES. However, we have quite a few legacy applications that cannot make use of these features without some code modification and recompilation, and we have a manpower problem. So if there were a way to better control access on the database server itself, I would certainly be a lot happier as system and db administrator. Regards, Richard -- +--------------------------+------------------------------------------+ | Dr. Richard Spitz | INTERNET: spitz@ana.med.uni-muenchen.de | | EDV-Gruppe Anaesthesie | Tel : +49-89-7095-6110 | | Klinikum Grosshadern | FAX : +49-89-7095-6420 <-- NEW!!! | | 81366 Munich, Germany | GSM : +49-172-8933578 | +--------------------------+------------------------------------------+