UNIX System Security

UNIX System Security

LISA `95 September 18, 1995

Matt Bishop

Department of Computer Science University of California at Davis Davis, CA 95616-8562

phone (916) 752-8060 email

What Is Security?

A college computing center does not allow copying from one class account to another. A student solves a homework assignment on the computer, but does not read-protect it. A second student copies it. Has a breach of security occurred?

Policy vs Mechanism

policy what is (and is not) allowed

mechanism what enforces the policy

Response to scenario: since the college asserts that each student's class account is private, a breach of security has occurred. The failure to use the mechanism to enforce this policy does not change this breach.

Classes of Security Policies

Military worry mainly about disclosure (revealing information)

Commercial worry mainly about modifying information

The Orange Book

DOD 5200.28-STD; de facto standard for many agencies Specifies rating criteria for the security of systems: class A1: Verified Design class B3: Security Domains class B2: Structured Protection class B1: Labelled Security Protection class C2: Controlled Access Protection class C1: Discretionary Security Protection

class D : Minimal Protection

Class D

All systems not falling into any higher class

Class C1

* discretionary access control

* creditable protection mechanism to enforce this

* used for cooperating users working at same sensitivity level

Class C1 (2)

Design Documentation: description of philosophy of protection, how this is incorporated into the operating system; description of any interfaces between modules of the TCB

Discretionary Access Control: control access between named users (or defined groups) and named objects

Identification and Authentication: requires user authentication, protection of authentication data --- most versions of UNIX fail this test

Security Features User's Guide: single summary (chapter, manual, etc.) describing protection mechanisms, their use, etc.

UNIX System Security

LISA `95 September 18, 1995

Class C1 (3)

Security Testing: ensure the security mechanisms work as described, and there are no obvious ways around them

System Architecture: TCB must run in protected mode--- personal computers fail this test

System Integrity: provide software, hardware (features) to allow validation of hardware, firmware elements of the TCB

Test Documentation: how were the mechanisms tested, and what was the result?

Trusted Facility Manual: a manual describing what the system administrator should be sure to control to run a secure facility

Class C2

Like C1, but ...

* individual accountability

* auditing of security-related events

* resource isolation

UNIX System Security

LISA `95 September 18, 1995

Class C2 (2)

Audit: be able to maintain logs (audit trails) actions based on user identity and protect the logs from modification or deletion

Discretionary Access Control: control access from groups of individuals (whether or not defined by the system); control assignment of privileges

Identification and Authentication: requires identification to granularity of a single user (no group accounts)

Object Reuse: clear all information from an object before reuse (eg, scrub disk blocks)

Security Testing: ensure resource isolation, no unauthorized access to audit, authentication data

System Architecture: isolate system resources but keep them auditable.

Trusted Facility Manual: Describe how to access, maintain, read logs

Class B1

Add to C2 ...

* mandatory access control

* informal statement of security policy model

* data labelling

* removal of flaws found by testing

UNIX System Security

LISA `95 September 18, 1995

Class B1 (2)

Audit: log security levels of objects

Design Documentation: description of model, show how model enforces the policy and the mechanisms enforce the model

Design Specification and Verification: maintain model of policy, show it is consistent with its axioms

I/O of Labeled Information: designate comm channel single- or multi level; be able to audit changes

I/O with Multi-level Devices: must write label on output, assign (read) labels on input

I/O with Single-Level Devices: must be able to designate compartment

Identification and Authentication: maintain security compartment information too

Class B1 (3)

Label Integrity: protect labels when output, tie them to objects

Labelling Human-Readable Output: label all output designed to be readable by people with printable representations of security labels

Labels: maintain sensitivity labels under the control of the TCB

Mandatory Access Control: enforce it for objects, subjects directly under the TCB's control

Security Testing: use friendly penetration attacks to demonstrate absence, removal, or neutralization of flaws

System Architecture: process isolation through separate address spaces under TCB control

Trusted Facility Manual: how to change security compartment of user

UNIX System Security

LISA `95 September 18, 1995

Class B2

Add to B1 ...

* formal statement of security policy model

* address covert storage channels

* TCB structured into protection-critical, non protection-critical elements

* stronger authentication mechanisms

* well tested and relatively resistant to penetration

Class B2 (2)

Audit: log identified events used to exploit covert channels

Configuration Management: need one of these that ensures consistent mapping among code, documentation for the TCB, and allows comparisons of code for successive TCBs

Covert Channels: identify, find max bandwidth of covert storage channels

Design Documentation: describe TCB interfaces, document how TCB implements reference monitor, least privilege; show top level description (specification) of TCB is accurate; document covert channels

Design Specification and Verification: formal model of security policy proven to satisfy security policy

Device Labels: support minimum, maximum security levels for devices

Labels: maintain sensitivity labels for everything directly or indirectly accessible by subjects under the control of the TCB

UNIX System Security

LISA `95 September 18, 1995

Class B2 (3)

Mandatory Access Control: enforce it for objects, subjects directly or indirectly under the TCB's control

Security Testing: correct all flaws, show TCB relatively resistant to penetration

Subject Sensitivity Labels: notify user of change in his/her security compartment during an interactive session

System Architecture: TCB has its own domain of execution which protects it from being tampered or interfered with

Test Documentation: include results of covert channel testing, effectiveness

Trusted Facility Management: separate administrator, operator functions

Trusted Facility Manual: identify sections containing mechanism used to validate the TCB, how to generate a new TCB

Trusted Path: required for initial login, authentication

Class B3

Add to B2 ...

* TCB must be a reference monitor

* support for system security administrator

* signal security-related events

* recovery procedures

* well tested and highly resistant to penetration

UNIX System Security

LISA `95 September 18, 1995

Class B3 (2)

Audit: monitor occurrences, events indicating imminent security violation

Covert Channels: identify, find max bandwidth of all covert channels

Design Documentation: show TCB to be consistent with descriptive top-level specification (informally)

Design Specification and Verification: need convincing argument that descriptive top-level specification is consistent with model

Discretionary Access Control: work on a per-user, per-right basis (ie, access control matrix implementation)

Security Testing: show TCB is resistant to penetration; no design flaws, only a few correctable flaws in implementation

Class B3 (3)

System Architecture: TCB to use a complete, conceptually simple protection mechanism; TCB to incorporate data hiding, abstraction, and layering

Trusted Facility Management: security administrator functions identified, separated (as much as possible) from non-security administrative role

Trusted Facility Manual: how to start the system in a secure manner, or to resume secure operation after operational problems

Trusted Recovery: how to recover without compromising protection mechanisms

UNIX System Security

LISA `95 September 18, 1995

Class A1

Add to B3 ...

* formal design specification of TCB

* formal verification of TCB

* stringent configuration management

* secure distribution

* support for system security administrator

Class A1 (2)

Configuration Management: for life-cycle, this must be in place for all aspects of system development, with safeguards to protect what it manages

Covert Channels: use formal methods in the analysis

Design Documentation: show TCB to be consistent with formal top level specification; describe mechanisms part of TCB but not dealt with in the FTLS (mapping registers, etc.)

Design Specification and Verification: need combination of formal, informal methods to show that formal top-level specification is consistent with model

Security Testing: show TCB is consistent with formal top-level specification

Test Documentation: show results of mapping between formal top level specification and TCB source

Trusted Distribution: maintain integrity during distribution

UNIX System Security

LISA `95 September 18, 1995

UNIX Systems

Most are class D

* Class C1 requires protection of authentication data, and on most UNIX systems this data is world readable

Some are class C2

* These usually are enhanced by add-on packages which protect authentication data, add extensive auditing capabilities, etc.

A very few are class B2

* These are completely redone versions of the UNIX system and are only now becoming available

Who Sets The Standards In the Federal Government?

In the Federal Government: Each agency sets its own standards, in consultation with the National Institute for Science and Technology

UNIX System Security

LISA `95 September 18, 1995

Who Sets The Standards In the Commercial World?

In industry: each company decides what it wants to protect, and how far to go to protect it

What Makes Up a Policy?

* Risk analysis:

* what are the threats?

* how likely are they to arise?

* how can they best be dealt with?

* Analysis of other factors:

* what else affects the policy (federal or state law, needs, etc.)?

* Procedures

* what procedures need to be put in place, and how will they affect security?

UNIX System Security

LISA `95 September 18, 1995

What Are the Threats?

* depends on nature of installation, what is done there, external requirements

example: if working on proprietary projects, non disclosure is important; integrity may be less so as you can reload from backups

example: if doing accounting or inventory control, integrity is vital as the data may change too quickly to do backups after each change; non-disclosure is less so, as it may embarrass but will not corrupt billing

How Likely are They to Arise?

Depends on nature of users and work done as well as nature of the installation

example: if the computer is not attacked to networks, system crackers cannot access it remotely

example: if competing projects are using the system, it is likely one project may try to read another's reports to see what progress is being made

UNIX System Security

LISA `95 September 18, 1995

How Can They Be Dealt With?

Depends on nature of the security mechanisms provided and the procedures allowed

example: if you can require every line of code of all programs added to the system to be inspected by all programmers, it is unlikely a Trojan horse will slip in. (Most sites do not do this as it is too expensive.)

example: use file system controls to restrict access to users' directories

Other Factors

Depend on local/national laws and treaties, needs of users, etc.

example: Shipping encrypted data over an international network may violate some laws and so not be possible, even if it is desireable

example: Put more effort into securing what the users use than into what they don't

UNIX System Security

LISA `95 September 18, 1995

Procedures

Depends on what you are allowed to do (see earlier) and what you are willing to trust

example: Allowing operators to change passwords on the basis of telephoned requests, with no additional validation, is not a good idea

example: Some sites allow the above if confirmation of the request by electronic mail follows

Password Security

Goal: To examine the password mechanisms used by UNIX, and discuss potential security problems

Overview

* How the password changing programs work

* How passwords are stored

* Password file do's and don't's

* What makes a good (or bad) password

* Proactive vs. reactive checking

* Special cases

* Alternatives to the standard UNIX scheme

UNIX System Security

LISA `95 September 18, 1995

Case #1, Columbia University

On Friday, Multimax seemed unusually sluggish

Investigation showed an unauthorized person had gained access to the guest account.

The guest account had an easy-to-guess password, and an unauthorized user guessed it and logged in - and used the machine in unauthorized ways

Joes

A joe is an account with the account name as password.

It was speculated once that every machine in which the user can select his/her own password has at least one joe.

In a nationwide experiment (done informally), this was verified for all computers examined.

UNIX System Security

LISA `95 September 18, 1995

Common Joes

root, rootsh, rootcsh, toor superuser account; as a variation, not given a password on many distribution versions

sysdiag, diag system diagnostic account; some vendors use this to check hardware. This should always have a password different than the account name.

Common Joes (2)

sync used during an emergency shutdown to protect disks. Okay as long as it does only this.

general information who, finger, date, w these can help an attacker get information that makes attacks easier (such as legitimate login names); but they may be desirable. Again, okay as long as they only do what you expect.

Note: these may reveal that the system is a UNIX system should an attacker be using a modem to make blind calls

UNIX System Security

LISA `95 September 18, 1995

Common Joes (3)

games often has a password like "play" or "fun" rather than "games"

demo this is usually a temporary account (in the sense that it is meant to be deleted but is instead forgotten ...)

guest, visitor usually meant only for on-site guests, but used by off-site (uninvited) visitors as well

Common Joes (4)

telnet so they can jump from your site to others (obscuring their trail)

uucp, nuucp so they can gain access to stored files, or to others' traffic through you

mail in some cases, simply to read mail; in other cases, to use a shell escape to get access to your system

UNIX System Security

LISA `95 September 18, 1995

Recommendation

Look for Joes, and eliminate them. No machine should have a full account with an account name as a password.

On Some Systems

* repeatedly guessing a login/password pair may be very slow and may raise alarms

Examples of such systems are IBM's AIX, but this feature can be set or cleared by the sysadmin. Do not assume that this alerts you to all password guessing, as some accounts may have no passwords, or passwords common across systems, or very easily guessed passwords, and often these can be cracked without triggering alarms.

Also, patience of some attackers is incredible; in Danish incident, they tried for two weeks before succeeding!

UNIX System Security

LISA `95 September 18, 1995

User Authentication

How does the user prove his or her identity to the computer?

* what you know (passwords, etc.)

* what you have (smart cards, etc.)

* what you are (biometrics, etc.)

Accepted identity is the basis for controlling all future actions by the user, so it is the

first and most basic security mechanism

What You Know

Checks identity based on something you remember:

* a word (password)

* an algorithm (pass-algorithm)

* a phrase (pass-phrase)

* some transformation of any or all of the above (key crunching)

Vanilla UNIX uses passwords, so we start there

UNIX System Security

LISA `95 September 18, 1995

Why is it Important?

Probably 90-95% of all successful intrusions can be traced to a guessed password (or a missing password):

* At MIT, Purdue, and other universities, programs which guess passwords (and report them to the system administrators) typically get 25-30% of the users' passwords

* An experiment at the Software Engineering Institute analyzed the password files from 50 sites (of all kinds); total 15,000 passwords. 3% (450) guessed in 10 minutes; 21% (3150) within a week.

What a Password Is

A password authenticates a user, binding that identity to all actions undertaken during that session.

Passwords are initially given by the superuser; users can (and should) change them as soon as possible

The user may be another computer (eg, connecting using a network protocol)