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