The 'Security Digest' Archives (TM)

Archive: About | Browse | Search | Contributions | Feedback
Site: Help | Index | Search | Contact | Notices | Changes

ARCHIVE: Rutgers 'Security List' (incl. misc.security) - Archives (1990)
DOCUMENT: Rutgers 'Security List' for August 1990 (53 messages, 21388 bytes)
SOURCE: http://securitydigest.org/exec/display?f=rutgers/archive/1990/08.txt&t=text/plain
NOTICE: securitydigest.org recognises the rights of all third-party works.

START OF DOCUMENT

-----------[000000][next][prev][last][first]----------------------------------------------------
Date:      1 Aug 90 03:00:00 GMT
From:      WHMurray@DOCKMASTER.NCSC.MIL
To:        misc.security
Subject:   ITSEC


           Observations and Comments on the ITSEC

The  ITSEC,  Information  Technology   Security   Evaluation
Criteria,  represents  the  harmonization of the  evaluation
criteria  work  done  by the UK, Germany,  France,  and  the
Netherlands.  The work is in part a response  to the Trusted
Computer Security  Evaluation Criteria of the  US Department
of Defense, in  part  an attempt to  update that  work.  For
example,  the use of the  term "Information Technololgy"  in
place of computer recognizes that the issue  is  now broader
than  it  was when the  TCSEC was  written.  It  is  also  a
response  to a concern on the part of these governments that
the TCSEC was part of a  DoD plot to exclude their  products
from the  US  market,  a  concern aggravated  by  the  DoD's
refusal, on national security  grounds,  to evaluate foreign
built  products.  (I  have never  been  certain whether  the
Europeans  really  believed in this  conspiracy,  or  simply
asserted it to get  funding for  what  they  intended to  do
anyway.)

The ITSEC describes language and criteria to  be used in the
evaluation  of security features,  functions, and properties
of computer products.  It is  independent  of  any  program,
commitment, or intent to do such evaluations.

The  use of the English language is excellent.  The  text is
clear, precise,  and  well ordered.  With  a few  exceptions
English language words retain their normal  meaning.  (There
do  not appear  to  be  any secret code  words here; trusted
means trusted, and secure  means  secure  (rather  than  the
reliable  enforcement  of  the  author's  favorite  policy).
Likewise  there  are  no  reserved  words;  classified means
classified, not CLASSIFIED.)

It would be naive  to believe  that there are no politics or
arguments  reflected  in  a  document  that  represents  the
"harmonisation"  of  the  efforts  of  four  nation  states.
However,  the ones here are sufficiently subtle as to escape
the notice of  this  practiced  observer.  The  document  is
almost totally free of rhetoric.

Important  and  useful  distinctions are  drawn, for example
between product (that  which a  vendor  offers),  system  (a
product   instance  which  someone  uses),  and   target  of
evaluation  (TOE) (that  which is  offered or  sponsored for
evaluation).  Also,  between  assurance,   correctness,  and
effectiveness.

In drawing the  distinction between  product and system, the
document acknowledges  Courtney's  first law,  i.e. "Nothing
useful can be said about  the  security  of a product/system
except  in  the  context of  a  particular  application  and
environment."  (Courtney was never able to  get  the authors
of the TCSEC to acknowledge the distinction.)  It notes that
a principal difference between  products and systems is what
is known  about their  environments (and applications); that
one may only assume  about products  what one can know about
systems.   Having said that, the authors argue that for sake
of consistency,  the same evaluation criteria should be used
for both.

Perhaps the most important distinction that the ITSEC offers
is  that  between functionality and assurance.  Indeed, they
employ separate scales for the evaluation of these.  This is
a concession  to those of  us who have complained  about the
lumping  of these in the  TCSEC.  This  results  in  a  more
granular  set  of criteria which permits a fairer comparison
of products.  It does so at the  expense  of a larger number
of points on  the  scale.  On  the other  hand, it does away
with the need for the infamous digraph.

As  in the TCSEC, assurance levels are based upon  the rigor
of the applicable and applied methodology, rather than  upon
the requirements  of  the application  and environment.  The
descriptions of the levels appears  to be  simpler and  more
granular  than  those in  the TCSEC.  However,  the  highest
defined level, E6, does not  seem to  be as rigorous as that
required for A1.  Nonetheless,  the scale is open at the top
end;  more rigorous methods could be specified as  required.
There  is  something to be  said for  resticting  oneself to
methods that are employed in  the  real  world, rather  than
arguing  for arbitrary rigor that has  not  ever before been
employed.

Another  important  distinction  that  the  ITSEC  draws  is
between the Corporate (institutional?)  Security  Policy and
the System Security Policy.  It is well  known that the both
the British and the Germans feel that the application of the
DoD  Mandatory  Policy  results  in  a tendency for  data to
migrate  toward   the  highest  classification.  They   were
anxious  to have  criteria  that  were  independent of  this
policy.

Identification is lumped with Authentication  and is applied
only   to  users.  No   consideration  is   given   to   the
identification  of  objects  or   other   subjects  such  as
processes.

Likewise the term  "attributes"  is  used  for  both  object
sensitivity labels  and  user  credentials.  While  this  is
likely to be confusing to someone that does not already know
what  is  intended,   it   is  still   better   that   using
"classification" for both objects and subjects.

Because  the  ITSEC  is  marginally  more  granular than the
TCSEC,  the  classes of the TCSEC  may  be  mapped on to the
ITSEC.  This  is done and provided in an appendix.  However,
the converse is  not true; that is,  it  is  not possible to
express the evaluation classes of the  ITSEC in terms of the
TCSEC.

Security functionality for a product is expressed in claims.
There are  no requirements or  design points set forth as in
the TCSEC.  However, the claims may be made  by reference to
a pre-defined set  of  functionality classes.  The  criteria
define ten such classes.  While  the  first five are derived
from  the functionality of  the TCSEC classes C1 thru B3/A1,
they are  essentially arbitrary.  Sub-classes, super-classes
or alternate sets  could be defined without doing damage  to
the structure.  (For example, I have longed claimed that the
commercial  requirement looked something like C2  plus  ACLs
plus named transaction types.  Since  functionality  classes
in the ITSEC are arbitrary, not hierarchical,  and not bound
to assurance, it would  be  correct and proper  to  define a
class that looked like that.)

The more I read it, the better I like it.

William Hugh Murray, Executive Consultant, Information System Security
21 Locust Avenue, Suite 2D, New Canaan, Connecticut 06840                
203 966 4769, WHMurray at DOCKMASTER.NCSC.MIL

-----------[000001][next][prev][last][first]----------------------------------------------------
Date:      2 Aug 90 13:55:54 GMT
From:      PGOODWIN@GTRI01.GATECH.EDU (Paul Goodwin)
To:        misc.security
Subject:   break-in detection

The point at which you are most likely to identify that someone is
breaking into a system is while that person is attempting to gain
access to an account.  Once he has an account USERID and PASSWORD,
detection becomes much more difficult.  Making the authorized users
of a system periodically change their passwords may suddenly deny access
to an unauthorized user, causing him to once again 'hack' at the system
until he gains entry.  This will make him much more visible, and much more
likely to be caught.

Disclaimer: I am, of course, speaking solely for myself.

Paul Goodwin
Office of Computing Services
Ga. Inst. of Technology

-----------[000002][next][prev][last][first]----------------------------------------------------
From:      barmar@think.com (Barry Margolin)  5-AUG-1990  0:33:10
To:        misc-security@husc6.harvard.edu
It's described pretty well in the SunOS 4.1 documentation.  There's a
decent overview of it in one of the administration manuals (named something
like "System & Network Administration".  And there's a more precise
description starting on p.156 of "Network Programming" (the chapter claims
to be a copy of RFC-1050).

Sun's secure RPC makes use of Diffie-Hellman public-key encryption and DES
encryption.

--
Barry Margolin, Thinking Machines Corp.
-----------[000003][next][prev][last][first]----------------------------------------------------
From:      EVERHART@arisia.dnet.ge.com  5-AUG-1990  0:51:24
To:        security@pyrite.rutgers.edu
If looking for a secure distributed file system, I'd suggest checking
out AFS, from Transarc. It uses Kerebros authentication, and supplies
tools for maintenance of large networks. It was designed for 10,000+
workstation environments and scales much better than NFS; also tends
to avoid eating networks for lunch as NFS can and does. Transarc is
in Pittsburgh; 412 338 4400; their domain name is transarc.com.
Glenn
-----------[000004][next][prev][last][first]----------------------------------------------------
From:      DANCC@cunyvm.cuny.edu  5-AUG-1990  1:09:19
To:        SECURITY@rutgers.edu
Sorry if this is too elementary for the group, but I'm at sea.  I've
seen what I want, but can't find it in any catalog.

It's sheetmetal cage, open only on front.  You bolt or glue it to a
table, attach the CPU to a sliding deal which locks into the cage,
and there you are.  Thief can't walk away with the whole thing, and
can't open cover to steal cards.  With time, tools, knowledge, and
some assurance the guard won't be by for 20 minutes  . . . but it
raises the threshhold.

Saw one at a school in California, but my host didn't know the
source.  He had been using them for some kind of PC clone, but they
fit his new Mac IIs also.  I assume they come in different sizes.

Much appreciate any pointers.
-----------[000005][next][prev][last][first]----------------------------------------------------
From:      de5@stc06.ctd.ornl.gov (SILL D E)  5-AUG-1990  1:25:38
To:        misc-security@ucbvax.berkeley.edu
>Now the REAL story:  the number factored was of a very special form,

AARRGGHH!!  Apparently you missed the recently posted article
(comp.risks?) by Ron Rivest (the `R' in RSA) that gave the REAL story.
Actually, both of the above posters are (in)correct.  The number
factored was of the form 10000...00001 (binary).  Such numbers are
used by RSA only by coincidence, that is to say very rarely.

Rivest further conjectured that that and other developments in
factoring would lead to the breaking of some short-key RSA within a
couple years, I believe (this is from memory, I forget the numbers).
He also said they were recommending longer keys for paranoids...er...
folks wanting utmost security.

Anybody save that article?  How 'bout posting it or sending me a copy?

-- 
--
Dave Sill (de5@ornl.gov)		These are my opinions.
Martin Marietta Energy Systems
Workstation Support
-----------[000006][next][prev][last][first]----------------------------------------------------
From:      GREENY <MISS026@ecncdc.bitnet>  5-AUG-1990 22:37:00
To:        <security@pyrite.rutgers.edu>
A lot of people have been asking me for the Oregon Sci. #, so I did some
digging, and found it!

Here it is:

Oregon Scientific, Inc.
10950 S.W. 5th Street, Suite #275
Beaverton, OR  97005

1-503-646-9806
1-503-641-8015 FAX
1-800-869-7779 (according to a friend of mine....)

Hiope this helps, and hope your cars, offices, boats, and homes are yelling
soon! :->

Bye for now but not for long
Greeny

BITNET: MISS026@ECNCDC
Internet: MISS026%ECNCDC.BITNET@CUNYVM.CUNY.EDU
GEnie: GREENY
AOL: GREENY1
Compu$erve: 72567,457
-----------[000007][next][prev][last][first]----------------------------------------------------
From:      pyron@skvax1.csc.ti.com (If Clayton's an Aggie, I'm not!)  5-AUG-1990 23:06:21
To:        "CSMSPCN@oac.ucla.edu"@skvax1.csc.ti.com
Cc:        "security@pyrite.rutgers.edu"@skvax1.csc.ti.com, PYRON@skvax1.csc.ti.com
>recently factored a 155 digit number, and that they are consequently
>recommending at least 200 digit primes for the RSA stuff.

The original article in CACM recommended 200 digit numbers, but made note of
the fact that factor these larges numbers was difficult, which is both a
blessing and a curse.  Of course, difficult in 1977 is a breeze in 1991?

Dillon Pyron                         | The opinions are mine, the facts 
TI/DSEG VAX Systems Support          | probably belong to the company.
pyron@skvax1.ti.com                  |
(214)575-3087                        | Jim Henson - Now that was talent
                                     | 
-----------[000008][next][prev][last][first]----------------------------------------------------
Date:      4 Aug 90 18:48:00 GMT
From:      JUTBAAA@iup.BITNET (Abhik Biswas)
To:        misc.security
Subject:   Papers on computer security....

Are there any archives of papers related to computer security either at sites
on Internet or Bitnet? Any information will be appreciated.

-----------[000009][next][prev][last][first]----------------------------------------------------
Date:      5 Aug 90 05:14:07 GMT
From:      krfall@UCSD.EDU
To:        misc.security
Subject:   Re: "secure nfs"

> If looking for a secure distributed file system, I'd suggest checking
> out AFS, from Transarc. It uses Kerebros authentication

The currently released version (3.0) does not yet use Kerberos (at
least so I have been told).
That would be the case for the AFS being released through Mt. Xinu as
well.  Project Athena has modified the authentication program
(klog?) to produce one which scrawls a v4 Kerberos ticket inside
the AFS tokens (aklog), and made corresponding changes for their
server software.

AFS 4 is evidently on the way from Transarc,
as is v5 Kerberos from Athena.  One might expect a merger
of these systems in the future.
These ideas are also being monitored by the Distributed File Systems
working group of the IETF (dfs-wg-request@citi.umich.edu).

- Kevin

-----------[000010][next][prev][last][first]----------------------------------------------------
Date:      7 Aug 90 01:23:27 GMT
From:      jpc@fctunl.rccn.pt (Jose Pina Coelho)
To:        misc.security
Subject:   Re: criminal record

>   It is possible to write to the FBI and ask them if they have a folder on

I doubt they would send you more than 10% of the folder.

[Moderator tack-on:  Speculation is fine, but that's all anyone has sent
in so far.  Does anyone have *FACTS* about this?   _H*]

-----------[000011][next][prev][last][first]----------------------------------------------------
From:      annala@neuro.usc.edu (A J Annala)  12-AUG-1990  0:31:18
To:        misc-security@ucbvax.berkeley.edu
I do some data communications technician type contracting work from time to
time (e.g. installing modems, analog line testing, protocol analysis, etc).
There have been notes on the network about police confiscating equipment of
the type I often use in my work.  The police claim is that such devices are
telephone access devices which should not be in the hands of the public.  I
am curious about whether any other technical people have been challenged by
the police and what answer has satisfied them to go away without hassle.

AJ
-----------[000012][next][prev][last][first]----------------------------------------------------
From:      WHMurray@dockmaster.ncsc.mil  12-AUG-1990  0:48:18
To:        security@rutgers.edu
           Observations and Comments on the ITSEC

The  ITSEC,  Information  Technology   Security   Evaluation
Criteria,  represents  the  harmonization of the  evaluation
criteria  work  done  by the UK, Germany,  France,  and  the
Netherlands.  The work is in part a response  to the Trusted
Computer Security  Evaluation Criteria of the  US Department
of Defense, in  part  an attempt to  update that  work.  For
example,  the use of the  term "Information Technololgy"  in
place of computer recognizes that the issue  is  now broader
than  it  was when the  TCSEC was  written.  It  is  also  a
response  to a concern on the part of these governments that
the TCSEC was part of a  DoD plot to exclude their  products
from the  US  market,  a  concern aggravated  by  the  DoD's
refusal, on national security  grounds,  to evaluate foreign
built  products.  (I  have never  been  certain whether  the
Europeans  really  believed in this  conspiracy,  or  simply
asserted it to get  funding for  what  they  intended to  do
anyway.)

The ITSEC describes language and criteria to  be used in the
evaluation  of security features,  functions, and properties
of computer products.  It is  independent  of  any  program,
commitment, or intent to do such evaluations.

The  use of the English language is excellent.  The  text is
clear, precise,  and  well ordered.  With  a few  exceptions
English language words retain their normal  meaning.  (There
do  not appear  to  be  any secret code  words here; trusted
means trusted, and secure  means  secure  (rather  than  the
reliable  enforcement  of  the  author's  favorite  policy).
Likewise  there  are  no  reserved  words;  classified means
classified, not CLASSIFIED.)

It would be naive  to believe  that there are no politics or
arguments  reflected  in  a  document  that  represents  the
"harmonisation"  of  the  efforts  of  four  nation  states.
However,  the ones here are sufficiently subtle as to escape
the notice of  this  practiced  observer.  The  document  is
almost totally free of rhetoric.

Important  and  useful  distinctions are  drawn, for example
between product (that  which a  vendor  offers),  system  (a
product   instance  which  someone  uses),  and   target  of
evaluation  (TOE) (that  which is  offered or  sponsored for
evaluation).  Also,  between  assurance,   correctness,  and
effectiveness.

In drawing the  distinction between  product and system, the
document acknowledges  Courtney's  first law,  i.e. "Nothing
useful can be said about  the  security  of a product/system
except  in  the  context of  a  particular  application  and
environment."  (Courtney was never able to  get  the authors
of the TCSEC to acknowledge the distinction.)  It notes that
a principal difference between  products and systems is what
is known  about their  environments (and applications); that
one may only assume  about products  what one can know about
systems.   Having said that, the authors argue that for sake
of consistency,  the same evaluation criteria should be used
for both.

Perhaps the most important distinction that the ITSEC offers
is  that  between functionality and assurance.  Indeed, they
employ separate scales for the evaluation of these.  This is
a concession  to those of  us who have complained  about the
lumping  of these in the  TCSEC.  This  results  in  a  more
granular  set  of criteria which permits a fairer comparison
of products.  It does so at the  expense  of a larger number
of points on  the  scale.  On  the other  hand, it does away
with the need for the infamous digraph.

As  in the TCSEC, assurance levels are based upon  the rigor
of the applicable and applied methodology, rather than  upon
the requirements  of  the application  and environment.  The
descriptions of the levels appears  to be  simpler and  more
granular  than  those in  the TCSEC.  However,  the  highest
defined level, E6, does not  seem to  be as rigorous as that
required for A1.  Nonetheless,  the scale is open at the top
end;  more rigorous methods could be specified as  required.
There  is  something to be  said for  resticting  oneself to
methods that are employed in  the  real  world, rather  than
arguing  for arbitrary rigor that has  not  ever before been
employed.

Another  important  distinction  that  the  ITSEC  draws  is
between the Corporate (institutional?)  Security  Policy and
the System Security Policy.  It is well  known that the both
the British and the Germans feel that the application of the
DoD  Mandatory  Policy  results  in  a tendency for  data to
migrate  toward   the  highest  classification.  They   were
anxious  to have  criteria  that  were  independent of  this
policy.

Identification is lumped with Authentication  and is applied
only   to  users.  No   consideration  is   given   to   the
identification  of  objects  or   other   subjects  such  as
processes.

Likewise the term  "attributes"  is  used  for  both  object
sensitivity labels  and  user  credentials.  While  this  is
likely to be confusing to someone that does not already know
what  is  intended,   it   is  still   better   that   using
"classification" for both objects and subjects.

Because  the  ITSEC  is  marginally  more  granular than the
TCSEC,  the  classes of the TCSEC  may  be  mapped on to the
ITSEC.  This  is done and provided in an appendix.  However,
the converse is  not true; that is,  it  is  not possible to
express the evaluation classes of the  ITSEC in terms of the
TCSEC.

Security functionality for a product is expressed in claims.
There are  no requirements or  design points set forth as in
the TCSEC.  However, the claims may be made  by reference to
a pre-defined set  of  functionality classes.  The  criteria
define ten such classes.  While  the  first five are derived
from  the functionality of  the TCSEC classes C1 thru B3/A1,
they are  essentially arbitrary.  Sub-classes, super-classes
or alternate sets  could be defined without doing damage  to
the structure.  (For example, I have longed claimed that the
commercial  requirement looked something like C2  plus  ACLs
plus named transaction types.  Since  functionality  classes
in the ITSEC are arbitrary, not hierarchical,  and not bound
to assurance, it would  be  correct and proper  to  define a
class that looked like that.)

The more I read it, the better I like it.

William Hugh Murray, Executive Consultant, Information System Security
21 Locust Avenue, Suite 2D, New Canaan, Connecticut 06840                
203 966 4769, WHMurray at DOCKMASTER.NCSC.MIL
-----------[000013][next][prev][last][first]----------------------------------------------------
From:      Jim Pinson <JPINSON@uga.cc.uga.edu>  15-AUG-1990 12:16:04
To:        security@pyrite.rutgers.edu
I make up my passwords based on the first letters of a phrase which has
meaning only to me.

Examples:

My First Grade Teacher Was Miss Jones  = MFGTWMJ
I Hate Boiled Okra With A Passion      = IHBOWAP

These passwords are easy to remember, fairly random in nature, and very hard
to guess.

Jim Pinson  University of Georgia.
-----------[000014][next][prev][last][first]----------------------------------------------------
From:      jpc@fctunl.rccn.pt (Jose Pina Coelho)  15-AUG-1990 12:36:50
To:        security@pyrite.rutgers.edu
>   It is possible to write to the FBI and ask them if they have a folder on

I doubt they would send you more than 10% of the folder.

[Moderator tack-on:  Speculation is fine, but that's all anyone has sent
in so far.  Does anyone have *FACTS* about this?   _H*]
-----------[000015][next][prev][last][first]----------------------------------------------------
From:      jik@athena.mit.edu (Jonathan I. Kamens)  15-AUG-1990 12:53:24
To:        security@pyrite.rutgers.edu
|> It is possible to write to the FBI and ask them if they have a folder on
|> you and to send you a copy of the contents of the folder if the folder does
|> exist.

  And, of course, if they don't have a folder on you, then the fact that you
wrote to them and asked if they did would most assuredly prompt them to open a
new one. (1/2 :-)

Jonathan Kamens			              USnail:
MIT Project Athena				11 Ashford Terrace
jik@Athena.MIT.EDU				Allston, MA  02134
Office: 617-253-8495			      Home: 617-782-0710
-----------[000016][next][prev][last][first]----------------------------------------------------
From:      krfall@ucsd.edu  15-AUG-1990 13:10:53
To:        EVERHART@arisia.dnet.ge.com
Cc:        security@pyrite.rutgers.edu
> If looking for a secure distributed file system, I'd suggest checking
> out AFS, from Transarc. It uses Kerebros authentication

The currently released version (3.0) does not yet use Kerberos (at
least so I have been told).
That would be the case for the AFS being released through Mt. Xinu as
well.  Project Athena has modified the authentication program
(klog?) to produce one which scrawls a v4 Kerberos ticket inside
the AFS tokens (aklog), and made corresponding changes for their
server software.

AFS 4 is evidently on the way from Transarc,
as is v5 Kerberos from Athena.  One might expect a merger
of these systems in the future.
These ideas are also being monitored by the Distributed File Systems
working group of the IETF (dfs-wg-request@citi.umich.edu).

- Kevin
-----------[000017][next][prev][last][first]----------------------------------------------------
From:      Harry Flowers <FLOWERS@memstvx1.bitnet>  15-AUG-1990 13:26:18
To:        security@pyrite.rutgers.edu
It seems that most of the replies to requiring password changes came back
against them, and some wondered why, if you have a good password, you should
be required to change it.

One of the computer operating systems here (not a VAX/VMS system) has recently
added a password expiration feature.  Because "the auditors" (cringe) wanted
this, it was implemented.  One surprising thing it turned up was there were a
number of people who had been sharing accounts for years who were not aware of
all the others using the same account... once the password changed, the others
couldn't get in.  These "good" passwords had been shared over time, and rather
than go to the trouble of requesting another account (not much trouble), they
shared accounts.

This, of course, was a problem caused by bad password practices, not bad
passwords.  And, if someone should happen to learn a password by whatever
means, be it a "good" or "bad" one, users may not notice that others are
using their account (how many of us look carefully at the last login date?).

The main advantage of frequent password changes is that if someone does happen
to see you type in your password or learn it by capturing network traffic, etc.,
no matter how careful they are to work undetected, they will eventually be shut
out of your account when you change the password.  Those of us with privileged
accounts have to be extra-careful, as other means of getting in can be set-up
from privileged accounts.  But your users are the ones least likely to realize
that their accounts have been compromised.

     "A password is like a toothbrush: you never share it and you get
                                       a new one every three months."

._   _.  .___.  ._. ._.  v------------------------------------------------+
| \ / | / ____\ | | | |  | Harry Flowers             Phone: (901)678-2663 |
||\v/|| \____ \ | |_| |  | Bitnet: FLOWERS@MEMSTVX1    Systems Programmer |
|| v || \_____/ \_____/  | Internet: not yet :-(, but soon :-)    VAX/VMS |
Memphis State University | USmail: 112 Admin Bldg, MSU, Memphis, TN 38152 |
                         ^------------------------------------------------+

P.S. We are going on the Internet soon using WIN TCP/IP.  I'd appreciate any
     information as to security problems we might encounter.  Thanks.
-----------[000018][next][prev][last][first]----------------------------------------------------
From:      "Andrew A. Houghton" <ah0i+@andrew.cmu.edu>  17-AUG-1990  2:25:15
To:        security@rutgers.edu
I know this subject has probably been run into the ground, but could
people please send me the addresses for good locksmithing schools,
along with any thoughts they have about them (like relative merits,
etcetera)

Please e-mail, no need to post on the net.

Andrew Houghton
(ah0i@andrew.cmu.edu)
-----------[000019][next][prev][last][first]----------------------------------------------------
From:      ctdonath@rodan.acs.syr.edu (Carl T. Donath)  17-AUG-1990  2:42:54
To:        security@pyrite.rutgers.edu
Does anyone know where I could buy a simple alarm like this: a small box
is attached onto/inside some hardware (a computer, VCR, whatever) that
will sound an alarm when it detects motion (by tilting, acceleration, 
whatever). It must run off a battery and be quite hard to disable.

Where can I buy one?

- Carl
-----------[000020][next][prev][last][first]----------------------------------------------------
From:      tep@tots.logicon.com (Tom Perrine)  17-AUG-1990  3:13:15
To:        security@pyrite.rutgers.edu
I have one of those cheap Master combination locks that I need to
remove, and the combination is long gone.

The options I can think of are (in order of preference):
	get combination from Master (from serial number)
	bolt cutters
	hacksaw

Of course, the cheaper the better, so a locksmith is out. I'm not in
any hurry, can I just call (or write) to Master and get the
combination? I really don't care about the lock, but if I can get the
combo, thats easier than finding some bolt cutters or spending an
hour? with a hacksaw....

Any recommendations?

Tom Perrine (tep)
-----------[000021][next][prev][last][first]----------------------------------------------------
From:      Paul V Hardiman <hardiman@csd4.csd.uwm.edu>  18-AUG-1990  0:45:31
To:        security-request@pyrite.rutgers.edu
I need to get information on the Kerberos security system.  Can you
give me the Internet address of a group or individual who can send
me this information?

Thank you
-----------[000022][next][prev][last][first]----------------------------------------------------
From:      Abhik Biswas <JUTBAAA@iup.bitnet>  18-AUG-1990  1:07:06
To:        security@ohstvma.bitnet
Are there any archives of papers related to computer security either at sites
on Internet or Bitnet? Any information will be appreciated.
-----------[000023][next][prev][last][first]----------------------------------------------------
From:      brendan@world.std.com (Brendan P Kehoe)  18-AUG-1990  1:26:06
To:        security@rutgers.edu
 You can get a copy of it (the "Orange Book") from gatekeeper.dec.com via
anon ftp in the directory pub/misc (if I remember right).

-- 
Brendan Kehoe | Soon: brendan@cs.widener.edu | temp: brendan@world.std.com
Also: brendan@chinet.chi.il.us | Preferred: bkehoe@widener.bitnet
-----------[000024][next][prev][last][first]----------------------------------------------------
From:      Paul Goodwin <PGOODWIN@gtri01.gatech.edu>  18-AUG-1990  1:46:50
To:        MISC-SECURITY%LOCAL@gatech.edu
The point at which you are most likely to identify that someone is
breaking into a system is while that person is attempting to gain
access to an account.  Once he has an account USERID and PASSWORD,
detection becomes much more difficult.  Making the authorized users
of a system periodically change their passwords may suddenly deny access
to an unauthorized user, causing him to once again 'hack' at the system
until he gains entry.  This will make him much more visible, and much more
likely to be caught.

Disclaimer: I am, of course, speaking solely for myself.

Paul Goodwin
Office of Computing Services
Ga. Inst. of Technology
-----------[000025][next][prev][last][first]----------------------------------------------------
Date:      16 Aug 90 19:34:55 GMT
From:      cb2s+@ANDREW.CMU.EDU (Christopher Gene BeHanna)
To:        misc.security
Subject:   Re: "secure nfs"

Someone suggested AFS from Transarc.  AFS has all the production capability
of beta-test software.  Being an administrator for it is a hell of a headache
because AFS loses track of the different states of volumes in memory and in
the vldb and they frequently get out of synch.  The backup program is trash.
I'd suggest holding out until several sites get 4.0 and see how things work
out.

Chris BeHanna
These opinions are my own, not those of Carnegie Mellon or Pittsburgh
Supercomputing Center, formulated by administering AFS this summer on
pmaxen.

-----------[000026][next][prev][last][first]----------------------------------------------------
Date:      17 Aug 90 19:13:56 GMT
From:      denbeste@bgsuvax.UUCP (William C. DenBesten)
To:        misc.security
Subject:   Re: cheap Master combo lock

There exists a book that lists all of the combinations by serial
number.  Many locksmiths have this book.  If you can demonstrate that
you own the lock, they may look it up for you.  I find it scary that
the relationship exists.

Personally, I prefer to use key locks with the serial/key number
written in ink (I erase the number) or to use locks for which I set
the combination.  At least someone can't look up the number in a handy
book.

-- 
William C. DenBesten   is   denbeste@bgsu.edu  or   denbesten@bgsuopie.bitnet

-----------[000027][next][prev][last][first]----------------------------------------------------
Date:      17 Aug 90 20:46:39 GMT
From:      truel@IUVAX.CS.INDIANA.EDU (Bob Truel)
To:        misc.security
Subject:   Re: cheap Master combo lock

Have you tried taking a shoe with a good hard rubber sole to it?  Back
in high school, I saw someone open a master lock like this.  I never
tried it on my own, nor anyone elses, and can't guarantee that it will
still work, but I never lock anything valuable with one.

-----------[000028][next][prev][last][first]----------------------------------------------------
Date:      17 Aug 90 20:55:00 GMT
From:      WURZBACH@OSHKOSH.WISC.EDU ("William F. Wurzbach")
To:        misc.security
Subject:   RE: cheap Master combo lock


        I had the same problem about a year ago and the solution was painless.
Go to the nearest hardware store that handles MasterLock locks. Explain to
someone there ( I approached the key-making department ) what the problem is,
get the address of the nearest MasterLock outlet or corporate headquarters,
and write a letter to them, explaining who you are, what the serial number of
the combination lock is, and giving the full address of the hardware store
you have made accommodations with. MasterLock will send the combination to
the hardware store ( authorized dealer ), where you can have them call you
or stop in periodically to check if it's arrived. No problem if you've got
the time.

-----------[000029][next][prev][last][first]----------------------------------------------------
Date:      18 Aug 90 17:44:58 GMT
From:      jkp@SAUNA.HUT.FI (Jyrki Kuoppala)
To:        misc.security
Subject:   Re: Papers on computer security....

I have put some security articles I have for anonymous ftp in
nic.funet.fi [128.214.6.100] directory pub/doc/security.

//Jyrki

-----------[000030][next][prev][last][first]----------------------------------------------------
Date:      18 Aug 90 19:24:57 GMT
From:      black@darkside.com (Black Death)
To:        misc.security
Subject:   (none)


        Yes, but if the users choose good passwords, there won't be much 
chance of anyone getting in at all. One good method is using a variety of 
upper & lower case (ie pAsSwOrD) on UNIXs that will alow you to do that. 
Another system which would make it nearly impossible to hack (beleive me, I 
know) would be to take two words, combine them together and add a two-digit 
number to the end (ie RUNWALK23)..If password security is not enough for 
your system you may wish to invest in a filter 
device, which will dramaticly reduce the numbe of people who even make it to 
the "password:" prompt. It is important, however, that even when you get one 
of these, you must still use good passwords.  That should drasticly reduce 
the amount of unwanted visitors on your system.

-----------[000031][next][prev][last][first]----------------------------------------------------
From:      black@darkside.com (Black Death)  21-AUG-1990 15:44:53
To:        misc-security@ucbvax.berkeley.edu
The only instance in which I have seen computer equipment confiscated is 
when the person in question is suspected of commiting some computer related 
crime. The situation you are talking about where your equipment was 
confiscated because it "should not be in the hands of the general public" is 
totaly disgusting. I do not know what it could be that you have that could 
pose such a huge threat to the telecommunications industry. What is it? 

bd/pha
-----------[000032][next][prev][last][first]----------------------------------------------------
From:      pmorriso@gara.une.oz.au (Perry Morrison MATH)  21-AUG-1990 16:12:24
To:        misc-security%munnari.mu.oz@munnari.oz.au
I'm interested in researching the nature, history, extent and motivations
behind computer "crime". I'm not sure how to define it at this stage (that
should happen after I've digested a much larger range of views), however I'm
interested in researching system break-ins, computer based fraud and monetary
or property theft, the history and alternative viewpoints behind hacking,
unauthorised copying of software, viruses and any other topic that (at least in
the eyes of some) verges on criminality.

Pointers to key articles, journals, summaries of the literature or even
isolated opinions would be greatly appreciated.

Please don't flame this rather naive request. My opinions are pretty much
unformed (and uninformed) at the moment, so any information can only help.

I'd be happy to post a summary of what I get. Pointers to key personalities
or researchers would also be extremely useful.

Perry Morrison
-----------[000033][next][prev][last][first]----------------------------------------------------
From:      <BRUGGMNJ@xavier.bitnet>  21-AUG-1990 16:40:56
To:        security@pyrite.rutgers.edu
    Actually I do know of a professor here at Xavier University that did
request his FBI folder. As I recall he had the assistance of a lawyer and
it took several weeks.  What he got was a folder with newspaper clippings about
him and things his is involved with, plus what looked liked memos and notes.
Now not all of this was readable, somethings the FBI deemed 'classified' and
had blackened out words or phrases or sometimes the whole document. So you
could say he got the full folder, you just couldn't *read* it all.

There was a funny side to some of this, it seemed the FBI was very curious
about this 'women' that traveled with him.  They said 'women' because while
they are married, she did not take his name.  They thought it might
be worth noting that he traveled with 'another' women.  That's about all I
have.
John

John Bruggeman  Programmer/Analyst
bruggmnj@xavier.bitnet
Xavier University  Cincinnati, OH

'Cincinnati, the only city where the only sin allowed is in the name!'
J.B.
-----------[000034][next][prev][last][first]----------------------------------------------------
Date:      20 Aug 90 23:23:06 GMT
From:      hollombe@ttidca.tti.com (The Polymath)
To:        misc.security
Subject:   Re: cheap Master combo lock

Use the hacksaw.  If it's a cheap Master lock you should be able to cut
through it in under five minutes.

-- 
The Polymath (aka: Jerry Hollombe, M.A., CDP, aka: hollombe@ttidca.tti.com)
Head Robot Wrangler at Citicorp(+)TTI             Illegitimis non
3100 Ocean Park Blvd.   (213) 450-9111, x2483       Carborundum
Santa Monica, CA  90405 {csun | philabs | psivax}!ttidca!hollombe

-----------[000035][next][prev][last][first]----------------------------------------------------
From:      smb@ulysses.att.com (Steven Bellovin)  23-AUG-1990 10:18:01
To:        misc-security@att.att.com
> ... would most assuredly prompt them to open a
> new one. (1/2 :-)

It should be a zero smiley; the statement is quite literally and definitely
true.  They have a special category for Freedom of Information Act requests
in their filing system.  (Source:  the ACLU.)
-----------[000036][next][prev][last][first]----------------------------------------------------
From:      dee@xait.xerox.com (Donald Eastlake)  23-AUG-1990 10:32:07
To:        misc-security@linus.mitre.org
I have not actually done this but, as I recall, there is a way to send
a set of your own fingerprints along with a small fee to the FBI and have
them send you back a listing of all the times your fingerprints have been
filed/looked up through them.  This document is traditinally called a "rap
sheet" because for someone who has been frequently arrested it would mostly
be a list of the arrests since you are usually fingerprinted when arrested.
The info is sent back by Registered Mail, deliver to addressee only, so you
have to show ID when the post office delivers it.  I don't know if the last
entry will be your query or if that's added after the query is processed.
-- 
	+1 617-969-9570		Donald E. Eastlake, III
	ARPA: dee@XAIT.Xerox.COM    usenet:  {cbosg,decvax,linus}!cca!dee
	AppleLink:  D2002	Box N, MIT Branch PO, Cambridge, MA 02139 USA
-----------[000037][next][prev][last][first]----------------------------------------------------
From:      edelheit@smiley.mitre.org (Jeff Edelheit)  23-AUG-1990 10:51:06
To:        don@delta.com
Cc:        security@pyrite.rutgers.edu
Gould's UNIX was evaluated and certified at the C2 level a long time
ago.  AT&T's System V/MLS was evaluated and certified at the B1 level
last September.  There are several other vendor's versions of UNIX
that are in evaluation at the B1 level. 

I would not associate a C2 as a "poor" rating.  Rather, C2 provides
discretionary access control, audit and several other security services.
The significance of B1 and above is that B1 systems provide mandatory
access control.  In most systems, mandatory access control is implemented
on a label-based mechanism.  This means if the user has a label attached 
to him/her at the "Unclassified" level, there are sufficient mechanisms
and assurances that the user cannot access information (e.g., files, 
directories) at the "Secret" level.  Honeywell's SCOMP was evaluated and
certified at the A1 level and Honeywell's XTS-200 is under evaluation
at the B3 level.

Regards,

Jeff Edelheit           (edelheit@mitre.org)
The MITRE Corporation   7525 Colshire Drive
McLean, VA   22102
-----------[000038][next][prev][last][first]----------------------------------------------------
From:      smb@ulysses.att.com  23-AUG-1990 11:03:53
To:        security@rutgers.edu
Anyone can write to the FBI requesting a copy of their files
under provisions of the Freedom of Information Act.  With some
exceptions, they are obligated to send the files to you.  If they don't
have a file on you when you send in your request, they'll open one, in
the FOIA section.  There's some mumbo-jumbo you're supposed to include
to make sure they check all of the categories, but I don't recall what
that is.  They will delete names of other people if mention would
violate their privacy.  They're also entitled to delete material
pertaining to active criminal investigations, or ``national security''
information.

This info is from memory, but taken from a ACLU newsletter.  As I
recall, they also publish a booklet on the FOIA; if you're serious
about getting your FBI files, I'd try to get the booklet first.  In
general, the government is entitled to collect a modest per-page charge
for FOIA requests, but I'm not sure if that applies to requests of this
nature.

		--Steve Bellovin

P.S.  No, I've never gotten around to asking for my own files, though
I keep meaning to.  I'm not even sure what I want to find out -- if
there's no file on me, it would indicate that I didn't speak up loudly
enough or forcefully enough during my activist days 20 years ago....
-----------[000039][next][prev][last][first]----------------------------------------------------
From:      faigin@aerospace.aero.org  23-AUG-1990 11:17:32
To:        security@rutgers.edu
Cc:        don@delta.com
Generic Unix has no rating, only specific implementations. The only UNIX
systems on the evaluated products list are:

System				Evaluation Date		Rating
Gould UTX/32S rel 1.0		31 Dec 86		C2
AT&T System V/MLS v1.1.2 on
  UNIX SVR3.1.1 running on
  3B2/500 or 3B2/600		07 Sep 89		B1

Standard UNIX System V has no rating.

Also, C2 is not a "poor" rating by any means. C2 is the best rating that a
UNIX system can get without adding support for Mandatory Access Control.

Assuming an evaluation, operating system extensions can easily extend Unix to
C2, by adding appropriate support for auditing, identification and
authentication, and assurances such as documentation, and testing. B1 can also
be reached easily by adding MAC support. B2 is much harder, because the
assurance requirements state:

   The TCB shall be internally structured into well-defined largely
   independent modules.  It shall make effective use of available hardware to
   separate those elements that are protection-critical from those that are
   not.  The TCB modules shall be designed such that the principle of least
   privilege is enforced.  Features in hardware, such as segmentation, shall
   be used to support logically distinct storage objects with separate
   attributes (namely: readable, writeable).  The user interface to the TCB
   shall be completely defined and all elements of the TCB identified.

UNIX is not well structured internally; reworking a UNIX implementation to B2
would require rewriting major chunks of the kernel.

>I've not heard of an out-of-the-box implementation in the A classification...

First of all, there is only one A classification. On the EPL, there is only
one A1 system, which was the first evaluated system, which is no longer
marketed. If there were more A1 systems on the EPL, they would certainly be
"out of the box" systems.

Daniel
-----------[000040][next][prev][last][first]----------------------------------------------------
From:      guhsd000@crash.cts.com (Paula Ferris)  24-AUG-1990  0:02:01
To:        misc-security@ucsd.edu
Someone stole my book on the subject, but under the Freedom of Information Act,
federal agencys are required to release information gathered by the agency in
anyform, in most circumstances.  There are set time limits on when the
information is released, (I think the time is started when you make a formal
request for the documentation) and can take a long time to clean, and clear the
red tape.  I belive CBS just recived some information pertaininto Vietnam
requested in the 70's only this year.

I'm sorry I can't be more help, but basically, as I recall, you make a formal
request on paper (Keep a copy) to the records center of the department,
and demand the information, (this is important) including all pages,
title pages, blank pages, markers, notes and tabs, fron and back.

They do have a few exclusions they can hide behind, the FBI is the most
frequent user of these.  They are allowed to edit out any information
that they deem may demonstrate internal workings or investigative
operations of their department.  Besure to request edited pages, and again,
demand, an explanation of EACH edit.

You can also ask that fees be waived, they usally are if the file is small.

I don't recall the time limits and formalities of processing, but sooner
or later it has to come out, but they are great at stalling, and don't
expect much, in FOIA's from the FBI I've examined, they have often
taken a page, Photocopied it, go over each line with a black marker,
and re-copied it, and included it in the requested document as edited.

Explanation and Justification of each edit can help you piece together what
they edited out by looking up the section numbers under which they
will give as justification, usally the one pertaining to the protection
of information gathering techniques.

Hale Telecommunications Incorperated - KKLR & KALE
-----------[000041][next][prev][last][first]----------------------------------------------------
From:      "Michael J. Chinni, SMCAR_CCS_E" <mchinni@pica.army.mil>  24-AUG-1990  0:24:27
To:        security@pyrite.rutgers.edu
-------------
To: cert-tools@cert.sei.cmu.edu
Subject: Sun Microsystem's Warning System
Date: Wed, 15 Aug 90 15:01:04 EDT
From: Richard Pethia <rdp@cert.sei.cmu.edu>

CERT Tools members,

At the June 1990 Workshop on Computer Security Incident Handling, Sun
Microsystems announced their intent to implement a Customer Warning
System and described several of its characteristics.

Yesterday, the CERT/CC at the SEI received the announcement below.
The announcement, distributed internally to Sun employees, provides
more information on the characteristics of the warning system, and,
more importantly, describes the methods Sun Microsystem's customers
should use to report problems and to sign up to receive warnings from
Sun Microsystems.

Beverly Ulbrich, Sun Product Manager, Software Security, has told us
that a formal press release will probably be released by Sun, but has
asked us to redistribute this announcement to the lists we maintain.  
We are doing so to provide people with information on Sun's action.

Sun's Customer Warning System promises to be a significant step
forward in dealing with computer security incidents and their
prevention, and represents the type of action I would like to see
other vendors take.  

Since the CERT/CC will be actively working with other vendors this
fall and encouraging them to take similar steps, please let me know
about any opinions you have regarding this type of vendor mechanism.

Please direct any questions you have about the specifics of Sun's
mechanism to one of the Sun employees listed below.

Sincerely,
Rich Pethia
CERT Coordinator
---------------------------------------------------------------------

To: All Sun Employees 

From: Beverly Ulbrich - Product Manager, Software Security
      Jack Collins - Director, Technical Support Services

Subject:  Announcing Sun Microsystem's Customer Warning System 
                   for Security Incident Handling  

Date:   August 14, 1990

In order to best serve our customers' service needs, Sun has established a 
Customer Warning System (CWS) for handling security incidents.  This is a 
formal process which includes:
	- Having a well advertised point of contact in Sun for reporting 
	  security problems. 			
	- Pro-actively alerting customers of worms, viruses or other security 
	  holes that could affect their systems. 
	- Distributing the patch (and/or work-around) to our customers as 
	  quickly as possible.

More specifically, the CWS is being set up as follows:

We have created an email address ( security-alert@sun ) which will enable 
both internal and external people to have a single place to report security 
problems.  We have provided a voice-mail back-up ( (415)-336-7205 ) for the 
cases where sending email is not possible.   *ALL* SECURITY HOLES SHOULD BE 
REPORTED TO THIS ALIAS.

We have filled the position of "Security Coordinator" in our Customer Service 
Organization.  The Security Coordinator is responsible for manning the email 
and voice mail hotlines and evaluating the security problems.   We have a 
Customer Warning System "SWAT Team" in place to address severe security 
incidents.  The CWS SWAT Team consists of knowledgeable senior people within 
Sun Corporate who are committed to being available to meet whenever required 
and who are empowered to make all necessary decisions.  

We plan on publicizing the CWS bi-monthly to the allsun alias.  It will 
also be announced (and supported) by the various Computer Emergency Response 
Teams Sun works with.  Please pass this information along to whoever you 
feel is appropriate.  Sales Representatives should be certain to send this 
information to all their security-conscious customers!

Customers and Sun Field Offices may send us a "Security Contact" from their
organizations.  This is the person Sun should contact in the case of any 
new security problems.  He or she will be sent information on the problem at 
hand, including work-arounds and how and when to obtain fixes.  Preferably, 
your Security Contact should be technical.  He or she should be your site's 
System Administrator (or System Security Administrator).  The information we 
need for the Security Contact from the three geographies for customers is as 
follows:

---------------------- U.S. Security Contact Information --------------------

Company Name:
Security Contact's Name:
Customer Number (from Cullinet):
Address ID (from Cullinet)*:

Postal address: 
Email address: 
Phone number:
Fax number: 
Preferred method of contact (from above: 1st, 2nd and 3rd choice):

* If there is not an existing Address ID, we need the full address for
  the security contact.

----------------- Europe and ICON Security Contact Information ---------

Company Name:
Security Contact's Name:
Customer Number:
Address Id:
If there is no customer number or Address ID, then we need the following
information for each customer:

Postal Address:
Email Address:
Phone Number:
Fax Number:
Preferred method of contact (from above: 1st, 2nd and 3rd choice):

--------------- Sun Field Office Security Contact Information ---------------

Office Location:
Security Contact's Name*:
Email address:

*One per office

----------------------------------------------------------------------------

*****   PLEASE SEND THIS INFORMATION TO:   *****

 	  security-alert@sun.com
  
or, if you prefer postal mail:

	Brad Powell
	c/o Sun Microsystems
	MTV18-04
	2550 Garcia Ave.
	Mt. View, CA 94043

All questions should be sent to bju@sun.com.

 **CERT-Tools Information:****************************************************
 * Submissions                         : cert-tools@cert.sei.cmu.edu         *
 * Address additions/deletions/changes : cert-tools-request@cert.sei.cmu.edu *
 * Moderator                           : tools@cert.sei.cmu.edu              *
 *****************************************************************************
-----------[000042][next][prev][last][first]----------------------------------------------------
From:      Simon Travaglia <CCC_SIMON@waikato.ac.nz>  24-AUG-1990 14:57:43
To:        security@rutgers.edu
Hi There.
	We use a Chubb 8108 system controlling 3 Chub 8100 door controllers,
and here's our problem.  Every now and then (we've had them since December
1989) one of the 8100s will go haywire and start running (on the two doors
it controls) through a cycle of <Locked>,<Enter PIN>,<Unlocked>.  During
the unlock part, the door will be unlocked for about half a second.

The cycling will continue until the unit has been reset.  We would like
to know if anyone else has had this problem, as it can be a real pain.
The Chubb guys said it was bad earthing, then 2 months later it was back
again, after the problem had apparently been fixed.

Anyone got any ideas.
-----------[000043][next][prev][last][first]----------------------------------------------------
From:      "Larry Margolis" <MARGOLI@ibm.com>  24-AUG-1990 15:20:57
To:        security@pyrite.rutgers.edu
When I had to do something similar a few years ago, (we had students
coming in for 1 to 3 month classes; we'd have to create a block of
between 20 and 300 userids before the class, and delete them afterwards),
I wrote an exec that would be given the class number (which determined
the student prefix), and the number of IDs needed, and it would
(1)  Create that number of userids, from XYZ001 to XYZnnn;
(2)  Create a SCRIPT file that printed off a Welcome to the Computer
     letter, specifying their userid and randomly generated password; and
(3)  Printed out mailing labels for these letters.

It could also be called to delete the userids en mass after the class
was over.

It's all pretty easy.  The only time-consuming thing was tracing through
DIRMAINT and all the stuff it calls until I located the DVH module that
actually sent the DIRM ADD request to the DIRMAINT machine.  I then
called that routine directly.  That way, my exec could ask for the
privileged user's password once, and use it for all the calls to the
lower-level module.

(Eventually, I got fancy, and had the exec pass the arguments to a
privileged service machine, which would do all the DIRM requests, and
interpret the output and only bother me if anything went wrong.  It would
also by default (could be overridden) wait until 2:00 AM to issue the
request, so that the DIRMAINT service machines wouldn't be tied up
adding hundreds of users during prime shift.)

Larry Margolis, MARGOLI@YKTVMV (bitnet), MARGOLI@IBM.COM (csnet)
-----------[000044][next][prev][last][first]----------------------------------------------------
From:      simsong@next.cambridge.ma.us (Simson L. Garfinkel)  28-AUG-1990  4:31:20
To:        hardiman@csd4.csd.uwm.edu
Cc:        security-request@pyrite.rutgers.edu
You can FTP papers on Kerberos from athena-dist.mit.edu
-----------[000045][next][prev][last][first]----------------------------------------------------
From:      Christopher Gene BeHanna <cb2s+@andrew.cmu.edu>  28-AUG-1990  5:04:08
To:        security@pyrite.rutgers.edu
Someone suggested AFS from Transarc.  AFS has all the production capability
of beta-test software.  Being an administrator for it is a hell of a headache
because AFS loses track of the different states of volumes in memory and in
the vldb and they frequently get out of synch.  The backup program is trash.
I'd suggest holding out until several sites get 4.0 and see how things work
out.

Chris BeHanna
These opinions are my own, not those of Carnegie Mellon or Pittsburgh
Supercomputing Center, formulated by administering AFS this summer on
pmaxen.
-----------[000046][next][prev][last][first]----------------------------------------------------
From:      simsong@next.cambridge.ma.us (Simson L. Garfinkel)  28-AUG-1990  5:23:54
To:        jpc@fctunl.rccn.pt
Cc:        security@pyrite.rutgers.edu
Under the Freedom of Information Act and the Privacy Act, they are
required to send you the entire folder, with a few exceptions:

	1. Ongoing investigations are exempt.
	2. Information that could endanger field operatives may be censored.
	3. Other "classified" information can be removed.

Most people, turns out, don't have FBI folders on them.  Unless you
lived in the 1950s and 1960s and were an activist, that is.  If you
did, you can get your folder by contacting your local FBI office; they
have an address that you can send a notorized letter to asking for
your folder.  You have to provide some personal information, but not a
whole lot.

I did it; I didn't have a folder (at the time), disproving the
assertion that all MIT students automatically get FBI folders when
they register.
-----------[000047][next][prev][last][first]----------------------------------------------------
From:      Bob Truel <truel@iuvax.cs.indiana.edu>  29-AUG-1990  6:11:17
To:        misc-security@rutgers.edu
Have you tried taking a shoe with a good hard rubber sole to it?  Back
in high school, I saw someone open a master lock like this.  I never
tried it on my own, nor anyone elses, and can't guarantee that it will
still work, but I never lock anything valuable with one.
-----------[000048][next][prev][last][first]----------------------------------------------------
From:      pmartin@mcc.com  29-AUG-1990  6:32:27
To:        tep@tots.logicon.com, security@pyrite.rutgers.edu
For "locker" style Master combo locks, you can probably doe the
combinatorics of the "soft spots" on it in under 10 minutes.
Some of the newer ones seem to have an extra mechanism to make it harder
to detect these points.... I've taken to actually writing down my combo
with these as it is such a pain to discover the combo from
experimentation...  Even so, the right answer is to figure out the combo
rather than use any of the cruder methods you listed.

Paul
-----------[000049][next][prev][last][first]----------------------------------------------------
From:      joe jesson <jej@chinet.chi.il.us>  29-AUG-1990  6:54:50
To:        misc-security@uunet.uu.net
 I need to connect a large network to annother very large network through
RSCS-to-RSCS and would like (no must) look at the exposure (read potential
hackers sending worms, virus, etc.) of our network and business files (CMS).

The infamous "Christmas Card" fiasco on the IBM network make me nervous. The
overall intent of hooking-up the networks is to send mail (Interenterprise
electronic mail project).

Any ideas on how the system may be compromised? Risk Level????

-joe                
-----------[000050][next][prev][last][first]----------------------------------------------------
From:      bgsuvax!denbeste@cis.ohio_state.edu (William C. DenBesten)  29-AUG-1990  7:17:50
To:        osu-cis!misc-security@cis.ohio-state.edu
There exists a book that lists all of the combinations by serial
number.  Many locksmiths have this book.  If you can demonstrate that
you own the lock, they may look it up for you.  I find it scary that
the relationship exists.

Personally, I prefer to use key locks with the serial/key number
written in ink (I erase the number) or to use locks for which I set
the combination.  At least someone can't look up the number in a handy
book.

-- 
William C. DenBesten   is   denbeste@bgsu.edu  or   denbesten@bgsuopie.bitnet
-----------[000051][next][prev][last][first]----------------------------------------------------
From:      Homer <CTM@cornellc.bitnet>  29-AUG-1990  7:41:24
To:        "Security List." <security@pyrite.rutgers.edu>
     When I was a kid, a fellow camper showed me how to crack the
standard everywhere present master combo lock.

     Basically the idea was to find the first number by pulling
the shank out and turning the knob.  It would click or stick or
feel different at the place that corresponded to the first
number.

     The third number was easy to find, assuming you had the first and
second number, all you had to do was turn the dial until the shank pulled
open.

     Finding the second number was a matter of trying each one, not
that many.  It made it even easier in that the second number was
'accurate' only to 2 digits, so you only had to try every other
position to get the right one.

     I opened many a master lock this way.
-----------[000052][next][prev][last][first]----------------------------------------------------
From:      "William F. Wurzbach" <WURZBACH@oshkosh.wisc.edu>  29-AUG-1990 14:46:35
To:        security@pyrite.rutgers.edu
        I had the same problem about a year ago and the solution was painless.
Go to the nearest hardware store that handles MasterLock locks. Explain to
someone there ( I approached the key-making department ) what the problem is,
get the address of the nearest MasterLock outlet or corporate headquarters,
and write a letter to them, explaining who you are, what the serial number of
the combination lock is, and giving the full address of the hardware store
you have made accommodations with. MasterLock will send the combination to
the hardware store ( authorized dealer ), where you can have them call you
or stop in periodically to check if it's arrived. No problem if you've got
the time.

END OF DOCUMENT