Pete Finnigan's Oracle Security Forum


    
      
        Pete Finnigan's Oracle Security Forum
        (http://www.petefinnigan.com/forum/yabb/YaBB.cgi)
      

        Oracle Security >> Oracle Security >> securing database link
        
(Message started by: Pete Finnigan on Nov 27^th, 2008, 3:45pm)

Title: securing database link
Post by Pete Finnigan on Nov 27^th, 2008, 3:45pm

Hi,
I'm stuck with one problem for two days now, and looking for any possible help.
I have two databses, lets call them A and B. A is insecure. There should be a database link beetwen them so that users of database A can acces the information from database B. I would not like to store any passwords to database B in database A. The password should be passed with every single query. Moreover, I can not use the 'current_user authentication' as long as this option assumes usernames and passwords are the same.

Is it possible? If so, can anyone let me know what to do? I would be greatful for any help.

Title: Re: securing database link
Post by Pete Finnigan on Nov 27^th, 2008, 10:19pm

"There should be a database link between them so that users of database A can access the information from database B."
What is the end-to-end situation ? Are they accessing database A directly through SQL or is there an application ? What do you mean when you say that "A is insecure" ?
1) usernames/passwords for database A are well known or easily 'cracked'
2) database accounts in database A are highly privileged (eg SELECT_CATALOG_ROLE, SELECT ANY..).
3) the underlying data files, or backups/extracts, for database A are stored in an easily accessible location

The first option is to drive from the secure database B to the less secure database.

Alternatively, since database A can't be trusted, I'd look at an application that supports concurrent connections to different databases. The application would have to 'simulate' joins between database objects on the different databases.

The only alternative I can think of is some web service style connection with userid and passwords as parameters. While the userids/passwords aren't stored in datafiles (which would address item 3 above), in 11g some bind variable information is exposed in v$sql so passwords passed in as bind variables may not be secure (and they are less secure if exposed as literals). Pre-11g, some trace events can expose bind variables too. So it is much less secure in regards to item 2.

Title: Re: securing database link
Post by Pete Finnigan on Dec 2^nd, 2008, 3:39am

Another option is to define the database link, in the insecure database A, with a valid userid/password (for database B).

For example, define a userid in B, such as LIMITED_DBLINK, with limited privileges, preferably, just Create Session and select on a limited set of views.

Define a VPD policy in B which requires the connection of LIMITED_DBLINK to originate from database A. (Perhaps obtain the IP_ADDRESS via SYS_CONTEXT.)

But if your database A is insecure, then perhaps the IP_ADDRESS could be hacked. (Not my area of expertise). It depends upon your level of tolerance. If this solution sounds like too much risk, then Pete's ideas of a push from the secure database is best, or, alternatively, as he suggests, handle the query in a section of application logic which can be trusted with knowledge of B credentials.

Title: Re: securing database link
Post by Pete Finnigan on Dec 18^th, 2008, 12:15pm

Hi,
In the end-to-end situation we have j2ee application which makes transfers between those two databases. What do I mean by saying A is insecure? usernames and passwords are easy to be cracked.

The web service style connection seems to be interesting. Is there any way to parametrize the queries in pre-11g? I mean passing credentials with query.

Title: Re: securing database link
Post by Pete Finnigan on Dec 28^th, 2008, 12:17am

"Is there any way to parametrize the queries in pre-11g? I mean passing credentials with query. "
In theory you can have a PL/SQL function returning a table or collection type, and query it with

"select * from table(func(:user,:pass))"

But complex data types don't work across DB links so I don't think it would help here, and as I mentioned before, bind variables aren't particularly secure.

"In the end-to-end situation we have j2ee application which makes transfers between those two databases. "
I'd have that application make two separate connections, one to each database. Or connect to the more secure and push to the less secure.

What do I mean by saying A is insecure? usernames and passwords are easy to be cracked.

The web service style connection seems to be interesting.