Re: How to keep "root" out?

Hi!

> I have an idea
>
> 1. Use let say My_Tursted_SA schema, write a trigger that will disconnect
new login as SYS or SYSTEM

How exactly are you planning to disconnect the login? You can't kill your own session, there's no disconnect or exit command in pl/sql. Only way I know is to generate an unhandled exception which doesn't allow to log on (or use an external library to kill your own server process from OS level, but this gets unnecessarily complicated).

> 2. If you want to use sys or system, you login as My_Trusted_SA disable
the trigger.

Sys & system do have the administer database trigger privilege, thus they can log on even if the logon trigger fires an unhandled exception.

Cheers,
Tanel.

>
> What do you think?
>
>
> Sinardy
>
> -----Original Message-----
> Richard Ji
> Sent: 31 August 2003 13:39
> To: Multiple recipients of list ORACLE-L
>
>
> A strange loop eh? You must have read GEB. :)
>
>
> -----Original Message-----
> From: Tim Gorman [mailto:tim_at_sagelogix.com]
> Sent: Sat 8/30/2003 12:49 AM
> To: Multiple recipients of list ORACLE-L
> Cc:
> Subject: Re: How to keep "root" out?
> Ahhhhhhhhhhhh...
>
> But if you encrypt it, where do you keep the key? How do you retrieve it
> for use? Donıt forget to follow the problem to the next step...
>
> ...and when you do, you realize that if nobody can be trusted, then the
> problem of security becomes an Escher print, or a Mobius strip, or the
> infinity symbol, or the exact value of ³pi²...
>
>
>
> on 8/29/03 9:29 AM, Richard Ji at Richard.Ji_at_ztango.com wrote:
>
> > We assume the SA don't know much about Oracle. But if some one is
> > particularly interested in
> > getting into the database, he might be on this list as well learning all
our
> > defense mechanisms. :)
> > Or doesn't have to be subscribed to it since this list is mirrored other
> > places and google is his friend.
> > I think the bottom line is, if you absolutely don't want the data to be
seen,
> > encrypt it.
> >
> > My 2 cents.
> >
> > Richard Ji
> >> -----Original Message-----
> >> From: Mercadante, Thomas F [mailto:NDATFM_at_labor.state.ny.us]
> >> Sent: Friday, August 29, 2003 10:31 AM
> >> To: Multiple recipients of list ORACLE-L
> >> Subject: RE: How to keep "root" out?
> >>
> > Walt,
> >
> > Something that has not been suggested - migrate your database to 9.2.
Connect
> > as internal goes away.
> >
> > Other than that, I think the best suggestion you got was a conversation,
and
> > granting access to the v$ tables thru a specific account for that
person.
> >
> > And then put a long trigger in place tracking all connections to the
database.
> > Keep track of all SYS connections. At least you know when things
happen. And
> > periodically review the init.ora file for the database to make sure that
> > nobody changes anything.
> >
> > Good Luck!
> >
> > Tom Mercadante
> > Oracle Certified Professional
> >>
> >> -----Original Message-----
> >> From: Jared.Still_at_radisys.com [mailto:Jared.Still_at_radisys.com]
> >> Sent: Thursday, August 28, 2003 4:50 PM
> >> To: Multiple recipients of list ORACLE-L
> >> Subject: Re: How to keep "root" out?
> >>
> >>
> >> But someone determined to get in the database can simply edit
sqlnet.ora
> >>
> >>
> >>
> >> "Tanel Poder" <tanel.poder.003_at_mail.ee>
> >> Sent by: ml-errors_at_fatcity.com 08/28/2003 10:24 AM
> >> Please respond to ORACLE-L
> >>
> >> To: Multiple recipients of list ORACLE-L
> >> <ORACLE-L_at_fatcity.com>
> >> cc:
> >> Subject: Re: How to keep "root" out?
> >>
> >>
> >> Hi!
> >>
> >> Put sqlnet.authentication_services = none in your server's sqlnet.ora.
Then
> >> everyone has to use a password.
> >>
> >> Tanel.
> >>
> >> ----- Original Message -----
> >> From: Walter K <mailto:ora1034_at_sbcglobal.net>
> >> To: Multiple recipients of list ORACLE-L <mailto:ORACLE-L_at_fatcity.com>
> >> Sent: Thursday, August 28, 2003 6:34 PM
> >> Subject: How to keep "root" out?
> >>
> >> Just for grins, I'll ask this question... Is there any way to keep the
Unix
> >> "root" user from logging into the database (i.e. connect internal or /
as
> >> sysdba)? Currently using 8.1.7.4 on Solaris 8 here.
> >>
> >> We have a couple people in our Unix admin group that feel the need to
"help"
> >> by writing their own DB monitoring scripts. Of course, they don't know
what
> >> they're talking about. They do not have formal logins for the database,
but
> >> since they are root users they are connecting via "connect internal".
This is
> >> not only counterproductive but actually a potential security
issue--just
> >> because someone has root doesn't necessarily entitle them to see the
data in
> >> the database. What if it is a payroll database?
> >>
> >> So, I'm curious, is there any way to prevent access via "connect
internal" or
> >> "/ as sysdba"?
> >>
> >> Thanks in advance.
> >>
> >> W
> >>
> >
>
>
>
> --
> Please see the official ORACLE-L FAQ: http://www.orafaq.net
> --
> Author: Sinardy Xing
> INET: SinardyXing_at_bkgcomsvc.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: Tanel Poder
  INET: tanel.poder.003_at_mail.ee

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).