🚀 go-pugleaf

dan@cubmol.bio.columbia.edu (Daniel Zabetakis) writes:

>    Does anyone have in thier usage policy mention of Crack, or COPS,
>or other programs that could be used for unnacceptable purposes?
>    Does anyone not allow possesion of Crack? How about running it?
[...]

I would think that it would violate the general free expression and
privacy policies of most universities to ban possession of legal
material. I assume Columbia doesn't ban student and professor
possession of legal books?

Banning the running of such programs doesn't seem so bad. But any
such ban should have an authorization mechanism.

I'm enclosing relevant information from the Computer and Academic
Freedom archive.

- Carl

ANNOTATED REFERENCES

(All these documents are available on-line. Access information follows.)

=================
news/cafv02n23: Message-Id: <1992Apr30.164835.1816@opac.osl.or.gov>
=================
An article from the Computers and Academic Freedom News 02.23

Notes 8-9 are about cracking program and email privacy policy.

8. "I have a problem with outlawing cracking programs: ... Would it be
illegal to possess a paper on access security that contained the
source code for a cracking program?  Where do they draw the line
between intellectual discourse and intent to break into someones
account?"

=================
news/cafv02n11: Message-Id: <9202161945.AA24863@bsu-cs.bsu.edu>
=================
An article from the Computers and Academic Freedom News 02.11

Notes 5-7 are about privacy.

5. A user on this system was apparently running a password cracking
program.  An administer searched my files and found I had a copy of
the newest version of Crack.  I have legitimate reasons for having
this program.  I have received mail from the Chairman of the
Department "inviting" me to discuss my account privileges. "It really
bothers me that I'm going to get in a lot of trouble (probably anyway)
just for the mere possession of a program."

=================
news/cafv02n29: Message-Id: <1992Jun18.200126.486@newshost.lanl.gov>
=================
An article from the Computers and Academic Freedom News 02.29

Notes 7 and 8 concern the rights of system administrators to access
users' accounts.

7. "You are given an account with the understanding that you will not
use it to attempt to crack the system. But if you use that account to
learn the passwords of other users, then you are abusing the trust
placed in you by the system administrator, and he can remove your
access for it."

=================
news/cafv01n03: Message-Id: <9104212213.AA25432@usenet.INS.CWRU.Edu>
=================
An article from the Computers and Academic Freedom News 01.03

Netnews censorship of a posted program at Case Western is discussed.

=================
news/cafv01n20: Message-Id: <1991Jul30.013420.19111@eff.org>
=================
An article from the Computers and Academic Freedom News 01.20

A report of a student of the University of Georgia being suspended for
knowingly aiding crackers by supplying them with an encrypted password
file. (The student seems to have received due processes.)

=================
academic/student.freedoms.aaup
=================
Joint Statement on Rights and Freedoms of Students -- This is the main
U.S. statement on student academic freedom.

=================
policies/uiuc.edu
=================
This is the University of Illinois's Interim E-Mail and Computer File
Privacy Policy. It says that "network and system administrators are
expected to treat the contents of electronic files as private and
confidential." and "Any inspection of electronic files, and any action
based upon such inspection, will be governed by all applicable U. S.
and Illinois laws and by University policies."

=================
policies/ctr.columbia.edu
=================
"CTR Rules and Regulations Reguarding the Use of Computing
Facilities".  CTR is the Center for Telecommunications Research at
Columbia University.  The policy was sent in by Seth Robertson
<seth@ctr.columbia.edu>.


=================
policies/cc.columbia.edu
=================
The old policy for Columbia University's Center for Computing
Activities. They are working on a new policy.

=================
faq/policy
=================
q: What guidance is there for creating or evaluating a computer policy?

=================
faq/email.policies
=================
q: Do any universities treat email and computer files as private?

=================
faq/email.privacy
=================
q: Can (should) my university monitor my email (and files)?

=================
faq/netnews.writing
=================
q: Should my university allow students to post to Netnews?
(also talks about freedom of expression in the context of computers)

=================
caf
=================
A description to the comp-academic-freedom-talk mailing list. It is a
free-forum for the discussion of questions such as: How should general
principles of academic freedom (such as freedom of expression, freedom
to read, due process, and privacy) be applied to university computers
and networks? How are these principles actually being applied? How can
the principles of academic freedom as applied to computers and
networks be defended?

=================
=================

These document(s) are available by anonymous ftp (the preferred
method) and by email. To get the file(s) via ftp, do an anonymous ftp
to ftp.eff.org (192.88.144.4), and get file(s):

  pub/academic/news/cafv02n23
  pub/academic/news/cafv02n11
  pub/academic/news/cafv02n29
  pub/academic/news/cafv01n03
  pub/academic/news/cafv01n20
  pub/academic/academic/student.freedoms.aaup
  pub/academic/policies/uiuc.edu
  pub/academic/policies/ctr.columbia.edu
  pub/academic/policies/cc.columbia.edu
  pub/academic/faq/policy
  pub/academic/faq/email.policies
  pub/academic/faq/email.privacy
  pub/academic/faq/netnews.writing
  pub/academic/caf

To get the file(s) by email, send email to archive-server@eff.org.
Include the line(s) (be sure to include the space before the file
name):

send acad-freedom/news cafv02n23
send acad-freedom/news cafv02n11
send acad-freedom/news cafv02n29
send acad-freedom/news cafv01n03
send acad-freedom/news cafv01n20
send acad-freedom/academic student.freedoms.aaup
send acad-freedom/policies uiuc.edu
send acad-freedom/policies ctr.columbia.edu
send acad-freedom/policies cc.columbia.edu
send acad-freedom/faq policy
send acad-freedom/faq email.policies
send acad-freedom/faq email.privacy
send acad-freedom/faq netnews.reading
send acad-freedom caf
--
Carl Kadie -- kadie@cs.uiuc.edu -- University of Illinois at Urbana-Champaign

In article <mumble>, dan@cubmol.bio.columbia.edu (Daniel Zabetakis) writes:
|> 
|>     Does anyone have in thier usage policy mention of Crack, or COPS,
|> or other programs that could be used for unnacceptable purposes?
|>     Does anyone not allow possesion of Crack? How about running it?

At Rice, we do not explicitly disallow the possession or running of
either of these programs.  If we caught someone using them for
unacceptable purposes, we could take action against them for trying to
break in to systems that they are not authorized to use.  Our policies
prohibit unacceptable actions, regardless of the mechanism or
technology used to perform them.  For some systems here, our defense is
to run them ourselves regularly, and strongly encourage/force users
whose accounts are vulnerable according to these programs to close the
vulnerabilities.  In the case of crack, if it guesses a password, we
have the user change to an unguessable (by crack) password.  We use
COPS regularly to audit for its list of security holes, such as world
readable/writable .rhosts files, and have the users close those too.

There are many different groups managing computers here on campus, and
not all of them use these methods, to my knowledge.  The systems that
do use these methods comprise the largest networks on campus, with by
far the largest number of users.  The good thing about using COPS is
that it protects the networks that use it from some of the weaknesses
of the other networks on campus.

-- 
Joseph A. Watters, Jr.		jaw@owlnet.rice.edu
Deputy Director, Owlnet
Rice University
Houston, Texas

kadie@herodotus.cs.uiuc.edu (Carl M. Kadie) writes:
>dan@cubmol.bio.columbia.edu (Daniel Zabetakis) writes:
>
>>    Does anyone have in thier usage policy mention of Crack, or COPS,
>>or other programs that could be used for unnacceptable purposes?
>>    Does anyone not allow possesion of Crack? How about running it?
>[...]
>
>I would think that it would violate the general free expression and
>privacy policies of most universities to ban possession of legal
>material. I assume Columbia doesn't ban student and professor
>possession of legal books?
>
>Banning the running of such programs doesn't seem so bad. But any
>such ban should have an authorization mechanism.

A simple question:

If I allow source code for cracking programs, but ban the running of
such programs, how will I know that the programs have been run?  After
all, I don't live in front of a terminal! 8)

Seriously, let's look at the possibilities:

	- I could (as the admin) sweep through all the user files,
	  looking for Crack source/binaries.  This is unacceptable.

	- I could check the monthly accounting reports and examine
	  every program that burned more than X minutes of CPU time.
	  This, too, is unacceptable.

	- I could remove (or place a lock upon) /usr/dict/words (the most
          commonly used word file for Crack).  This would conflict with 
	  other system programs, so it's unacceptable as well.

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

	- I could just cease to care about it, and wait for something to happen.
	  This, too, is unacceptable; we've already had several cracking inci-
	  dents, and I don't need those headaches.

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

(If I were running systems for a Computer Science or Mathematics department,
 I might set aside a particular machine for use by cryptography enthusiasts;
 perhaps this could serve as the 'authentication mechanism' Carl mentioned.)

It's important to realize that "academic freedom" does not imply automatic
organizational support of any endeavor a student (or faculty member) may
wish to undertake.  

For example, I doubt that an Engineering faculty member would receive 
university support for work in clay sculpture or political science.  At 
most universities, the faculty/staff/student communities work within a 
(fairly) well-defined conceptual framework for their area of interest.  

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

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

Wes> == Wes Morgan <morgan@ms.uky.edu> 

 Wes> Seriously, let's look at the possibilities:

 Wes> 	- I can set a simple policy that says "this system is not to be used
 Wes> 	  for the development or use of password cracking software".  My users
 Wes> 	  are Engineering students; they have no curricular need to develop
 Wes> 	  such software on our systems.  

 Wes> 	  This approach benefits everyone (in theory).  The users don't have
 Wes> 	  to worry about admins (or Crack users) rooting through their files, 
 Wes> 	  and I don't have to worry about Crack fanciers.......

Or you could run shadow passwords, and run Crack yourself, and have a
proactive password checker.

This also benefits everyone, because it means that people are less
likely to have their accounts broken into, you don't get into problems
with people being duped into giving out your /etc/passwd for Joe Cracker
to run through Crack on his 486/50 (or on the SS2 he broke into last
week), and even if someone does get your shadow file, your passwords
will have some degree of strength.

I realize that this isn't always doable, but it's a big improvement.

--
Christopher Davis * ckd@eff.org * System Administrator, EFF * +1 617 864 0665
            ``Ed Gruberman, you fail to grasp Ti Kwan Leep.
            Approach me that you might see.'' -- The Master

In <1992Aug26.174017.1077@ms.uky.edu> morgan@ms.uky.edu writes:

>  Seriously, let's look at the possibilities:
>  
>  	- I could (as the admin) sweep through all the user files,
>  	  looking for Crack source/binaries.  This is unacceptable.
>...
>  	- 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.

>  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? ;;-)

>...
>  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. 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. 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 don't know about your engineering department, and I know that this
is a heatedly debated issue since computers exist (are games allowed?
and so on) 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, 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).

MfG,
        Olaf
-- 
Olaf Titz - comp.sc.student - Univ of Karlsruhe - s_titz@iravcl.ira.uka.de -
uknf@dkauni2.bitnet - praetorius@irc - +49-721-60439 - did i forget something?
One frequently hears horror expressed that a 2M byte machine may have 400K
 devoted to its operating system. - Fred Brooks (1975)

Or you could run crack yourself and fix the holes...

-- 
>>Unix/C Contract worker available 5 years C/unix work experience<<  ______
Available for Telecommuting/Travel and contracts on the T Line       \    /
in the Boston MA area. Send me e-mail for a copy of my Resume.        \  /
       -- VWIS 508-793-9568 (2400 baud), Linux support BBS.--          \/