RE: OEM permissions

You could use protocol.ora to specify which machines are allowed to make a connection to the database.

In some environments this would be fairly painless.

SAP for example. The users do not connect to the database, they connect to the app server. The number of machines that legitimately require a connection to the database could be very limited.

This would reduce the possibility of someone sneaking in through a database link.

Jared

On Sat, 2003-12-20 at 12:29, Yong Huang wrote:
> Hi,
>
> I think you're describing a real security hole. But I'm not sure how it's
> exploited exactly. Let's say John Doe sets up his database on his desktop,
> which is part of the production database network. He sees the hash value of
> SYSTEM's password on production and sets the hash value for his own SYSTEM user
> to be the same. Since now he doesn't know the clear text password for SYSTEM
> (Pete Finnigan may know how to find it, though), he can't easily create a
> private database link owned by SYSTEM. He can still create a public link, or a
> private link owned by somebody else, his SYS user e.g. Then what?
>
> (He can still create a link owned by SYSTEM from another account such as SYS
> using a little bit hacking. But he won't know SYSTEM's password. I don't know
> how security of the production database is compromised in any way)
>
> Yong Huang
>
> you wrote:
>
> Maybe I'm a being a bit touchy here; but it seems that my comments about
> having access to dba_users went completely unnoticed. Let's put it this
> way: There is NO WAY you can prevent somebody from setting up their own
> private oracle instance. It they have access to dba_users in your database,
> they can create the SAME users with the SAME passwords in their private
> database. And they can create database links in their private database.
>
> Now, is this a problem?
>
> __________________________________
> Do you Yahoo!?
> New Yahoo! Photos - easier uploading and sharing.
> http://photos.yahoo.com/
> --
> Please see the official ORACLE-L FAQ: http://www.orafaq.net
> --
> Author: Yong Huang
> INET: yong321_at_yahoo.com
>
> Fat City Network Services -- 858-538-5051 http://www.fatcity.com
> San Diego, California -- Mailing list and web hosting services
> ---------------------------------------------------------------------
> To REMOVE yourself from this mailing list, send an E-Mail message
> to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
> the message BODY, include a line containing: UNSUB ORACLE-L
> (or the name of mailing list you want to be removed from). You may
> also send the HELP command for other information (like subscribing).

-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.net
-- 
Author: Jared Still
  INET: jkstill_at_cybcon.com

Fat City Network Services    -- 858-538-5051 http://www.fatcity.com
San Diego, California        -- Mailing list and web hosting services
---------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from).  You may
also send the HELP command for other information (like subscribing).