Article View: comp.admin.policy
Article #88Policy regarding Crack
From: Wes Morgan
Date: Thu, 27 Aug 1992 18:38
Date: Thu, 27 Aug 1992 18:38
111 lines
5516 bytes
5516 bytes
From: S_TITZ@iravcl.ira.uka.de (Olaf Titz) >In <1992Aug26.174017.1077@ms.uky.edu> morgan@ms.uky.edu writes: > >> - I could write an automated shell script that examines every >> text file on the system, reporting the names of any files which >> are in /etc/passwd format (i.e. Crack food). This borders on the >> unacceptable. > >It *is* unacceptable, IMHO - the same thing of searching user files. > This approach borders on acceptability for one reason only -- I'm not looking at the files myself. If such a script reports that "file /users/booga/foo/blast is in /etc/passwd format", I would simply dis- cuss the matter with the owner of the file. I don't examine user files. Besides, I don't believe that the /etc/passwd format is widely used in other applications.......8) >> OR....... >> >> - I can set a simple policy that says "this system is not to be used >> for the development or use of password cracking software". My users >> are Engineering students; they have no curricular need to develop >> such software on our systems. >> >> This approach benefits everyone (in theory). The users don't have >> to worry about admins (or Crack users) rooting through their files, >> and I don't have to worry about Crack fanciers....... > >Are you sure that setting a policy will *prevent* your system from >being Crack'ed? ;;-) I never said that such a policy would prevent it! However, such cracking would be a more remote possibility. 8) I'm also concerned about users collecting password files from all over and using my box as their password cruncher....... >> Computing resources are usually assigned/allocated within this framework. >> However, assignments/allocations of these resources for purposes outside >> of the framework can (and should) be limited. A Mechanical Engineering >> student may wish to write a Japanese text parser; while that is a laudable >> project, can we justify the allocation of Engineering resources to that >> goal? >> >> "Academic freedom" is not equivalent to "a blank check". > >Right, but... be VERY careful about that. > >The step from your Japanese parser to general restrictions like 'we >don't carry alt* and rec* newsgroups' is dangerously short. Excuse me, but the two concepts are NOT as similar as you claim them to be. In my example, I suggest a policy that would prevent the use of a particular facility by an individual user (namely, the future use of my system for cracking programs). Your counter-example, the revocation of alt.* and rec.* newsgroup access, suggests the revocation of current use by all users. The two cases are markedly different; you're comparing apples and oranges. >Take >another example: When I want books from my university library, nobody >cares about the importance of, say, a book on music history for my >computer science studies. This example is irrelevant. The university libraries are, by definition, open to all students of the University. My systems, on the other hand, are open only to Engineering students/faculty/staff. There are 'general purpose' University computing systems which are available to all students; I don't manage those systems, so I can't speak for them. >Not a blank check, but the provision of >CERTAIN resources for own use (as opposed to the provision of >resources for CERTAIN use - understood?) I agree; however, when that use begins to approach illegal activity (or activity prohibited by University policy), then actions must be taken. Would you agree? >but I think universities should provide the resources they >are able to (technically, financially,...) and place no restrictions >on their use unless there are justifiable reasons to do so, Yup, but who determines the justification? There are those who argue that playing games is justifiable 'educational use'; there are others who argue that diskspace quotas are a violation of their 'academic freedom'. You want to use it, and I have to manage it for all users; sooner or later, we may butt heads. >e.g. >outright abuse (what this is, however, should not be stated par ordre >du mufti but established, ideally, by a board of staff AND students). The other problem with the definition of offenses comes here. I've been trying to write a polcy for almost a year, and I keep hearing that "it's not specific enough". One student even complained about the sentence "Forgery, or attempted forgery, of electronic mail messages is prohibited."; he said that it was "too general". We will NOT be able to develop a written policy that covers every possible offense. Some discretion must be left with the administrators. I repeat: "academic freedom" does not equal "a blank check". -- MORGAN@UKCC | Wes Morgan | ...!ukma!ukecc!morgan morgan@ms.uky.edu | Engineering Computing | morgan@wuarchive.wustl.edu morgan@engr.uky.edu | University of Kentucky | JWMorgan@dockmaster.ncsc.mil Mailing list for AT&T StarServer S/E - starserver-request@engr.uky.edu
Technical Details
Message-ID:
<1992Aug27.143847.5244@ms.uky.edu>Path:
arc1-ca.pugleaf.net!sparky!uunet!gatech!ukma!morganReferences:
<9208271530.AA15830@herodotus.cs.uiuc.edu>Show Full Headers
Complete Article Headers
Newsgroups: comp.admin.policy Path: arc1-ca.pugleaf.net!sparky!uunet!gatech!ukma!morgan From: morgan@ms.uky.edu (Wes Morgan) Subject: Policy regarding Crack References: <9208271530.AA15830@herodotus.cs.uiuc.edu> Message-ID: <1992Aug27.143847.5244@ms.uky.edu> Date: Thu, 27 Aug 1992 18:38:47 GMT Organization: The Puzzle Palace, UKentucky Lines: 111