home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #3 / NN_1993_3.iso / spool / comp / os / vms / 21661 < prev    next >
Encoding:
Internet Message Format  |  1993-01-21  |  3.9 KB

  1. Path: sparky!uunet!cs.utexas.edu!uwm.edu!linac!att!ucbvax!lrw.com!leichter
  2. From: leichter@lrw.com (Jerry Leichter)
  3. Newsgroups: comp.os.vms
  4. Subject: re: SYSUAF.DAT access - the real world
  5. Message-ID: <9301202243.AA01736@uu3.psi.com>
  6. Date: 20 Jan 93 21:28:13 GMT
  7. Sender: daemon@ucbvax.BERKELEY.EDU
  8. Distribution: world
  9. Organization: The Internet
  10. Lines: 62
  11.  
  12. Philip Perucci wrote that he needed to be able to provide access to SYSUAF.DAT
  13. to someone working for the company comptroller.  A number of people have taken
  14. the opportunity to use this as an example of the stupidity of management, and
  15. to say that there is basically no way to do this without giving that person
  16. at least the ability to get any rights he likes.
  17.  
  18. INFO-VAX subscribers (including some whose postings I generally respect) once
  19. again again reveal their narrowness of vision and understanding of the real
  20. world.  Look, a VAX is not a toy.  It can be a substantial investment, and
  21. USE of it may represent real money.
  22.  
  23. A BASIC rule of handling money is never to give one person complete control.
  24. That's why you pay one person for your movie ticket, then hand the ticket to
  25. a second person.  (Otherwise, how's anyone to know that the person at the
  26. ticket window isn't pocketing some fraction of the take and just letting
  27. people through?)
  28.  
  29. It is perfectly legitimate for the comptroller of a corporation to wish to be
  30. in a position to audit use of a corporate resource.  It is unacceptable if the
  31. only way to audit usafe of a resource is through the direct intervention of a
  32. person in a perfect position to misuse the resource.  If you have to ask the
  33. system manager to prepare reports on system usage, and he is the one who is
  34. stealing, what do you think the chances are that the reports will give him
  35. away?
  36.  
  37. Don't respond by saying that you have to have confidence in your system
  38. manager.  That's true - but why do you think con men - short for confidence
  39. men - are called that?  They are the people who no one suspects, who everyone
  40. identifies as the nicest, friendliest, most trustworthy people in the organi-
  41. zation.
  42.  
  43. In the IBM world, system management responsibilities can be subdivided.  In
  44. organizations that worry about this kind of thing, a common rule is that the
  45. person who has the ability to create accounts on a system is never allowed to
  46. use that system for anything else.  The most closely monitored function in a
  47. payroll organization is the creation of new payroll accounts.
  48.  
  49. VMS is actually not particularly good in this kind of "large system/large
  50. money" world.  However, it's moving in that direction.  That's why there's a
  51. separate SECURITY privilege:  The security officer and the system manager in
  52. a high-security shop are different people, and the former has SECURITY and
  53. few other privileges, while the latter has all sorts of privileges, but not
  54. SECURITY.  While with CMKRNL you can do anything, given enough effort, VMS is
  55. deliberately designed so that it's difficult to do security-related things
  56. without leaving a trail.
  57.  
  58. In Mr. Perucci's position, the ideal would be to be able to give the auditor
  59. read-only access to the SYSUAF.  Unfortunately, AUTHORIZE demands WRITE
  60. access.  I consider this a serious limitation, since it makes it unnecessarily
  61. more difficult to implement an "outside auditor" facility.  One way to do this
  62. would be to give the auditor just read access and have him copy the live
  63. SYSUAF.DAT to a private file, which he could then modify to his heart's
  64. content without damaging anything.  Another approach is to trust the auditor
  65. not to do anything stupid - but have someone else check the audit logs for any
  66. changes he might make to the SYSUAF.  (Again, make sure two people have to
  67. work together to subvert the system.)
  68.  
  69. Of course, with the listings it should be simple to patch AUTHORIZE NOT to
  70. demand write access - just pull out the explicit check.  If it keels over when
  71. someone tries to write to the file, well, big deal.
  72.                             -- Jerry
  73.  
  74.