Security Policies CSSE 490 Computer Security Mark Ardis

Security Policies CSSE 490 Computer Security Mark Ardis, Rose-Hulman Institute March 15, 2004 1

Acknowledgements Many of these slides came from Matt Bishop, author of Computer Security: Art and Science 2

Chapter 4: Security Policies n n Overview The nature of policies q q What they cover Policy languages 3

Security Policy n Policy partitions system states into: q Authorized (secure) n q Unauthorized (nonsecure) n n These are states the system can enter If the system enters any of these states, it’s a security violation Secure system q q Starts in authorized state Never enters unauthorized state 4

Confidentiality n n X set of entities, I information I has confidentiality property with respect to X if no x in X can obtain information from I I can be disclosed to others Example: q q q X set of students I final exam answer key I is confidential with respect to X if students cannot obtain final exam answer key 5

Integrity n n n X set of entities, I information I has integrity property with respect to X if all x in X trust information in I Types of integrity: q q q trust I, its conveyance and protection (data integrity) I is information about origin of something or an identity (origin integrity, authentication) I is a resource: means resource functions as it should (assurance) 6

Availability n n n X set of entities, I resource I has availability property with respect to X if all x in X can access I Types of availability: q q traditional: x gets access or not quality of service: promised a level of access (for example, a specific level of bandwidth) and not meet it, even though some access is achieved 7

Policy Models n n Abstract description of a policy or class of policies Focus on points of interest in policies q q q Security levels in multilevel security models Separation of duty in Clark-Wilson model Conflict of interest in Chinese Wall model 8

Types of Security Policies n Military (governmental) security policy q n Commercial security policy q n Policy primarily protecting integrity Confidentiality policy q n Policy primarily protecting confidentiality Policy protecting only confidentiality Integrity policy q Policy protecting only integrity 9

Trust Administrator installs patch 1. Trusts patch came from vendor, not tampered with in transit 2. Trusts vendor tested patch thoroughly 3. Trusts vendor’s test environment corresponds to local environment 4. Trusts patch is installed correctly 10

Types of Access Control n Discretionary Access Control (DAC, IBAC) q n Mandatory Access Control (MAC) q n individual user sets access control mechanism to allow or deny access to an object system mechanism controls access to object, and individual cannot alter that access Originator Controlled Access Control (ORCON) q originator (creator) of information controls who can access information 11

Policy Languages n n Express security policies in a precise way High-level languages q n Policy constraints expressed abstractly Low-level languages q Policy constraints expressed in terms of program options, input, or specific characteristics of entities on system 12

High-Level Policy Languages n n n Constraints expressed independent of enforcement mechanism Constraints restrict entities, actions Constraints expressed unambiguously q Requires a precise language, usually a mathematical, logical, or programming-like language 13

Example: Web Browser n n n Goal: restrict actions of Java programs that are downloaded and executed under control of web browser Language specific to Java programs Expresses constraints as conditions restricting invocation of entities 14

Expressing Constraints n Entities are classes, methods q q n Operations q q n Class: set of objects that an access constraint constrains Method: set of ways an operation can be invoked Instantiation: s creates instance of class c: s -| c Invocation: s 1 executes object s 2: s 1 | s 2 Access constraints q q deny(s op x) when b While b is true, subject s cannot perform op on (subject or class) x; empty s means all subjects 15

Sample Constraints n n Downloaded program cannot access password database file on UNIX system Program’s class and methods for files: class File { public file(String name); public String getfilename(); public char read(); n Constraint: deny( |-> file. read) when (file. getfilename() == “/etc/passwd” 16

Another Sample Constraint n n At most 100 network connections open Socket class defines network interface q n Network. numconns method giving number of active network connections Constraint deny( -| Socket) when (Network. numconns >= 100) 17

DTEL - Domain Type Enforcement Language n n Basis: access can be constrained by types Combines elements of low-level, high-level policy languages q q Implementation-level constructs express constraints in terms of language types Constructs do not express arguments or inputs to specific system commands 18

Example n n Goal: users cannot write to system binaries Subjects in administrative domain can q n User must authenticate to enter that domain Subjects belong to domains: q q d_user d_admin d_login d_daemon ordinary users administrative users for login system daemons 19

Types n Object types: q q q n t_sysbin t_readable t_writable t_dte t_generic executable system files readable files writable files data used by enforcement mechanisms data generated from user processes For example, treat these as partitions q In practice, files can be readable and writable; ignore this for the example 20

Domain Representation n Sequence q q First component is list of programs that start in the domain Other components describe rights subject in domain has over objects of a type (crwd->t_writable) means subject can create, read, write, and list (search) any object of type t_writable 21

d_daemon Domain d_daemon = (/sbin/init), (crwd->t_writable), (rd->t_generic, t_readable, t_dte), (rxd->t_sysbin), (auto->d_login); n Compromising subject in d_daemon domain does not enable attacker to alter system files q n Subjects here have no write access When /sbin/init invokes login program, login program transitions into d_login domain 22

d_admin Domain d_admin = (/usr/bin/sh, /usr/bin/csh, /usr/bin/ksh), (crwxd->t_generic), (crwxd->t_readable, t_writable, t_dte, t_sysbin), (sigtstp->d_daemon); n n sigtstp allows subjects to suspend processes in d_daemon domain Admin users use a standard command interpreter 23

Low-Level Policy Languages n Set of inputs or arguments to commands q n Check or set constraints on system Low level of abstraction q Need details of system, commands 24

Example: X Window System n n UNIX X 11 Windowing System Access to X 11 display controlled by list q List says what hosts allowed, disallowed access xhost +groucho -chico n n Connections from host groucho allowed Connections from host chico not allowed 25

Example: tripwire n File scanner that reports changes to file system and file attributes q tw. config describes what may change /usr/mab/tripwire +gimnpsu 012345678 -a n q Check everything but time of last access (“-a”) database holds previous values of attributes 26

Example Database Record /usr/mab/tripwire/README 0. . /. 100600 45763 1 917 10 33242. gt. Pvf. gt. Pv. Y 0. ZD 4 cc 0 Wr 8 i 21 ZKa. I. . LUOr 3. 0 fwo 5: hf 4 e 4. 8 TAqd 0 V 4 ubv ? . . 9 b 3 1 M 4 GX 01 xb. GIX 0 o. Vu. Go 1 h 15 z 3 ? : Y 9 jfa 04 rdz. M 1 q: eqt 1 APg. Hk ? . Eb 9 yo. 2 zk. Eh 1 XKov. X 1: d 0 w. F 0 kf. Av. C ? 1 M 4 GX 01 xb. GIX 2947 jdyrior 38 h 15 z 3 0 n file name, version, bitmask for attributes, mode, inode number, number of links, UID, GID, size, times of creation, last modification, last access, cryptographic checksums 27

Comments n n System administrators not expected to edit database to set attributes properly Checking for changes with tripwire is easy q n Just run once to create the database, run again to check Checking for conformance to policy is harder q Need to set system up to conform to policy, then run tripwire to construct database 28

Example English Policy: UC Davis n Computer security policy for academic institution q q n n Institution has multiple campuses, administered from central office Each campus has its own administration, and unique aspects and needs Acceptable Use Policy Electronic Mail Policy 29

Acceptable Use Policy n n Intended for one campus (Davis) only Goals of campus computing q Underlying intent Procedural enforcement mechanisms q Warnings q Denial of computer access q Disciplinary action up to and including expulsion Written informally, aimed at user community 30

Electronic Mail Policy n n Systemwide, not just one campus Three parts q q q Summary Full policy Interpretation at the campus 31

Summary n Warns that electronic mail not private q q n Can be read during normal system administration Can be forged, altered, and forwarded Unusual because the policy alerts users to the threats q Usually, policies say how to prevent problems, but do not define threats 32

Summary n What users should and should not do q q q n Think before you send Be courteous, respectful of others Don’t interfere with others’ use of email Personal use okay, provided overhead minimal 33

Full Policy n E-mail, infrastructure are university property q q q Principles of academic freedom, freedom of speech apply Access without user’s permission requires approval of vice chancellor of campus or vice president of UC If infeasible, must get permission retroactively 34

Uses of E-mail n Anonymity allowed q n Can’t interfere with others’ use of e-mail q n Provided it doesn’t break laws or other policies No spam, letter bombs, e-mailed worms, etc. Personal e-mail allowed within limits q q Cannot interfere with university business Such e-mail may be a “university record” subject to disclosure 35

Security of E-mail n University can read e-mail q q q n Won’t go out of its way to do so Allowed for legitimate business purposes Allowed to keep e-mail robust, reliable Archiving and retention allowed q May be able to recover e-mail from end system (backed up, for example) 36

Key Points n n n Policies describe what is allowed Mechanisms control how policies are enforced Trust underlies everything 37