Computer Underground Digest--Fri Aug 16, 1991 (Vol #3.30) Moderators: Jim Thomas and Gordon Meyer (TK0JUT2@NIU.BITNET) CONTENTS, #3.30 (AUGUST 16, 1991) Subject: File 1--Review: PRACTICAL UNIX SECURITY (Garfinkel and Spafford) Subject: File 2--Review of "Practical Unix Security" (Garfinkel & Spafford). Subject: File 3--Cyberspace and the Legal Matrix: Laws or Confusion? (Reprint) Subject: File 4--Mystery Lurks In The Death of INSLAW Reporter ARCHIVIST: BRENDAN KEHOE RESIDENT CONVALESCENT: BOB KUSUMOTO ULTRA-SCANMEISTER: BOB KRAUSE CuD is available via electronic mail at no cost. Printed copies are available by subscription. Single copies are available for the costs of reproduction and mailing. Issues of CuD can be found in the Usenet alt.society.cu-digest news group, on CompuServe in DL0 and DL4 of the IBMBBS SIG, DL1 of LAWSIG, and DL0 and DL12 of TELECOM, on Genie, on the PC-EXEC BBS at (414) 789-4210, and by anonymous ftp from ftp.cs.widener.edu, chsun1.spc.uchicago.edu, and dagon.acc.stolaf.edu. To use the U. of Chicago email server, send mail with the subject "help" (without the quotes) to archive-server@chsun1.spc.uchicago.edu. COMPUTER UNDERGROUND DIGEST is an open forum dedicated to sharing information among computerists and to the presentation and debate of diverse views. CuD material may be reprinted as long as the source is cited. Some authors do copyright their material, and they should be contacted for reprint permission. It is assumed that non-personal mail to the moderators may be reprinted unless otherwise specified. Readers are encouraged to submit reasoned articles relating to the Computer Underground. Articles are preferred to short responses. Please avoid quoting previous posts unless absolutely necessary. DISCLAIMER: The views represented herein do not necessarily represent the views of the moderators. Digest contributors assume all responsibility for ensuring that articles submitted do not violate copyright protections. ---------------------------------------------------------------------- Date: Wed, 14 Aug 1991 11:22:00 CDT From: "Jim Thomas" Subject: File 1--Review: PRACTICAL UNIX SECURITY (Garfinkel and Spafford) Review of: _Practical UNIX Security_, by Simson Garfinkel and Gene Spafford. Sebastopol, (Calif): O'Reilly & Associates, Inc. 481 pp. $29.95 pb. Because I know virtually nothing about UNIX, I am eminently qualified to comment on the Garfinkel/Spafford (G&S) volume. If I can understand and learn from it, anybody can. I have no idea whether UNIX Whizzes will find the tome worthwhile, but as a UNIX beginner, I judge the book a first-rate primer for inquisitive, but uninformed, neophytes. To label the G&S book a "security" manual is misleading. Their introductory warning to would-be hackers who would interpret the book as in invitation to break into the authors' systems is perhaps a bit melodramatic (p. xxvii), but the book is about security as M*A*S*H is about war. I suspect system administrators, such as the following reviewer who is plagued by the screw-ups of folks like me who learn by punching in commands to see what they do--would hope users read _UNIX Security_ on the chance it would make them (the users, not the sysads) better citizens and cause them (the sysads, not the users) less hassle in answering obvious questions. I'd guess that most users do not learn UNIX by taking classes, but rather by trial and error, pestering the pros, and maybe even purchasing a book or two. Unlike the detailed "how to" books, such as _UNIX Made Easy_ (an oxymoronic title) that cover a wide range of UNIX uses and commands from programming to learning the intricacies of vi, _UNIX Security_ is more basic, focused, and appropriate for the UNIX newnicks. Despite the focus on security, the book's emphasis is on responsible system use by teaching, step-by-step, those aspects of use at which security requisites arise. Such lessons obviously require an overview of the basics, which the authors provide. They begin with an overview of the history of UNIX dating from the Mid-1960s with Multics to the rewriting and playful renaming of Multics to UNIX derived from the fact that Multics tried to to multiple things, and UNIX just one: Run programs (p. 7). But, the openness and ease of UNIX also had a major drawback: The early versions were not secure. Many of the original problems were the result of holes in the software itself, but--and the authors stress this throughout--the most serious security lapses are the result of human error or indifference. Cracking into any system in most cases requires access to an account and then using that account to penetrate deeper by using various tricks to obtain root privileges. As a consequence, the first line of defense, argue the authors, is to assure that unauthorized logins are prevented. There is little new for sysads in the book's first substantive chapter, "Users, Groups, and the Superuser." But the new user will find this explanation, along with the various charts clarifying what all those symbols mean when we list the /etc/group file, quite helpful. Subsequent chapters explaining files, defending accounts, and securing data provide useful examples that can serve as exercises for the beginner in ferreting out the complexity of UNIX as well as for protecting one's own account against intruders. What for experienced users might seem mundane serves newer users with ways to develop and test knowledge of *one's own* account. The periodic distinctions between legitimate curious use and inappropriate abuse provide guidelines that encourage exploration while reminding the user of the courtesies owed to the sysads and others. For those active on the nets, a five chapter section on modems, UUCP, Networks and Security, Sun's NFS, and other topics condenses much of Quarterman's $50 _The Matrix_ into a few comprehensible chapters. Although intended more for those setting up systems than using them, the discussion illustrates what occurs when we dial into a UNIX system and summarizes various operations of remote systems, including sending mail and file transfer. I found that the general discussion helped clarify the occasional error message and helps to use other systems more efficiently, ranging from moving around within them to using ftp and telnet. Sysads may find little new in the discussion of what to do when a breakin occurs, but the step-by step procedures might serve as a mindful checklist. The cardinal rules--"don't panic" and "document" are sound for all computer users when they suspect intrusion, and inexperienced users should find the discussion helpful in reviewing how systems track and identify other users. Although most users do not encrypt files and know nothing about the process, the early discussion of the process (pp 29-31) provides an understandable overview of what encryption is and how it works. With increasing emphasis on secure systems, discussions of encryption also increase, and even for those of us who are functionally illiterate, it helps to know what salt is and what it does to our password. Chapter 18 is devoted to a more detailed summary of encryption systems, including ROT13 and crypt. The chapter on "Computer Security and U.S. Law" is too brief. G&S explain the legal options for prosecution and remind readers of the hazards of criminal prosecution, which include law enforcement illiteracy, the problems of search warrants, and the dangers of equipment seized as evidence. Alluding to the experience of Steve Jackson Games, where law enforcement seizure of equipment and a pre-publication version of a new game had led to a suit against Federal and private sector personnel, G&S warn employeers whose employees--or they themselves--may have equipment taken by law enforcement of their right to receipts and of the need to discuss the conditions of return. The section on law (p. 349) lists the laws likely to be used in prosecuting computer intrustion along with a few word summary of the violation each law represents. Because even the most recent laws tend to be overly-broad and vague, the section on "Federal computer crime laws" could have been expanded to include a discussion of the problems of legal language and give a better summary of the relevant language of each. It is also a bit disturbing that the chapters seems to advocate (despite the caveats) prosecution in favor of other, less punitive but equally effective, actions. My bias as an advocate of decriminalization of many types of crimes and as a believer in reducing, rather than increasing, the burden of the criminal justice system led to me quibble, perhaps unduly, with what is otherwise a well-summarized chapter. But, especially for students (who constitute the bulk of the "hacker" population), there are numerous non-legal options available, and to my mind there should have been greater emphasis on elaborating the non-legal responses available and even suggesting some new ones. There is one irony in the G&S volume. Take the various chapters, retitle them as "how to break into..." or "UNIX cryptography" and rewrite the text in cyberese, then publish them in PHRACK or LoD/TJ, and add at the end of each the caution "Don't get caught with this," and you might have law enforcement breathing down your neck. G&S have written--albeit more articulately and with more detail and insight--on the kinds of topics with similar examples to those found in some of the better p/h newsletters. Proving, perhaps, that form can be more important as content. My goal here has been to suggest for the non-UNIX expert why they wold find _Practical UNIX Security_ worth reading. Despite the title and the authors' professed goal, is crammed with information on all phases of UNIX use and with tips for utilizing the system's power. Those who read and experiment with the volume are likely to become better system and net citizens, both because of their knowledge and proficiency and because of the socialization process entailed by practicing what the authors teach us. It is well worth the price. ((Jim Thomas is CuD co-editor and trying to learn UNIX after 9 years on an IBM mainframe)) ------------------------------ Date: Wed, 14 Aug 1991 11:22:00 CDT From: Neil Rickert Subject: File 2--Review of "Practical Unix Security" (Garfinkel & Spafford). Following on the heals of the development of the microprocesor, the last decade has seen an explosion of computers. However the expertise to administer these computers has not grown at anything like the same pace. The result is that there are large numbers of computers administered by people who are seriously short of experience. Worse still many of these computers are connected to Internet, readily exposing them to would be electronic intruders. Unix systems have particularly flexible networking facilities, but while these provide great benefits to the Unix user, they also provide portholes through which breakins can be attempted. In the circumstances "Practical Unix Security" is a very timely publication. This is a book for all Unix admins, not just those concerned about security. If you have a Unix work station on your desktop, and if you are the sole user, and it not connected to any networks, you perhaps have little to worry about in terms of security. But you can still benefit greatly from reading "Practical Unix Security". For this is not just a book about security. It also covers many aspects of administering Unix systems. Indeed, it fills in many of the gaps left by the system administration books that you will find in the Unix section of your bookstore. Doubtless the book will also be of interest to Unix detractors who will welcome the opportunity to gloat at some of the security problems in Unix. But while they are gloating, they should perhaps look more closely at their own systems for problems which may be lurking just below the surface, less well known perhaps, because their systems lack the openness of Unix. If you are looking for a specific list of steps to break into a Unix system, this is not the book for you. The author's are quite careful on this point. They do, however, give a guided tour through the system indicating the points of weakness, and suggesting how to configure your system to minimize the security problems. The book covers passwords, file permissions and the use of umask, the risk of trojan horses and selecting a PATH which reduces the risk, SUID and SGID programs, logging activity, configuring UUCP to minimize security problems, networking cautions including cautions on the use of NFS and NIS services. It discusses Kerberos, SunOS secure rpc, and firewall arrangements, as ways of enhancing security. Some time is spent on discussing good system backup plans. A good backup strategy can be important if your system security is broken, for it allows you to recover any damaged files. But, more important, it also provides recovery from the acts of incredible stupidity to which even the most experienced computer administrators are occasionally prone. Security is not a technical problem, and the authors are careful to point this out. It is a people problem. Technological fixes by themselves don't work. If, for example, you impose a system of machine generated passwords, this may create passwords that users can not remember, causing them to write the passwords down on paper with a net loss in security. There is always a tradeoff between security and convenience. Some of the stricter security measures may generate sufficient inconvenience that users will unthinkingly develop ways of subverting the security mechanisms. Still, there is no excuse for vendors favoring convenience to the extent that they sell systems with virtually no security. Perhaps one of the most serious of these is distribution of default configurations with a '+' in /etc/hosts.equiv . The authors do not mince words on page 238, where they state "This is a major security hole" and on the next page "If you have a plus sign in your host.equiv (sic) file, REMOVE IT." Any book this length is bound to contain a few mistakes. "Practical Unix Security" is no exception. Here are some examples: p. 54 The su command only changes your process's effective UID; the real UID remains the same. That sounds to me like a badly broken implementation of su. p. 92 Letting a user run the Berkeley mail(1) program without logging in is dangerous, because the mail program allows the user to run any command by preceding a line of the mail message with a tilde and an exclamation mark. While I agree with the authors that it would be unwise, the risk is not as obvious as they assert. When a user attempts such a shell escape, 'mail' implements it by invoking the user's login shell. If, as in this example, the login shell is 'mail', then the tilde escape to execute say 'csh' would result in 'mail' attempting to execute '/usr/ucb/mail -c csh', and that would not get you very far. p. 218 Your mail system should not allow mail to be sent directly to a file. Mailers that deliver directly to files can be used to corrupt system databases or application programs. You can test whether or not your system allows mail to be sent to a file with the command sequence: mail /tmp/mailbug this is a mailbug file test ^D If the file mailbug appears in the /tmp directory, then your mailer is insecure. This is not a good test to try. If 'mail /tmp/mailbug < message-file' happens to work, it doesn't do anything more dangerous than say 'cat >> /tmp/mailbug < message-file'. There is only a problem if you can persuade 'mail' to write to a file you would not otherwise be able to write to, or to create a file with permissions and ownership you could not normally use. If, for example, your 'mail' program were to directly handle mail to files, and pass all other mail off to 'sendmail', this would not be a security problem at all unless your mail program runs suid or sgid. +++++ These examples are really only minor failings. But they do have the effect of making the inexperienced reader believe that Unix security is much weaker than in reality it is. This will tend to make inexperienced admins unnecessarily paranoid, and perhaps afraid to do anything useful with their system. My major criticism of this book, in fact, is that it seems to present an excessively paranoid view of the subject. The authors make an attempt to avoid this very early, when they discuss risk assessment, and point at that you need not go overboard, but should provide sufficient security for the likely risk given the nature of the data on your computer and the way it is used. Unfortunately, the author's seem to lose sight of this later on when they are busily pointing out the likely weaknesses, and how to protect against them. Experienced administrators will have no trouble deciding how much security they need, and balancing this with the convenience they wish to provide to their users. But I worry that novice administrators will not be able to make this judgement. They may either overreact, and be so restrictive that their system is not as useful as it should be, or they may decide that achieving reasonable security is hopeless, and not even take the simplest steps which are often the most important. In summary, I recommend this book for every Unix administrator and would-be administrator, not just for the security information, but for the insight it gives into the workings of Unix. But I hope the reader will keep in mind that the authors have made things sound scarier than they really are. ((Neil Rickert, a professor of computer science, is the sysad of the UNIX system at Northern Illinois University)). ------------------------------ Date: Mon, 28 Jul 1991 10:15:13 CDT From: elrose@well.sf.ca.us Subject: File 3--Cyberspace and the Legal Matrix: Laws or Confusion? (Reprint) ((Moderator's note: The following first appeared in Boardwatch, and later was sent across the nets by the author. We reprint it as part of the on-going discussion about life in cyberspace)). Cyberspace and the Legal Matrix: Laws or Confusion? ((By Lance Rose)) Cyberspace, the "digital world", is emerging as a global arena of social, commercial and political relations. By "Cyberspace", I mean the sum total of all electronic messaging and information systems, including BBS's, commercial data services, research data networks, electronic publishing, networks and network nodes, e-mail systems, electronic data interchange systems, and electronic funds transfer systems. Many like to view life in the electronic networks as a "new frontier", and in certain ways that remains true. Nonetheless, people remain people, even behind the high tech shimmer. Not surprisingly, a vast matrix of laws and regulations has trailed people right into cyberspace. Most of these laws are still under construction for the new electronic environment. Nobody is quite sure of exactly how they actually apply to electronic network situations. Nonetheless, the major subjects of legal concern can now be mapped out fairly well, which we will do in this section of the article. In the second section, we will look at some of the ways in which the old laws have trouble fitting together in cyberspace, and suggest general directions for improvement. LAWS ON PARADE - Privacy laws. These include the federal Electronic Communications Privacy Act ("ECPA"), originally enacted in response to Watergate, and which now prohibits many electronic variations on wiretapping by both government and private parties. There are also many other federal and state privacy laws and, of course, Constitutional protections against unreasonable search and seizure. - 1st Amendment. The Constitutional rights to freedom of speech and freedom of the press apply fully to electronic messaging operations of all kinds. - Criminal laws. There are two major kinds of criminal laws. First, the "substantive" laws that define and outlaw certain activities. These include computer-specific laws, like the Computer Fraud and Abuse Act and Counterfeit Access Device Act on the federal level, and many computer crime laws on the state level. Many criminal laws not specific to "computer crime" can also apply in a network context, including laws against stealing credit card codes, laws against obscenity, wire fraud laws, RICO, drug laws, gambling laws, etc. The other major set of legal rules, "procedural" rules, puts limits on law enforcement activities. These are found both in statutes, and in rulings of the Supreme Court and other high courts on the permissible conduct of government agents. Such rules include the ECPA, which prohibits wiretapping without a proper warrant; and federal and state rules and laws spelling out warrant requirements, arrest requirements, and evidence seizure and retention requirements. - Copyrights. Much of the material found in on-line systems and in networks is copyrightable, including text files, image files, audio files, and software. - Moral Rights. Closely related to copyrights, they include the rights of paternity (choosing to have your name associated or not associated with your "work") and integrity (the right not to have your "work" altered or mutilated). These rights are brand new in U.S. law (they originated in Europe), and their shape in electronic networks will not be settled for quite a while. - Trademarks. Anything used as a "brand name" in a network context can be a trademark. This includes all BBS names, and names for on-line services of all kinds. Materials other than names might also be protected under trademark law as "trade dress": distinctive sign-on screen displays for BBS's, the recurring visual motifs used throughout videotext services, etc. - Right of Publicity. Similar to trademarks, it gives people the right to stop others from using their name to make money. Someone with a famous on-line name or handle has a property right in that name. - Confidential Information. Information that is held in secrecy by the owner, transferred only under non-disclosure agreements, and preferably handled only in encrypted form, can be owned as a trade secret or other confidential property. This type of legal protection is used as a means of asserting ownership in confidential databases, >from mailing lists to industrial research. - Contracts. Contracts account for as much of the regulation of network operations as all of the other laws put together. The contract between an on-line service user and the service provider is the basic source of rights between them. You can use contracts to create new rights, and to alter or surrender your existing rights under state and federal laws. For example, if a bulletin board system operator "censors" a user by removing a public posting, that user will have a hard time showing his freedom of speech was violated. Private system operators are not subject to the First Amendment (which is focused on government, not private, action). However, the user may have rights to prevent censorship under his direct contract with the BBS or system operators. You can use contracts to create entire on-line legal regimes. For example, banks use contracts to create private electronic funds transfer networks, with sets of rules that apply only within those networks. These rules specify on a global level which activities are permitted and which are not, the terms of access to nearby systems and (sometimes) to remote systems, and how to resolve problems between network members. Beyond the basic contract between system and user, there are many other contracts made on-line. These include the services you find in a CompuServe, GEnie or Prodigy, such as stock quote services, airline reservation services, trademark search services, and on-line stores. They also include user-to-user contracts formed through e-mail. In fact, there is a billion-dollar "industry" referred to as "EDI" (for Electronic Data Interchange), in which companies exchange purchase orders for goods and services directly via computers and computer networks. - Peoples' Rights Not to be Injured. People have the right not to be injured when they venture into cyberspace. These rights include the right not to be libelled or defamed by others on-line, rights against having your on-line materials stolen or damaged, rights against having your computer damaged by intentionally harmful files that you have downloaded (such as files containing computer "viruses"), and so on. There is no question these rights exist and can be enforced against other users who cause such injuries. Currently, it is uncertain whether system operators who oversee the systems can also be held responsible for such user injuries. - Financial Laws. These include laws like Regulations E & Z of the Federal Reserve Board, which are consumer protection laws that apply to credit cards, cash cards, and all other forms of electronic banking. - Securities Laws. The federal and state securities laws apply to various kinds of on-line investment related activities, such as trading in securities and other investment vehicles, investment advisory services, market information services and investment management services. - Education Laws. Some organizations are starting to offer on-line degree programs. State education laws and regulations come into play on all aspects of such services. The list goes on, but we have to end it somewhere. As it stands, this list should give the reader a good idea of just how regulated cyberspace already is. LAWS OR CONFUSION? The legal picture in cyberspace is very confused, for several reasons. First, the sheer number of laws in cyberspace, in itself, can create a great deal of confusion. Second, there can be several different kinds of laws relating to a single activity, with each law pointing to a different result. Third, conflicts can arise in networks between different laws on the same subject. These include conflicts between federal and state laws, as in the areas of criminal laws and the right to privacy; conflicts between the laws of two or more states, which will inevitably arise for networks whose user base crosses state lines; and even conflicts between laws from the same governmental authority where two or more different laws overlap. The last is very common, especially in laws relating to networks and computer law. Some examples of the interactions between conflicting laws are considered below, from the viewpoint of an on-line system operator. 1. System operators Liability for "Criminal" Activities. Many different activities can create criminal liabilities for service providers, including: - distributing viruses and other dangerous program code; - publishing "obscene" materials; - trafficking in stolen credit card numbers and other unauthorized access data; - trafficking in pirated software; - and acting as an accomplice, accessory or conspirator in these and other activities. The acts comprising these different violations are separately defined in statutes and court cases on both the state and federal levels. For prosecutors and law enforcers, this is a vast array of options for pursuing wrongdoers. For service providers, it's a roulette wheel of risk. Faced with such a huge diversity of criminal possibilities, few service providers will carefully analyze the exact laws that may apply, nor the latest case law developments for each type of criminal activity. Who has the time? For system operators who just want to "play it safe", there is a strong incentive to do something much simpler: Figure out ways to restrict user conduct on their systems that will minimize their risk under *any* criminal law. The system operator that chooses this highly restrictive route may not allow any e-mail, for fear that he might be liable for the activities of some secret drug ring, kiddie porn ring or stolen credit card code ring. The system operator may ban all sexually suggestive materials, for fear that the extreme anti-obscenity laws of some user's home town might apply to his system. The system operator may not permit transfer of program files through his system, except for files he personally checks out, for fear that he could be accused of assisting in distributing viruses, trojans or pirated software; and so on. In this way, the most restrictive criminal laws that might apply to a given on-line service (which could emanate, for instance, from one very conservative state within the system's service area) could end up restricting the activities of system operators all over the nation, if they happen to have a significant user base in that state. This results in less freedom for everyone in the network environment. 2. Federal vs. State Rights of Privacy. Few words have been spoken in the press about network privacy laws in each of the fifty states (as opposed to federal laws). However, what the privacy protection of the federal Electronic Communications Privacy Act ("ECPA") does not give you, state laws may. This was the theory of the recent Epson e-mail case. An ex-employee claimed that Epson acted illegally in requiring her to monitor e-mail conversations of other employees. She did not sue under the ECPA, but under the California Penal Code section prohibiting employee surveillance of employee conversations. The trial judge denied her claim. In his view, the California law only applied to interceptions of oral telephone discussions, and not to visual communication on video display monitors. Essentially, he held that the California law had not caught up to modern technology - making this law apply to e-mail communications was a job for the state legislature, not local judges. Beyond acknowledging that the California law was archaic and not applicable to e-mail, we should understand that the Epson case takes place in a special legal context - the workplace. E-mail user rights against workplace surveillance are undeniably important, but in our legal and political system they always must be "balanced" (ie., weakened) against the right of the employer to run his shop his own way. Employers' rights may end up weighing more heavily against workers' rights for company e-mail systems than for voice telephone conversations, at least for employers who use intra-company e-mail systems as an essential backbone of their business. Fortunately, this particular skewing factor does not apply to *public* communications systems. I believe that many more attempts to establish e-mail privacy under state laws are possible, and will be made in the future. This is good news for privacy advocates, a growing and increasingly vocal group these days. It is mixed news, however, for operators of BBS's and other on-line services. Most on-line service providers operate on an interstate basis - all it takes to gain this status is a few calls from other states every now and then. If state privacy laws apply to on-line systems, then every BBS operator will be subject to the privacy laws of every state in which one or more of his users are located! This can lead to confusion, and inability to set reasonable or predictable system privacy standards. It can also lead to the effect described above in the discussion of criminal liability. On-line systems might be set up "defensively", to cope with the most restrictive privacy laws that might apply to them. This could result in declarations of *absolutely no privacy* on some systems, and highly secure setups on others, depending on the individual system operator's inclinations. 3. Pressure on Privacy Rights Created by Risks to Service Providers. There are two main kinds of legal risks faced by a system operator. First, the risk that the system operator himself will be found criminally guilty or civilly liable for being involved in illegal activities on his system, leading to fines, jail, money damages, confiscation of system, criminal record, etc. Second, the risk of having his system confiscated, not because he did anything wrong, but because someone else did something suspicious on his system. As discussed above, a lot of criminal activity can take place on a system when the system operator isn't looking. In addition, certain non-criminal activities on the system could lead to system confiscation, such copyright or trade secret infringement. This second kind of risk is very real. It is exactly what happened to Steve Jackson Games last year. Law enforcement agents seized Steve's computer (which ran a BBS), not because they thought he did anything wrong, but because they were tracking an allegedly evil computer hacker group called the "Legion of Doom". Apparently, they thought the group "met" and conspired on his BBS. A year later, much of the dust has cleared, and the Electronic Frontier Foundation is funding a lawsuit against the federal agents who seized the system. Unfortunately, even if he wins the case Steve can't get back the business he lost. To this day, he still has not regained all of his possessions that were seized by the authorities. For now, system operators do not have a great deal of control over government or legal interference with their systems. You can be a solid citizen and report every crime you suspect may be happening using your system. Yet the chance remains that tonight, the feds will be knocking on *your* door looking for an "evil hacker group" hiding in your BBS. This Keystone Kops style of "law enforcement" can turn system operators into surrogate law enforcement agents. System operators who fear random system confiscation will be tempted to monitor private activities on their systems, intruding on the privacy of their users. Such intrusion can take different forms. Some system operators may declare that there will be no private discussions, so they can review and inspect everything. More hauntingly, system operators may indulge in surreptitious sampling of private e-mail, just to make sure no one's doing anything that will make the cops come in and haul away their BBS computer systems (By the way, I personally don't advocate either of these things). This situation can be viewed as a way for law enforcement agents to do an end run around the ECPA's bar on government interception of electronic messages. What the agents can't intercept directly, they might get through fearful system operators. Even if you don't go for such conspiracy theories, the random risk of system confiscation puts great pressure on the privacy rights of on-line system users. 4. Contracts Versus Other Rights. Most, perhaps all, of the rights between system operators and system users can be modified by the basic service contract between them. For instance, the federal ECPA gives on-line service users certain privacy rights. It conspicuously falls short, however, by not protecting users from privacy intrusions by the system operator himself. Through contract, the system operator and the user can in effect override the ECPA exception, and agree that the system operator will not read private e-mail. Some system operators may go the opposite direction, and impose a contractual rule that users should not expect any privacy in their e-mail. Another example of the power of contracts in the on-line environment occurred recently on the Well, a national system based in San Francisco (and highly recommended to all those interested in discussing on-line legal issues). A Well user complained that a message he had posted in one Well conference area had been cross-posted by other users to a different conference area without his permission. A lengthy, lively discussion among Well users followed, debating the problem. One of the major benchmarks for this discussion was the basic service agreement between the Well and its users. And a proposed resolution of the issue was to clarify the wording of that fundamental agreement. Although "copyrights" were discussed, the agreement between the Well and its users was viewed as a more important source of the legitimate rights and expectations of Well users. Your state and federal "rights" against other on-line players may not be worth fighting over if you can get a contract giving you the rights you want. In the long run, the contractual solution may be the best way to set up a decent networked on-line system environment, except for the old bogeyman of government intrusion (against whom we will all still need our "rights", Constitutional and otherwise). CONCLUSION There are many different laws that system operators must heed in running their on-line services. This can lead to restricting system activities under the most oppressive legal standards, and to unpredictable, system-wide interactions between the effects of the different laws. The "net" result of this problem can be undue restrictions on the activities of system operators and users alike. The answers to this problem are simple in concept, but not easy to execute. First, enact (or re-enact) all laws regarding electronic services on a national level only, overriding individual state control of system operators activities in cyberspace. It's time to realize that provincial state laws only hinder proper development of interstate electronic systems. As yet, there is little movement in enacting nationally effective laws. Isolated instances include the Electronic Communications Privacy Act and the Computer Fraud and Abuse Act, which place federal "floors" beneath privacy protection and certain types of computer crime, respectively. On the commercial side, the new Article 4A of the Uniform Commercial Code, which normalizes on-line commercial transactions, is ready for adoption by the fifty states. Second, all laws regulating on-line systems must be carefully designed to interact well with other such laws. The goal is to create a well-defined, reasonable legal environment for system operators and users. The EFF is fighting hard on this front, especially in the areas of freedom of the press, rights of privacy, and rights against search and seizure for on-line systems. Reducing government intrusion in these areas will help free up cyberspace for bigger and better things. However, the fight is just beginning today. _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ Lance Rose is an attorney who works primarily in the fields of computer and high technology law and intellectual property. His clients include on-line publishers, electronic funds transfer networks, data transmission services, individual system operators, and shareware authors and vendors. He is currently revising SYSLAW, The Sysop's Legal Manual. Lance is a partner in the New York City firm of Greenspoon, Srager, Gaynin, Daichman & Marino, and can be reached by voice at (212)888-6880, on the Well as "elrose", and on CompuServe at 72230,2044. Copyright 1991 Lance Rose The above article was originally published in Boardwatch, June, 1991 ------------------------------ Date: Wed, 14 Aug 91 21:24 EDT From: silicon.surfer@unixville.edu Subject: File 4--Mystery Lurks In The Death of INSLAW Reporter ((Moderators' note: The death of INSLAW reporter J. Daniel Casolaro by apparent suicide raises more questions about the entire affair. Former U.S. Attorney General Elliot Richardson has called for a Congressional investigation into the role of the Justice Department in the affair. The Chicago Tribune (Aug.16, 1991, p. 14) reported that a three hour autopsy this week found no evidence of anything other than suicide, but that alternatives had not been ruled out, and no cause of death has yet been given officially.)) Mystery Lurks In The Death Of Reporter The Associated Press Charleston, W. Va.- An investigative reporter found dead with his wrists slashed in a hotel bathtub had warned others that he was on to an explosive government scandal and might wind up dead in an "accident". The death of free-lance journalist Joseph D. Casolaro, 44, of Fairfax, Va., initially was believed to be a suicide, but an autopsy was ordered after the family members were contacted, police said Tuesday. "He told us if he got killed in an accident not to believe it. That was three months ago," said Casolaro's brother, Dr. M. Anthony Casolaro of Alexandria, Va. Casolaro had been working for a year on a book on allegations made in 1983 that the U.S. government stole software from INSLAW Inc., a Washington company. The company has alleged in court that after it won a $10 million contract with the Justice Department, the department stole software designed to help law enforcement officials track cases. Several of Casolaro's sources had warned him he would be in danger if he continued his investigation, company owner Bill Hamilton said. "I have some sources that Danny also had, and several of them told him, 'These people will snuff you out without blinking an eye.' " Hamilton said. Dr. James Frost, an assistant state medical examiner, said a preliminary report on the death would be completed today. The body had been embalmed before the autopsy was held. Frost said that was because early indications were that Casolaro had killed himself. Acquaintances said that they seen no indications of depression and that Casolaro was in West Virginia to get more information. In an outline of his book, Casolaro described his findings to Hamilton as "an octopus, created in the 1950s and operating today with impunity because it is intertwined with domestic and foreign intelligence agencies...a criminal enterprise bent on making money. ------------------------------ End of Computer Underground Digest #3.30 ************************************