home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / admin / policy / 969 < prev    next >
Encoding:
Text File  |  1992-08-27  |  5.3 KB  |  122 lines

  1. Newsgroups: comp.admin.policy
  2. Path: sparky!uunet!gatech!ukma!morgan
  3. From: morgan@ms.uky.edu (Wes Morgan)
  4. Subject: Policy regarding Crack
  5. References: <9208271530.AA15830@herodotus.cs.uiuc.edu>
  6. Message-ID: <1992Aug27.143847.5244@ms.uky.edu>
  7. Date: Thu, 27 Aug 1992 18:38:47 GMT
  8. Organization: The Puzzle Palace, UKentucky
  9. Lines: 111
  10.  
  11. From: S_TITZ@iravcl.ira.uka.de (Olaf Titz)
  12. >In <1992Aug26.174017.1077@ms.uky.edu> morgan@ms.uky.edu writes:
  13. >
  14. >>      - I could write an automated shell script that examines every
  15. >>        text file on the system, reporting the names of any files which
  16. >>        are in /etc/passwd format (i.e. Crack food).  This borders on the 
  17. >>        unacceptable.
  18. >
  19. >It *is* unacceptable, IMHO - the same thing of searching user files.
  20. >
  21.  
  22. This approach borders on acceptability for one reason only -- I'm not
  23. looking at the files myself.  If such a script reports that "file
  24. /users/booga/foo/blast is in /etc/passwd format", I would simply dis-
  25. cuss the matter with the owner of the file.  I don't examine user files.
  26.  
  27. Besides, I don't believe that the /etc/passwd format is widely used in
  28. other applications.......8)
  29.  
  30. >>  OR.......
  31. >>  
  32. >>      - I can set a simple policy that says "this system is not to be used
  33. >>        for the development or use of password cracking software".  My users
  34. >>        are Engineering students; they have no curricular need to develop
  35. >>        such software on our systems.  
  36. >>  
  37. >>        This approach benefits everyone (in theory).  The users don't have
  38. >>        to worry about admins (or Crack users) rooting through their files, 
  39. >>        and I don't have to worry about Crack fanciers.......
  40. >
  41. >Are you sure that setting a policy will *prevent* your system from
  42. >being Crack'ed? ;;-)
  43.  
  44. I never said that such a policy would prevent it!  However, such cracking
  45. would be a more remote possibility.  8)  I'm also concerned about users
  46. collecting password files from all over and using my box as their password
  47. cruncher.......
  48.  
  49. >>  Computing resources are usually assigned/allocated within this framework.
  50. >>  However, assignments/allocations of these resources for purposes outside
  51. >>  of the framework can (and should) be limited.  A Mechanical Engineering 
  52. >>  student may wish to write a Japanese text parser; while that is a laudable
  53. >>  project, can we justify the allocation of Engineering resources to that
  54. >>  goal?  
  55. >>  
  56. >>  "Academic freedom" is not equivalent to "a blank check".
  57. >
  58. >Right, but... be VERY careful about that.
  59. >
  60. >The step from your Japanese parser to general restrictions like 'we
  61. >don't carry alt* and rec* newsgroups' is dangerously short. 
  62.  
  63. Excuse me, but the two concepts are NOT as similar as you claim them to be.  
  64. In my example, I suggest a policy that would prevent the use of a 
  65. particular facility by an individual user (namely, the future use of 
  66. my system for cracking programs).  Your counter-example, the revocation 
  67. of alt.* and rec.* newsgroup access, suggests the revocation of current 
  68. use by all users.  The two cases are markedly different; you're comparing 
  69. apples and oranges.
  70.  
  71. >Take
  72. >another example: When I want books from my university library, nobody
  73. >cares about the importance of, say, a book on music history for my
  74. >computer science studies. 
  75.  
  76. This example is irrelevant.  The university libraries are, by definition,
  77. open to all students of the University.  My systems, on the other hand,
  78. are open only to Engineering students/faculty/staff.
  79.  
  80. There are 'general purpose' University computing systems which are 
  81. available to all students; I don't manage those systems, so I can't
  82. speak for them.  
  83.  
  84. >Not a blank check, but the provision of
  85. >CERTAIN resources for own use (as opposed to the provision of
  86. >resources for CERTAIN use - understood?)
  87.  
  88. I agree; however, when that use begins to approach illegal activity
  89. (or activity prohibited by University policy), then actions must be
  90. taken.  Would you agree?
  91.  
  92. >but I think universities should provide the resources they
  93. >are able to (technically, financially,...) and place no restrictions
  94. >on their use unless there are justifiable reasons to do so, 
  95.  
  96. Yup, but who determines the justification?  There are those who argue
  97. that playing games is justifiable 'educational use'; there are others
  98. who argue that diskspace quotas are a violation of their 'academic
  99. freedom'.  You want to use it, and I have to manage it for all users;
  100. sooner or later, we may butt heads.
  101.  
  102. >e.g.
  103. >outright abuse (what this is, however, should not be stated par ordre
  104. >du mufti but established, ideally, by a board of staff AND students).
  105.  
  106. The other problem with the definition of offenses comes here.  I've
  107. been trying to write a polcy for almost a year, and I keep hearing 
  108. that "it's not specific enough".  One student even complained about
  109. the sentence "Forgery, or attempted forgery, of electronic mail messages 
  110. is prohibited."; he said that it was "too general".  
  111.  
  112. We will NOT be able to develop a written policy that covers every possible
  113. offense.  Some discretion must be left with the administrators.  
  114.  
  115. I repeat: "academic freedom" does not equal "a blank check".
  116.  
  117. -- 
  118. MORGAN@UKCC         |       Wes Morgan       |        ...!ukma!ukecc!morgan 
  119. morgan@ms.uky.edu   | Engineering  Computing |   morgan@wuarchive.wustl.edu
  120. morgan@engr.uky.edu | University of Kentucky | JWMorgan@dockmaster.ncsc.mil
  121.   Mailing list for AT&T StarServer S/E  - starserver-request@engr.uky.edu
  122.