Issues in Informix

I need to implement some aspects related to security in a database Informix: I have no experience in Informix so is more complicated, and I have several issues: ' The default permission were changed to 777 or 755 in some files of the following dirs /informix, /informix/bin, /informix/etc, so it's too risky.I need the default installation permissions. Where can I get a list of them???? ' Is it possible to create a Script in order to verify informix tables and databases permissions??? ' And I finally I need to restrict access application through ODBC's to a DB. For example I do not want to allow connections from excel or lotus to my DB, I only want to allow connections from one specific application. Is it this possible??? Is there any solution for this purpose??? Thanks in advance Dave

David Mendez wrote: > I need to implement some aspects related to security in a database > Informix: I have no experience in Informix so is more complicated, and I > have several issues: > > ' The default permission were changed to 777 or 755 in some files of the > following dirs /informix, /informix/bin, /informix/etc, so it's too > risky.I need the default installation permissions. Where can I get a > list of them???? $INFORMIXDIR/etc/*files > ' Is it possible to create a Script in order to verify informix tables > and databases permissions??? Answer 1: Yes, see the examples in the IIUG Software Archive (utils_jl - ixchkperm, ixsetperm). Answer 2: On rereading before sending, I think Answer 1 is for a different question - it checks the permissions for files in $INFORMIXDIR. Are you using SE? Or OnLine/IDS/XPS? What do you mean by verifying database and table permissions? In SE, the database directories should be owned by the creator of the database, should belong to group informix, and should have 770 permissions. The files in the database should be owned by the table creator, belong to group informix, and should have 660 permissions. In IDS, the chunks for the dbspaces should be owned by user informix and group informix with 660 permissions. Or do you mean verifying the permissions granted within the database - the series of granted permissions so that you can tell which tables a certain user is allowed to select, insert, delete, update, etc? That's a somewhat intricate query, but fundamentally, you interrogate the systabauth and syscolauth tables in the system catalog, bearing in mind such trickinesses as public permissions and role permissions (and the permissions for roles granted to roles) -- information from sysusers and sysroleauth. > ' And I finally I need to restrict access application through ODBC's to > a DB. For example I do not want to allow connections from excel or lotus > to my DB, I only want to allow connections from one specific > application. Is it this possible??? Is there any solution for this > purpose??? Two nice easy questions - then a real googly (curve ball for those more familiar with baseball than cricket) *** This is one of the hardest issues to deal with. The short answer is No. And, to misquote myself from other questions in times past, the long answer goes through a lot of rambling and ends up with the answer No too. Informix uses the (claimed) user ID and possibly password to control whether you can access the database, and makes no distinction between the different programs that can be used to access the database. In particular, it treats DB-Access the same as any other more controlled program. So, if the user can delete rows from the table using an application, the user can also delete rows from the table using DB-Access. This is a problem. There are no easy solutions; I'm not even wholly convinced there are any hard solutions to the problem. You can raise the bar, but I haven't found any way to make the bar unjumpable by the suitably determined. One way of raising the bar is to have the controlled applications connect to the database using some username such as UserB which is not related to the user's login name, UserA. You grant the privileged user, UserB, the permissions necessary to do the job; you grant the unprivileged user, UserA, the bare minimum permissions you are prepared to tolerate -- or even no permission at all. This then means that to violate the system, UserA has to find out which username is used when connecting to the database (ie, UserB) and the associated password. Depending on the controls placed on the client environment, this might be more or less difficult. One suggested solution is to have the database identify which program it is that is accessing the database, but the problem there is how to ensure that it gets the correct information. Given a development kit (CSDK) and a compiler, how do you prevent the unscrupulous programmer from writing ProgramA that lets the user do anything while claiming to be ProgramB, a strictly controlled program? The only way I think that this can be done rigorously is if the database stores the program, and controls who can store programs, and it can then validate things -- the client side would send a request to run AppA on behalf of the user, and the database would then extract and verify AppA and run it on behalf of the user. The trouble is, applications tend to need to talk to the user -- and the mechanisms for handling that are tricky, at best. Additionally, this isn't how it is designed at the moment. There's still an authentication problem, but that is more soluble -- amongst other systems, Kerberos could be used. Even then, there is a risk that the authentication has not identified the correct user -- a shared password for a single login is the simple Unix equivalent. The computer(s) only know that someone who was able to produce the correct credentials associated with UserA has asked to be authenticated as UserA; that isn't the same as saying it is UserA who was authenticated. Even biometrics can't be made wholly reliable if the person attacking has enough access to the system (did they manage to intercept the communications between the thumbprint reader and the system at some time - etc). These issues affect any system I'm aware; not just Informix. So, as I said a long time ago, the answer is, IMO, No. I'd be happy to hear from anyone who has a valid solution to this problem. *** Just occasionally, the Meriam-Webster online dictionary reveals its American roots - it has no clue about a googly (though the print version of Webster's Collegiate Dictionary has it). The Chambers Dictionary online version knows about it. It is nothing whatsoever to do with a certain search engine, either, though said search engine also comes up with the right answer in the number 2 spot! http://www.m-w.com http://www.chambersharrap.co.uk/chambers/chref/chref.py/main http://www.google.com -- Jonathan Leffler #include <disclaimer.h> Email: jleffler@earthlink.net, jleffler@us.ibm.com Guardian of DBD::Informix v2003.04 -- http://dbi.perl.org/