OPS$ accounts are, basically, Oracle's attempt to implement single sign-on.
OPS$ accounts are not a problem, as long as there is no network involved
because your oracle database is as secure as the underlying OS. You can not
have more security. When there is a network involved, everthing is OK as long
as one can totally control it. In other words, no nodes should be addedd to
the network without a knowledge of the DBA. In the era of laptops when anybody
can walk in and plug his laptop in a departmental ethernet segment, this
cannot be controlled. If you add V internet to the equation, situation
becomes even worse.
Single sign-on, on the other hand is not insecure, as long as it is done
properly. There are many single-sign on methods (Kerberos, RADIUS are the
first ones that come to mind) but they all cost money and are usable only with
the advanced security option. Biometrics doesn't yet instill any confidence in
me. Fingerprints (the so called Yakuza method) are not so easy distinguish
among as one would think.
On 2003.06.21 12:04, Arup Nanda wrote:
Hi Pete,
I think you misunderstood. OPS$ accounts are weaker than the regular
accounts; but I maintain that they are not so insecure that they should be
outright banned. My position is they can be created if needed, but the
privileges should be granted judiciously, something that has to be done even
in regular accounts. OPS$ accounts with DBA privs - a big NO NO.
About the project you mentioned where the user admins are not really DBAs
but regular users who create or manage users via Forms - why not create a
procedure under user sys to manage all that and give execute privs to the
users, instead of giving them sweeping privs like DBA? That way your OPS$
accounts are limited to the operations performed by this procedure, but not
anything else.
HTH.
Arup
- Original Message -----
To: "Multiple recipients of list ORACLE-L" <[EMAIL PROTECTED]>
Sent: Saturday, June 21, 2003 5:08 AM
> Hi Arup,
>
> The example was an application i saw recently, the administration was
> application administration via a form that included adding and
> maintaining Oracle users. The people who used it were not DBA's but
> their users had been granted the DBA role.
>
> I think we will have to agree to disagree though that external accounts
> are always going to be weaker than ones with database authentication
> (weak passwords I agree make those easy as well) simply because they
> rely on another system to do the authentication for them and those
> systems have to be trusted.
>
> cheers
>
> Pete
>
> In article <[EMAIL PROTECTED]>, Arup Nanda
> <[EMAIL PROTECTED]> writes
> >Pete,
> >
> >Apprciate your comments. You are right in stating that if the OPS$
accounts
> >have special privs they might be abused. But how it is any different than
> >any other user id with special privileges whose password is not guarded
> >well? The security hole does not come from the fact that
remote_os_authent
> >is true, but due to lax security management. Removing OPS$ accounts will
not
> >help increase the security any more than simply evaluating who has what
> >privileges.
> >
> >Instead of fighting the introduction of ops$ accounts, what I suggested
was
> >to have a safe practice of setting a prefix. Of course, the privileges of
> >such accounts should be carefully monitored and accesses should be
provided
> >to the bare minimum; dba accounts are certainly a big no. In your example
> >you specified, this is rather ridiculous to have a form for a dba user.
Why
> >not use OEM, for free?
> >
> >In my book I have addressed some of these issues and common
misconceptions
> >and tried to separate myths from facts.
> >
> >Thanks.
> >
> >Arup
> >
> >
> >
> >----- Original Message -----
> >To: "Multiple recipients of list ORACLE-L" <[EMAIL PROTECTED]>
> >Sent: Friday, June 20, 2003 6:19 AM
> >
> >
> >> Hi Arup,
> >>
> >> Remote OS authentication whether with OPS$ or not is still a risk. You
> >> are intimating that SYSTEM is the only risky account involved here.
What
> >> if any of the newly created OPS$ accounts have useful privileges. I
have
> >> seen a similar application to the one described recently. There were
> >> forms within the application for administration and user management (in
> >> oracle, not the application) and the users who had access to these were
> >> assigned the DBA role and were of course external accounts.
> >>
> >> I think what you should add to your comment is that the issue is
> >> overrated is that any OPS$ / external accounts should not have any
> >> dangerous privileges granted and certainly not DBA. If you can guess
the
> >> name of an admin account even if its OPS$ then the issue is still
> >> severe.
> >>
> >> cheers
> >>
> >> Pete
> >>
> >> --
> >> Pete Finnigan
> >> email:[EMAIL PROTECTED]
> >> Web site: http://www.petefinnigan.com - Oracle security audit
specialists
> >> Book:Oracle security step-by-step Guide - see http://store.sans.org for
> >details.
> >>
> >> --
> >> Please see the official ORACLE-L FAQ: http://www.orafaq.net
> >> --
> >> Author: Pete Finnigan
> >> INET: [EMAIL PROTECTED]
> >>
> >> 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: [EMAIL PROTECTED] (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
>
> --
> Pete Finnigan
> email:[EMAIL PROTECTED]
> Web site: http://www.petefinnigan.com - Oracle security audit specialists
> Book:Oracle security step-by-step Guide - see http://store.sans.org for
details.
>
> --
> Please see the official ORACLE-L FAQ: http://www.orafaq.net
> --
> Author: Pete Finnigan
> INET: [EMAIL PROTECTED]
>
> 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: [EMAIL PROTECTED] (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: Arup Nanda
INET: [EMAIL PROTECTED]
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: [EMAIL PROTECTED] (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).
--
Mladen Gogala
Oracle DBA
--
Please see the official ORACLE-L FAQ: http://www.orafaq.net
--
Author: Mladen Gogala
INET: [EMAIL PROTECTED]
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: [EMAIL PROTECTED] (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).
Received on Sat Jun 21 2003 - 15:37:29 CDT
