----MESSAGE-BEGIN---- [9008120058.AA20826@ucbarpa.Berkeley.EDU] <1990080103000000> From: WHMurray@DOCKMASTER.NCSC.MIL Newsgroups: misc.security Subject: ITSEC Message-ID: <9008120058.AA20826@ucbarpa.Berkeley.EDU> Date: 1 Aug 90 03:00:00 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 132 Approved: security@rutgers.edu Posted: Wed Aug 1 04:00:00 1990 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [9008180158.AA07517@ucbarpa.Berkeley.EDU] <1990080213555400> From: PGOODWIN@GTRI01.GATECH.EDU (Paul Goodwin) Newsgroups: misc.security Subject: break-in detection Message-ID: <9008180158.AA07517@ucbarpa.Berkeley.EDU> Date: 2 Aug 90 13:55:54 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 14 Approved: security@rutgers.edu Posted: Thu Aug 2 14:55:54 1990 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990080315231000> From: barmar@think.com (Barry Margolin) 5-AUG-1990 0:33:10 To: misc-security@husc6.harvard.edu Subj: [449] Re: "Secure NFS" 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. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990080315412400> From: EVERHART@arisia.dnet.ge.com 5-AUG-1990 0:51:24 To: security@pyrite.rutgers.edu Subj: [417] "secure nfs" 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990080315591900> From: DANCC@cunyvm.cuny.edu 5-AUG-1990 1:09:19 To: SECURITY@rutgers.edu Subj: [711] Request vendor info on CPU "cage" 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. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990080316153800> From: de5@stc06.ctd.ornl.gov (SILL D E) 5-AUG-1990 1:25:38 To: misc-security@ucbvax.berkeley.edu Subj: [880] Re: Authentication of electronic commercial documents >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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990080413270000> From: GREENY 5-AUG-1990 22:37:00 To: Subj: [521] re: Oregon Scientific Address/Phone# 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990080413562100> 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 Subj: [650] Re: Authentication of electronic commercial documents 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 | ----MESSAGE-END---- ----MESSAGE-BEGIN---- [9008180119.AA07069@ucbarpa.Berkeley.EDU] <1990080418480000> From: JUTBAAA@iup.BITNET (Abhik Biswas) Newsgroups: misc.security Subject: Papers on computer security.... Message-ID: <9008180119.AA07069@ucbarpa.Berkeley.EDU> Date: 4 Aug 90 18:48:00 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 2 Approved: security@rutgers.edu Posted: Sat Aug 4 19:48:00 1990 Are there any archives of papers related to computer security either at sites on Internet or Bitnet? Any information will be appreciated. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [9008151319.AA17842@ucbarpa.Berkeley.EDU] <1990080505140700> From: krfall@UCSD.EDU Newsgroups: misc.security Subject: Re: "secure nfs" Message-ID: <9008151319.AA17842@ucbarpa.Berkeley.EDU> Date: 5 Aug 90 05:14:07 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 18 Approved: security@rutgers.edu Posted: Sun Aug 5 06:14:07 1990 > 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [9008151246.AA17597@ucbarpa.Berkeley.EDU] <1990080701232700> From: jpc@fctunl.rccn.pt (Jose Pina Coelho) Newsgroups: misc.security Subject: Re: criminal record Message-ID: <9008151246.AA17597@ucbarpa.Berkeley.EDU> Date: 7 Aug 90 01:23:27 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 6 Approved: security@rutgers.edu Posted: Tue Aug 7 02:23:27 1990 > 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*] ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990081015211800> From: annala@neuro.usc.edu (A J Annala) 12-AUG-1990 0:31:18 To: misc-security@ucbvax.berkeley.edu Subj: [534] Telephone Access Devices 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990081015381800> From: WHMurray@dockmaster.ncsc.mil 12-AUG-1990 0:48:18 To: security@rutgers.edu Subj: [6573] 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990081403060400> From: Jim Pinson 15-AUG-1990 12:16:04 To: security@pyrite.rutgers.edu Subj: [327] On the subject of hard to guess passwords 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. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990081403265000> From: jpc@fctunl.rccn.pt (Jose Pina Coelho) 15-AUG-1990 12:36:50 To: security@pyrite.rutgers.edu Subj: [266] 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*] ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990081403432400> From: jik@athena.mit.edu (Jonathan I. Kamens) 15-AUG-1990 12:53:24 To: security@pyrite.rutgers.edu Subj: [512] Re: criminal record |> 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990081404005300> From: krfall@ucsd.edu 15-AUG-1990 13:10:53 To: EVERHART@arisia.dnet.ge.com Subj: [779] Re: "secure nfs" 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990081404161800> From: Harry Flowers 15-AUG-1990 13:26:18 To: security@pyrite.rutgers.edu Subj: [2309] Passwords 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. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990081517151500> From: "Andrew A. Houghton" 17-AUG-1990 2:25:15 To: security@rutgers.edu Subj: [298] locksmithing schools 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) ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990081517325400> From: ctdonath@rodan.acs.syr.edu (Carl T. Donath) 17-AUG-1990 2:42:54 To: security@pyrite.rutgers.edu Subj: [313] Simple alarm 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990081518031500> From: tep@tots.logicon.com (Tom Perrine) 17-AUG-1990 3:13:15 To: security@pyrite.rutgers.edu Subj: [572] cheap Master combo lock 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) ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990081615353100> From: Paul V Hardiman 18-AUG-1990 0:45:31 To: security-request@pyrite.rutgers.edu Subj: [168] Kerberos 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990081615570600> From: Abhik Biswas 18-AUG-1990 1:07:06 To: security@ohstvma.bitnet Subj: [139] 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. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990081616160600> From: brendan@world.std.com (Brendan P Kehoe) 18-AUG-1990 1:26:06 To: security@rutgers.edu Subj: [279] Re: Different security ratings 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990081616365000> From: Paul Goodwin 18-AUG-1990 1:46:50 To: MISC-SECURITY%LOCAL@gatech.edu Subj: [635] 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [9008280516.AA18119@ucbarpa.Berkeley.EDU] <1990081619345500> From: cb2s+@ANDREW.CMU.EDU (Christopher Gene BeHanna) Newsgroups: misc.security Subject: Re: "secure nfs" Message-ID: <9008280516.AA18119@ucbarpa.Berkeley.EDU> Date: 16 Aug 90 19:34:55 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 11 Approved: security@rutgers.edu Posted: Thu Aug 16 20:34:55 1990 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. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [9008290727.AA18115@ucbarpa.Berkeley.EDU] <1990081719135600> From: denbeste@bgsuvax.UUCP (William C. DenBesten) Newsgroups: misc.security Subject: Re: cheap Master combo lock Message-ID: <9008290727.AA18115@ucbarpa.Berkeley.EDU> Date: 17 Aug 90 19:13:56 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 12 Approved: security@rutgers.edu Posted: Fri Aug 17 20:13:56 1990 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- [9008290619.AA17197@ucbarpa.Berkeley.EDU] <1990081720463900> From: truel@IUVAX.CS.INDIANA.EDU (Bob Truel) Newsgroups: misc.security Subject: Re: cheap Master combo lock Message-ID: <9008290619.AA17197@ucbarpa.Berkeley.EDU> Date: 17 Aug 90 20:46:39 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 4 Approved: security@rutgers.edu Posted: Fri Aug 17 21:46:39 1990 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. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [9008291459.AA20728@ucbarpa.Berkeley.EDU] <1990081720550000> From: WURZBACH@OSHKOSH.WISC.EDU ("William F. Wurzbach") Newsgroups: misc.security Subject: RE: cheap Master combo lock Message-ID: <9008291459.AA20728@ucbarpa.Berkeley.EDU> Date: 17 Aug 90 20:55:00 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 11 Approved: security@rutgers.edu Posted: Fri Aug 17 21:55:00 1990 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. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [9009100905.AA20827@ucbarpa.Berkeley.EDU] <1990081817445800> From: jkp@SAUNA.HUT.FI (Jyrki Kuoppala) Newsgroups: misc.security Subject: Re: Papers on computer security.... Message-ID: <9009100905.AA20827@ucbarpa.Berkeley.EDU> Date: 18 Aug 90 17:44:58 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 4 Approved: security@rutgers.edu Posted: Sat Aug 18 18:44:58 1990 I have put some security articles I have for anonymous ftp in nic.funet.fi [128.214.6.100] directory pub/doc/security. //Jyrki ----MESSAGE-END---- ----MESSAGE-BEGIN---- [9009110612.AA15153@ucbarpa.Berkeley.EDU] <1990081819245700> From: black@darkside.com (Black Death) Newsgroups: misc.security Subject: (none) Message-ID: <9009110612.AA15153@ucbarpa.Berkeley.EDU> Date: 18 Aug 90 19:24:57 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 12 Approved: security@rutgers.edu Posted: Sat Aug 18 20:24:57 1990 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. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990082006345300> From: black@darkside.com (Black Death) 21-AUG-1990 15:44:53 To: misc-security@ucbvax.berkeley.edu Subj: [456] confiscations 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990082007022400> From: pmorriso@gara.une.oz.au (Perry Morrison MATH) 21-AUG-1990 16:12:24 To: misc-security%munnari.mu.oz@munnari.oz.au Subj: [911] Computer "Crime": Resources and Researchers 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990082007305600> From: 21-AUG-1990 16:40:56 To: security@pyrite.rutgers.edu Subj: [1000] FBI folder information. 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. ----MESSAGE-END---- ----MESSAGE-BEGIN---- [9009100957.AA22001@ucbarpa.Berkeley.EDU] <1990082023230600> From: hollombe@ttidca.tti.com (The Polymath) Newsgroups: misc.security Subject: Re: cheap Master combo lock Message-ID: <9009100957.AA22001@ucbarpa.Berkeley.EDU> Date: 20 Aug 90 23:23:06 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 8 Approved: security@rutgers.edu Posted: Tue Aug 21 00:23:06 1990 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990082201080100> From: smb@ulysses.att.com (Steven Bellovin) 23-AUG-1990 10:18:01 To: misc-security@att.att.com Subj: [269] Re: criminal record > ... 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.) ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990082201220700> From: dee@xait.xerox.com (Donald Eastlake) 23-AUG-1990 10:32:07 To: misc-security@linus.mitre.org Subj: [851] Re: criminal record 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990082201410600> From: edelheit@smiley.mitre.org (Jeff Edelheit) 23-AUG-1990 10:51:06 To: don@delta.com Subj: [1029] Re: Different security ratings 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990082201535300> From: smb@ulysses.att.com 23-AUG-1990 11:03:53 To: security@rutgers.edu Subj: [1278] Re: criminal record 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.... ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990082202073200> From: faigin@aerospace.aero.org 23-AUG-1990 11:17:32 To: security@rutgers.edu Subj: [1860] Re: Different security ratings 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990082214520100> From: guhsd000@crash.cts.com (Paula Ferris) 24-AUG-1990 0:02:01 To: misc-security@ucsd.edu Subj: [1841] Re: criminal record 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990082215142700> From: "Michael J. Chinni, SMCAR_CCS_E" 24-AUG-1990 0:24:27 To: security@pyrite.rutgers.edu Subj: [5895] F Y I ------------- 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 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 * ***************************************************************************** ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990082305474300> From: Simon Travaglia 24-AUG-1990 14:57:43 To: security@rutgers.edu Subj: [664] Chubb Locks 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 ,,. 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. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990082306105700> From: "Larry Margolis" 24-AUG-1990 15:20:57 To: security@pyrite.rutgers.edu Subj: [1511] Userid maintenance Automation 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) ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990082619212000> From: simsong@next.cambridge.ma.us (Simson L. Garfinkel) 28-AUG-1990 4:31:20 To: hardiman@csd4.csd.uwm.edu Subj: [57] Kerberos Cc: security-request@pyrite.rutgers.edu You can FTP papers on Kerberos from athena-dist.mit.edu ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990082619540800> From: Christopher Gene BeHanna 28-AUG-1990 5:04:08 To: security@pyrite.rutgers.edu Subj: [552] 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. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990082620135400> From: simsong@next.cambridge.ma.us (Simson L. Garfinkel) 28-AUG-1990 5:23:54 To: jpc@fctunl.rccn.pt Subj: [795] criminal record 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. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990082721011700> From: Bob Truel 29-AUG-1990 6:11:17 To: misc-security@rutgers.edu Subj: [269] 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. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990082721222700> From: pmartin@mcc.com 29-AUG-1990 6:32:27 To: tep@tots.logicon.com, security@pyrite.rutgers.edu Subj: [463] cheap Master combo lock 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990082721445000> From: joe jesson 29-AUG-1990 6:54:50 To: misc-security@uunet.uu.net Subj: [492] IBM RSCS-to-RSCS Communications Hole? 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990082722075000> 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 Subj: [524] 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 ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990082722312400> From: Homer 29-AUG-1990 7:41:24 To: "Security List." Subj: [735] Re: cheap Master combo lock 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. ----MESSAGE-END---- ----MESSAGE-BEGIN---- <1990082805363500> From: "William F. Wurzbach" 29-AUG-1990 14:46:35 To: security@pyrite.rutgers.edu Subj: [697] 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. ----MESSAGE-END----