home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / database / oracle / 2620 < prev    next >
Encoding:
Text File  |  1992-12-23  |  4.5 KB  |  129 lines
  1. Newsgroups: comp.databases.oracle
  2. Path: sparky!uunet!munnari.oz.au!yarrina.connect.com.au!cmutual.com.au!aaj
  3. From: aaj@cmutual.com.au (Tony Jambu)
  4. Subject: Re: OPS$LOGIN :security hole?
  5. Message-ID: <1992Dec23.072030.19046@cmutual.com.au>
  6. Keywords: OPS$LOGIN security SQL*Net
  7. Sender: aaj@cmutual.com.au (Tony Jambu)
  8. Organization: Colonial Mutual Group 
  9. References: <1go861INN4hv@rave.larc.nasa.gov> <1992Dec17.003907.26151@pmafire.inel.gov> <1992Dec17.184923.24754@ncsa.uiuc.edu> <1992Dec17.222051.950@pmafire.inel.gov>
  10. Date: Wed, 23 Dec 1992 07:20:30 GMT
  11. Lines: 116
  12.  
  13.  
  14. Quite a lot of discussion have been going on about Oracle's security,
  15. OPS$LOGIN and SQL*Net.  I am in the process of finishing a report for our
  16. Internal Audit Division that explains what the problems are and how to
  17. overcome them.  If you interested in the report, I could post it to in the
  18. New Year.  I do not pretend to know all the answers and could be wrong in
  19. some of my facts.  If so, please correct me but no flames.  In the short
  20. term, this is a summary and it applies to Oracle V6 only!
  21.  
  22.  
  23. I hope the following information will clarify some of the misconceptions about
  24. Oracle security, OPS$LOGIN and SQL*Net eg
  25.  
  26. >The only way the ops$ account works without a password is when you are
  27. >directly logged into the host server at the OS level.  If you connect to
  28. >the host via SQL*Net, the RDBMS will require entry of the password.
  29.  
  30. >I believe what oracle does with the autologin feature is just use the
  31. >current
  32. >user's operating system userid to come up with the ops$user account, then
  33. >automatically log into that account using whatever password you gave it,
  34.  
  35. >What I do is make all accounts autologin, but assign a different password
  36. >for each one and the passwords never change.  No one ever needs to know
  37. >what their password is, and no one can log into anyone else's account
  38. >since they don't know what the oracle password is (unless, of course, they
  39. >know the person's operating system password and log into that).
  40.  
  41. >IN UNIX (sunos4.12) the conventions
  42. >sqlplus /
  43. >sqlplus OPS$user/bogus
  44. >will both work
  45.  
  46. You need to quote the OPS$user/bogus with 'OPS$user/bogus'
  47.  
  48. >The only way the ops$ account works without a password is when you are
  49. >directly logged into the host server at the OS level.  If you connect to
  50. >the host via SQL*Net, the RDBMS will require entry of the password.
  51.  
  52. Not true.  This is probably the case at your site because your DBA has chosen
  53. so.
  54.  
  55.  
  56. Point 1
  57. ------
  58. ANY OPS$LOGIN account can change its oracle password by using the command.
  59.     'grant connect to ops$login identified by password'
  60.  
  61. So no matter what password the DBA gives you, you can always change it.
  62.  
  63. Point 2
  64. ------
  65. 'sqlplus / ' works only is you have an Oracle OPS$LOGIN in the database.
  66.  
  67. Point 3
  68. ------
  69. On UNIX, sqlplus or any Oracle programs for that matter will examine and
  70. use your 'User login name' not the User ID ie UID, for the OPS$LOGIN on the
  71. server where the database your are trying to access resides.  That is,
  72. LOGIN is your Op/Sys Login Name.
  73.  
  74.  
  75. Point 4
  76. ------
  77. It is possible to login across the network using
  78.     'sqlplus /@T:machine:SID'
  79. without specifying a password.
  80.  
  81. To be able to login across the network using ops$login you MUST have an
  82. OPERATING SYSTEM account on the Server and the server database must have an
  83. Oracle OPS$LOGIN user.
  84.  
  85. Point 5
  86. ------
  87. It is possible to shutdown or create havoc on a remote database across the
  88. network using the same principle as above.  What it all boils down to is
  89.     - does the remote server have an op/sys account name the same as the one
  90.       you are using on your local server
  91.     - does the op/sys account belong to the DBA group on the remote server
  92.  
  93.  
  94. So how to you get around
  95. 1.  OPS$login across the network
  96.  
  97.     ANSWER: Start up orasrv with 'opsoff'
  98.  
  99. 2.  Unauthorised DBA access across the net
  100.  
  101.     ANSWER: Start up orasrv with 'opsoff' AND 'dbaoff'
  102.  
  103.  
  104. Point 6
  105. -------
  106. Even with opsoff, you may still use the op$login if you are connecting to a
  107. local database.
  108.  
  109.  
  110.  
  111. The real security issue is not to do with OPS$LOGIN but unauthorised DBA
  112. commands across the network like 'shutdown immediate' and 'connect internal'
  113.  
  114.  
  115. I have validated the above points at my site and it may differ from yours.  If
  116. you find any of the points incorrect please email me .
  117.  
  118.  
  119. thanks
  120. tony
  121.  
  122.  
  123.  
  124. -- 
  125.  _____       ________ / ____ |Tony Jambu, Database Administrator
  126.   /_  __       /_ __ /       |Colonial Mutual Invest Mgmt Aust (ACN 004021809)
  127.  /(_)/ ((_/ \_/(///(/_)/_(   |EMAIL:  TJambu@cmutual.com.au
  128.  \_______/                   |PHONE:  +61-3-6418448       FAX:  +61-3-6076198
  129.