Re: Client/Server ORACLE 6 security issues

In article <05APR93.18755956.0053_at_UNBVM1.CSD.UNB.CA> "Andrew Jones (lrpr_at_unb.ca)" <LRPR_at_UNB.CA> writes:
> Hello! I am currently in the design stages of a project using
>ORACLE version 6 RDBMS and SQL*net V6.0.36.1.1 to have DOS 5.0 PC's
>do client access (using ORACLE DOS tools) to the database server on a
>UNISYS U6000/65 (SVR4) box. The problem is one of security. We'll have
>DCA/RLN (Remote Lan Node) access for dial-up customers, who'll be querying
>the DB. There will be ORACLE permit security which will prevent users
>from doing unauthorized things like deleting from tables they shouldn't.
>However, there will also be things which would be easily handled with
>stored procedures and triggers (like: update this table with a charge record
>whenever that table is selected from) which can only (I believe) be done
>in ORACLE 6 via the application logic. What scares me is a user who fires
>up SQL*Plus as a DOS tool and then connects to the DB; since they don't
>really log on to UNIX there's no UNIX security, and the database making
>a SQL*net connection can't tell if it's an application or an interactive
>interface connected to it. Thus, they might do things which the application
>must be able to (like insert rows in a table) without the application-based
>integrity constraints. The best thing I can think of so far is to have them
>enter an application password, which is decrypted by a C program; it would
>then connect to a the database with a password which never appears as a file
>on the PC. However, a good hacker could dissassemble the encryption
>algorithm, leaving me exposed. Anybody have an experience with this?
>
>Thanks in advance!
>
>Andrew Jones,
>New Brunswick Geographic Information Corporation,
>Fredericton, New Brunswick, Canada
>E-mail: LRPR _at_ UNB.CA
>

You can put entries in the product_user_profile table that will prevent users from issuing unwanted SQL statements from SQL*Plus on any client. You can use this to disable the DELETE and UPDATE SQL statements, for example, from a certain group of SQL*Plus users, though they can still use the commands from SQL*Forms.

This will not stop the sophisticated user from firing up some other tool or C program that talks to Oracle and issues integrity-busting statements - You'll need to upgrade to Oracle7, which is available on your platform, to control this.

• Dan

Daniel Druker
Anderson Graduate School of Management at UCLA                    

| Dan Druker                                                               |
| agsm mail 	: ddruker                                                  |
| internet 	: ddruker_at_agsm.ucla.edu                                    |
| oracle*mail	: unix:ddruker_at_agsm.ucla.edu                               |
----------------------------------------------------------------------------

Disclaimer: None. I'm a student now and I don't care what you think. Received on Tue Apr 06 1993 - 07:06:07 CEST