From orarup@hotmail.com Sat, 21 Jun 2003 12:36:29 -0700 From: "Arup Nanda" Date: Sat, 21 Jun 2003 12:36:29 -0700 Subject: Re: oracle authentication from windows Message-ID: MIME-Version: 1.0 Content-Type: text/plain 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).