CS 5460: Operating Systems

CS5460: Operating Systems Lecture 24: Security

  Once upon a time, this patch was made to Linux’s wait4() system call:

+ if ((options == (__WCLONE|__WALL)) && (current->uid = 0))!

+ retval = -EINVAL;!

  The commit came from one of the most active kernel

developers   What is its effect?

CS 5460: Operating Systems

What’s Computer Security All About?

  Cryptography   Network security   Writing secure code   Secure hardware   Secure operating systems   Etc…

CS 5460: Operating Systems Lecture 25

Today

  OS security basics   UNIX security   Multilevel security   Secure operating systems   Integrity and auditing

CS 5460: Operating Systems

High-Level Security Goals

  Privacy / Confidentiality – Information only available to authorized users

  Integrity – Information retains intended content and semantics

  Availability – Information retains access and presence

  There is tension between these goals   Real systems must make difficult choices between

them

How Do We Approach Security?

  Devise a security policy –  Implements a security model –  Boils down to a collection of rules

  Next, we try to follow the rules –  It’s hard to write large programs that follow security rules –  It’s hard to get humans to follow security rules

  There are many things that can go wrong

CS 5460: Operating Systems

Users  UNIX user -> username -> uid

– uid is the system’s real name for user –  integer 0 ... 65536 (varies in some systems) – mapping is in /etc/passwd

regehr:x:1000:1000:John Regehr,,,:/mnt/z:/bin/bash  More than one username may map to a uid

– Desired for some system purposes (program tracking)

– Problem for ordinary users (confused file ownership) – Security problem (hacker makes duplicate uid

account)  Command to change uid temporarily: su

Unix Groups

  A user is in one or more groups   A group contains zero or more users

–  Groups are used to give better file access control –  Defined by /etc/groups and network sharing software –  ypcat group.byname –  CS department has 961 groups –  gid - integer system name for group (generally unique)

  Listed for individual users with “groups”   Change group of file with “chgrp”

–  chgrp newgroup myfile

Unix File Security

  Each file has owner and group   Permissions set by owner

–  Read, write, execute –  Owner, group, other –  Represented by vector of four octal values

  Only owner, root can change permissions –  This privilege cannot be delegated or shared

  Setid bits – Discuss in a few slides

rwx rwx rwx -

ownr grp othr

setid

UNIX Permissions Practice

16 lab3-1:~> ls –l

drwx------+ 2 regehr csprof 2 Sep 8 11:02 Desktop

drwx------+ 2 regehr csprof 6 Oct 3 21:23 bin

-rw-------+ 1 regehr csprof 25524 Nov 24 11:54 blkdev.h

-rw-r--r--+ 1 regehr csprof 63507 Sep 11 23:02 clang-113697.patch

-rwxrwx---+ 1 regehr csprof 411 Oct 5 18:11 copy_sat_ops.pl

CS 5460: Operating Systems

SETUID and SETGID  Special mechanisms: temporarily use a uid

or gid during the execution of a program  Part of mode bits

– s in user x field - setuid – s in group x field - setgid

 To be effective, both s and x must be set – chmod a+x myprog – chmod u+s myprog – chmod 4755 myprog

 WARNING: It’s hard to use this correctly

Handin on CADE   Directory listing for the “handin” backend:

-rwsrwxr-x 1 root tty 24715 Nov 24 1999 rcvhandin

  Now tell me how handin works –  What happens when you run it? –  How would you use handin to read another student’s files?

CS 5460: Operating Systems

Unix Summary   Good things

–  Some protection from most users –  Flexible enough to make things possible

  Main bad thing: it’s not very expressive –  For example, can’t easily just let a single user mount a CDROM or

add users to the system –  Too tempting to use root privileges

Multilevel Security   Users with different “needs to know” share a

computer or network   If don’t need to know – shouldn’t even be able to

determine if information exists   Should be able to filter functionality based on

allowable information

Military Security Model   Information is ranked:

– Unclassified – Confidential – Secret – Top Secret

 Least Privilege: Subject should have access to fewest objects needed for successful work

– The system backup program may be allowed to bypass read restrictions on files, but it would not have the ability to modify files.

– “Need to Know”

Compartmentalization Information may belong to one or more

compartments Compartments are used to enforce need-to-

know.  Classification of Information:

<rank; compartments>  Clearance: <rank; compartments>

– an indication of a level of trust  A subject can access an object only if

– The clearance level of the subject is at least as high as that of the information.

– The subject has a need to know about all compartments for which the information is classified.

Information Flow Models   Acts as an filter to control the transfer of

information permitted by access to a particular object

  Information flow analysis can assure that operating system modules that have access to sensitive data cannot leak that data to calling modules

Bell-LaPadula Model

 A formal description of the allowable paths of information flow in a secure system

– Applies only to privacy (not availability or integrity)

– Identifies paths that could lead to inappropriate disclosures

– Is used as the basis for the design of systems that handle data of multiple levels

– Includes both discretionary and mandatory access rules

Bell-LaPadula Mandatory Controls

  Fixed security classes for each subject and each object

  Security classes ordered by a relation   Simple Security Property:

–  Subject may have read access only if object classified at same level or lower.

  * - Property: –  Subject may have write access only if all objects read are at

same level or higher than object to be written.

  Summary: “No read up, no write down”   Trusted subjects may violate the *-property

Picture: Confidentiality

S

Public

Proprietary

Read below, write above

S

Public

Proprietary

Read above, write below

Biba Model   Concerned with integrity rather than privacy   Defines integrity levels much like sensitivity levels

–  Fixed integrity classes for each subject and each object –  Ordered integrity classes

Biba Properties  Simple Integrity Property:

– Subject can modify object only if integrity class at least as high as the object. (untrusted subjects reduce integrity class when writing)

 * - Property: – Subjects may have write access only if the integrity of

objects they are reading is at least as high as the object to be written. (untrusted sources reduce integrity of results)

Integrity Preservation  A high integrity file is one whose contents

are created by high-integrity processes. – high-integrity file cannot be contaminated by

information from low-integrity processes. – high-integrity process cannot be subverted by low

integrity processes or data.

 The integrity class label on a file guarantees that the contents came only from sources of at least that degree of integrity.

Picture: Integrity

S

Public

Proprietary

Read above, write below

S

Public

Proprietary

Read below, write above

Problem: Models are contradictory   Bell-LaPadula Confidentiality

–  Read down, write up

  Biba Integrity –  Read up, write down

  Want both confidentiality and integrity –  Only way to satisfy both models is only allow read and write at

same classification

In reality: Bell-LaPadula used more than Biba model Example: Common Criteria

Sample Features of a Secure OS   Mandatory access control

– MAC not under user control   Object reuse protection

– Write over old data when file space is allocated   Complete mediation

–  Prevent any access that circumvents monitor   Audit support   Intrusion detection

– Anomaly detection »  Learn normal activity, Report abnormal actions

– Attack detection »  Recognize patterns associated with known attacks

Basic Design Principles  Least privilege - fewest possible privileges for

user  Economy of mechanism - small, simple,

straight forward  Open design  Complete mediation - check every access  Permission based - default is denial of access  Separation of privilege - no single super user  Least common mechanism - avoid shared

objects  Easy to use

Monitor Model  General idea:

– Take user's request – Consult access control information – Allow or disallow request

 Advantages – Easy to implement – Easy to understand

 Disadvantages – Bottleneck in system – Controls only direct accesses (not inferences)

Security Kernel   Responsible for implementing the security

mechanisms of the entire operating system.   Provides the security interfaces among the

hardware, the operating system, and the other parts of the computing system.

  Implementation of a security kernel: –  May degrade system performance (one more layer). –  May be large. –  No guarantees.

  Designing a security kernel is hard –  Linux, MacOS, and Windows do not have one –  Virtual machine managers act as security kernels

Security Enhanced Linux   Developed by NSA

–  Partly based on work done at Utah!

  Enforces separation of information based on confidentiality and integrity requirements

  Mandatory access control incorporated into the major subsystems of the kernel

–  Limit tampering and bypassing of application security mechanisms

–  Confine damage caused by malicious applications

http://www.nsa.gov/research/selinux/

SELinux Security Abstractions   Type enforcement

–  Each process has an associated domain –  Each object has an associated type –  Configuration files specify

»  How domains are allowed to access types »  Allowable interactions and transitions between domains

  Role-based access control –  Each process has an associated role

»  Separate system and user processes –  configuration files specify

»  Set of domains that may be entered by each role

  Security model is complicated and powerful –  Hard to get right, too

SELinux   Open source

–  Already subject to public review »  This by itself does not guarantee security …

–  NSA can review source, modify and extend –  Hope to encourage additional operating system security research –  Released under the same terms and conditions as the original

sources. »  includes documentation and source code

  Bad about SELinux: –  Hard to use –  Policies are very large and complex –  Makes it harder to exploit kernel bugs, but doesn’t eliminate them –  Any device driver can simply disable SELinux!

CS 5460: Operating Systems

Questions?

(This lecture is derived from material by Tim Shimeall at CMU and John Mitchell at Stanford)