Re: dbaccess Permissions (Summary)

Folks, Given the interest level several people have expressed in this problem (restricting database access to people with application access but who shouldn't have access to the database outside the application), I have incorporated the responses I have received below. Thanks very much to all who replied! In the course of all the replies, I was feeling good about how to resolve this problem until... I got this additional reply from Donald Boothby: [some stuff clipped] -> ->A parting thought: I'd like to underscore a key point which I fear I ->didn't express very well. That is: you may have users that have other ->tools (like dbaccess) that run on PCs that could access (i.e.: delete, ->change, insert to tables in) the databases. This is the Forest and ->Trees, Powerviewer or Infomaker, Q&E, etc...*** -> [some other stuff clipped] Anyway, this opens up to me whole other worlds of possibility when it comes to malicious hacking. Anyone have any additional thoughts on this before I develop additional gray hairs? Summary of reponses to original question: ------------------------------------------------------------------------ Kathy, Don't forget to lock the standard user out of c4gl, r4gl, and esql too! Or see Walt Hultgren's appstart program > 2) Write a set of stored procedures which are executed as dba to grant > and revoke privileges every time a user enters or exits a program. > I really don't think this is a very efficient thing to do and I would > prefer to avoid it This is bad. Couldn't they bang a shell or otherwise get into dbacess while they are in a program that would have granted them permission? I would consider writing a C program "wrapper" program (call it "dbaccess") that calls up the real dbaccess after doing a setuid call to a user that doesn't have any add, update, or delete privledges. This means revoking add, upd, del from "PUBLIC" but granting same to each user (a maintenance headache). Also involves revoking dbaccess permissions from everyone other than the fake user you set up that have no add, upd, del privledge. I did this for my group. -- Colin McGrath Internet: cmm@trac3000.ueci.com Raytheon Engineers & Constructors, Inc. Voice: 215-422-4144 Philadelphia, PA, 19101 FAX: 215-422-1445 <Standard disclaimers apply> ------------------------------------------------------------------------ > > Folks, > > 3) Any other brilliant solutions any of you have come up with and may be > using? > Restricted shell. cheers j. _____________________________________________________________________________ Jack Parker - Hewlett Packard, BSMC Boise, Idaho, USA jparker@hpbs3645.boi.hp.com _____________________________________________________________________________ Here is a fairly painless solution.... change your permissions to only allow group execution, then put only those people who really require direct acces into that group. For all others, hide the execution of this via a small C program that will do a setgid call (to set the effective group id) and then exec the required processes.... this program will then allow you to restrict access, authenticate people...just about anything you want. total time for a reasonable unix programmer....2 hours :-) -- --------------------------------------------------------------------------- Don't you feel more like you do now than you did when you came in? --------------------------------------------------------------------------- Dave Lease dalease@platy.idss.nwa.com 726.2984 (voice) 726.0521 (fax) --------------------------------------------------------------------------- At 11:50 AM 5/23/95, Cathy Kipp wrote: [bunch of original question clipped] > >Potential Solutions: > >1) Change dbaccess permissions from: -rwxr-xr-x informix informix > to: -rwxr-x--- informix infmx_user Cathy - I've done this exact thing, since I do not want anyone other then INFORMIX to use dbaccess, for the same reasons you've stated. I have not encountered any problems with doing this. Jon ================================================================== Jon Vemo Internet: jvemo@cyberspace.com Bothell, WA USA ------------------------------------------------------------------ Watch out for road-kill on the information superhighway....SPLAT!! ================================================================== ------------------------------------------------------------------------ No particular problem with solution 1 at all. If DB-Access were SUID or SGID, then there would, but otherwise, No. Don't forget dbimport, dbexport, dbload, etc. Any other utilities? ISQL? Etc. Alternative solutions would probably still require you to change the permissions on DB-Access (and other to-be-controlled programs), and would interpose a SUID program which would vet whether the user was allowed to run DB-Access and then arrange to start it. This is messier as the SUID program probably has to be SUID root, and is difficult to make secure. Yours, Jonathan Leffler (johnl@informix.com) #include <disclaimer.h> ------------------------------------------------------------------------ We are using a slight variation of solution 1. Only user informix and group informix have execute access. All other users (which is everyone but informix) use an utility developed in-house to read from the database. This utility accepts the SQL statements (from a file or interactively), parses these statements to ensure that only retrieval verbs are being used and runs a C executable (uid bit set to informix) that runs dbaccess against these statements. Raj ------------------------------------------------------------------------ Cathy, While this is not an answer, we've been wrestling with the same problems and have been talking about alternatives. We don't have a solution mapped out yet, or even know if the ideas are workable. But, we have discussed some ideas that may provoke thought. I would be interested in any other replies you may get. Here's some: 1) (Like your #2.) Only the stored procedures are written to do the updates. The users only have read access to the tables and execute access to the stored procedure. The stored procedures can (I understand) have update access to the tables even though the users who execute them don't. Disadvantages: that's a whole lot of stored procedures to write. It also means changing the application(s). Advantages: most security with no holes that we have been able to see. (I've seen a couple of variations of this on the list before.) 2) Have a set of IDs for each user. Example: usr001ro and usr001. When the user signs on the Unix box directly, then a UNIX script executes which changes his userid to a 'read-only' id. When the user signs on using PB or whatever, the script won't execute and the user has update capabilities. The negative to this is the fact that you have to have two IDs for each user. This can be@