Database Security

Forwarded message: > From informix-list-owner%rmy.emory.edu@rmy.rmy.emory.edu Wed Oct 16 20:37:09 1991 > Date: Wed, 16 Oct 91 18:00:12 -0400 > From: Walt Hultgren {rmy} <walt@mathcs.emory.edu> > Message-Id: <9110162200.AA19563@emory.mathcs.emory.edu> > To: informix-news-gate@rmy > Subject: Informix database security > X-Informix-List-Id: <newsgate.369> > > Path: emory!swrinde!cs.utexas.edu!uunet!iWarp.intel.com|ogicse!psgrain!m2xenix!quagga!ucthpx!oct1!aim1!chan > >From: chan@aim1.UUCP (Neville Chamberlain) > Newsgroups: comp.databases,comp.databases.informix > Keywords: database security informix > Message-ID: <53@aim1.UUCP> > Date: 15 Oct 91 05:39:11 GMT > Organization: Aztec Information Management > > Here's an interesting scenario: A retail chain are installing > a number of Unix systems at their branches to handle point of > sale, ordering, etc. Among other things, the systems will > contain confidential information relating to each branch, e.g. > personnel info. This info has to be kept private and access > limited to only selected persons. > > The database system being used is Informix with the standard > engine; applications have been developed using 4GL. The problem > with security is that the chain has to give one person at each > branch root access to the system in case the network/modem > support lines fail; this person will obviously have permission > to do almost anything on the system. I do not think the chain > are too worried about the persons with root access; but others > might get hold of the root password and, if they can get hold > of the relevant info, use it for their own nefarious purposes. > > THUS: How to protect the confidential information on the systems? > > The following suggestions have been made: > > a) Enforce strict security and auditing on the systems. This will > warn of unauthorised accesses, file opens, etc. Nice but always > too late. > > b) Modify all reads and writes to the relevant tables to encrypt and > decrypt the data before it is written/after it is read. Means > that the application programs (already in existence) have to > be modified. > > c) Ignore the problem. The people at the branch outlets are not > programmers or Unix experts, either of which is required to > get to the data. > > d) Encrypt/decrypt the relevant tables after and before use. This > means that while certain applications are running, the info > is "freely" available. > > e) Combinations of the above. > > Any help/suggestions appreciated! I will summarise if there is > enough interest. > > -- > ............................................................. > Neville Chamberlain :Tel: +27 (21) 419-2690 > Aztec Information Management :Fax: +27 (21) 21-1040 > chan@aim1.UUCP > Neville - If the need for local root access is for a specific, limited purpose, it may be possible to provide a limited form of root access that only allows the specific activities that are required, thus eliminating the threat to database security. I have seen this done successfully on several different systems, using the following schemes: 1. "sudo" command - this is a special form of su that allows only commands from a special list to be executed 2. keeping a second root login (with a different password), and revealing the password (in this case by telephone) only when it is required - then changing the password as soon as it is no longer required this will severely limit the time window for unauthorized access (although an invdividual with sufficient expertise can gain permenant, unauthorized root access given just a few moments of authorized root access) 3. write a program to do the special task, give it root ownership, and set UID to root as required (as some of the Informix executables do) 4. I haven't tried it, but you might be able to set up an alternate root login that gets a restricted shell ------------ DHL WORLDWIDE EXPRESS ------------------------------------------- Greg Bryan gbryan@ssf-sys.dhl.com DHL Systems Data Administrator uunet!ssf-sys.dhl.com!gbryan San Francisco -------------------------------------------------------------------------------