Protection and Security

1
Protection and Security

• Protection is a mechanism for controlling the
  access of programs, processes, or users to the
  resources of a computer system
• must provide means for specification of controls
  and of enforcement
• Security reflects the policy of the system.
  Also, a measure of confidence that the integrity
  of a system and its data will be preserved - a
  much wider topic..
• Protection provides a mechanism for the
  enforcement of policies
• important for the OS to avoid and detect errors
• should be available as a tool for the application
  programmer

2
Security

• Concerns - data loss intruders privacy
• Authentication - ability to identify the user
  and/or processes - in networked environments,
  identify computer
• two parts -
• external security - authorization (users)
• internal security - access to resources
  (processes)
• common approach - use passwords (a key)
• passwords can be guessed (too short too
  obvious)
• system keeps passwords encrypted - public
  encryption - one can use an intelligent
  dictionary instead of the inverted function
• network-wide login - password file is kept
  centrally

3
The Security EnvironmentThreats

• Security goals and threats

4
Intruders

• Common Categories
• Casual prying by nontechnical users
• Snooping by insiders
• Determined attempt to make money
• Commercial or military espionage

5
Accidental Data Loss

• Common Causes
• Acts of God
• fires, floods, wars
• Hardware or software errors
• CPU malfunction, bad disk, program bugs
• Human errors
• data entry, wrong tape mounted

6
Policies and Mechanism

• Policies general guidelines on authorization in
  the system, examples
• Students can see their grades
• Only instructors can change grades
• Mechanisms techniques to enforce the policies
• Access control
• Encryption

7
Institution Policies

• Laws, rules and practices that regulate how an
  institution manages and protects resources.
  Another definition is high-level guidelines
  concerning information security
• Computer mechanisms should enforce these policies.

8
Principles of Security Policy

• Least privilege
• Individual responsibility
• Explicit authorization
• Separation of duty
• Auditing
• redundancy

9
Categories of Security Policies

• Mandatory vs. Discretionary (Need to Know).
• Ownership vs. Administration
• Centralized vs. Distributed
• Close vs. Open
• Name, Content or Context dependent
• Individual, Group or Role based
• Information Flow Control based

10
Some security policies

• Open/closed systems--In a closed system
  everything is forbidden unless explicitly allowed
• Need-to-know (Least privilege)-- Give enough
  rights to perform duties
• Ownership - Information belongs to the
  institution versus private ownership
• Access granularity access types or access units
  of access

11
Military Security Model
12
Internal Access Authentication
13
A protection system
14
The Access Matrix Model - DAC

• Subjects
• Users, groups, applications, transactions
• Objects
• Files, programs, databases, relations, URLs
• Access-types
• Read, write, create, copy, delete, execute, kill
• Authorization commands
• Enter, remove, transfer
• Authorizers
• Owners, users, administrators

15
The Access Matrix Model
Compatibility Lists Access Lists
16
A protection model

• Active parts (processes) operate in Protection
  domains, passive parts are called objects
• Objects in protection domains
• Hardware CPU memory segments disk drives...
• Software files data bases processes
  semaphores
• Objects have names and permissible operations
• Domains - sets of pairs (object, rights)

D1
D2
D3
ltO1, read,writegt
ltO1, executegt
ltO2, executegt
ltO4, writegt
ltO3, readgt
ltO2, readgt
ltO3, writegt
17
Protection mechanisms - Domains

• Domains do not have to be disjoint
• domain can be associated to a user, a process, a
  procedure (i.e. its variables)
• commonly, a process runs in one domain at one
  time
• the domain of a process may need to be switched
  to enable different operations
• switching domains is a well-defined operation of
  domains
• Changes applied to domains can also be part of
  domains, based on the following operations
• owner - can add/remove any right in any entry of
  column
• copy - can copy to any place in column
• control - members of domain Di can change rights
  in Dj

18
Domains - the Access Table

• a table of (domain,object) that stores
  permissions
• adding the domains to the objects represents
  domain switches as well

19
Options of Access Tables

• Copy rights - in the same column, to other
  domains
• transfer copy with right just copy
• Owner rights - anything in the same column
• enabling access rights to object, in other
  domains
• Control - only applies to domain-domain cells
  and enables one domain members to control other
  domain access rights

20
The Access Matrix Model

• Whats the difference between a Subject and a
  Domain ?
• A subject is usually a process. During its
  life-time, a subject may acquire rights or lose
  them. At a particular point of time, a subject
  has a given set of rights - thats a Domain!
• The concept of Amplification

21
Use of Access Matrix

• If a process in Domain Di tries to do op on
  object, then op must be in the access matrix.
• Can be expanded to dynamic protection.
• Operations to add, delete access rights.
• Special access rights
• Owner of Oi
• Copy op from Oi to Oj
• Control Di can modify Dj access rights
• Transfer switch from Domain Di to Dj

22
Access Matrix with Copy Rights
object
domain
(a)
object
domain
(b)
23
The HRU Model

• The Harrison-Ruzzo-Ullman model (called the HRU
  model) is very similar to the Graham-Denning
  model. The model is based on commands, where each
  command involves conditions and primitive
  operations.
• The structure of a command is as follows.

Command name(o1,o2,,ok) if
r1 in As1,o1 and r2 in
As2,o2 and . . .
rm in Asm,om then
op1
op2 . . .
opn end
24
Harison-Ruso-Ullman Model

• Access matrix with general commands
• Concept of system safety
• Is there an algorithm to decide whether a given
  set of commands can lead to an unsafe state?
• The general problem is
• Undecideable!

25
Harison-Ruso-Ullman Model

• Each HRU command is mapped into a write on a
  Turing machine tape
• The Safety problem is reduced into the Halting
  problem!
• Special case each command has only one action
  algorithm is decidable but may be exponential
  (P sidebar 5-2)

26
Use of Access Matrix

• Access matrix design separates mechanism from
  policy.
• Mechanism
• Operating system provides access-matrix rules.
• It ensures that the matrix is only manipulated by
  authorized agents and that rules are strictly
  enforced.
• Policy
• User dictates policy
• Who can access what object and in what mode

27
Access Control Lists

• The access matrix is too large and too sparse to
  be practical
• It can be stored by columns
• Objects have ordered lists of domains that can
  access them
• Access bits RWX express access to files by users
  and groups
• Prohibiting access specifically, by owner, can be
  expressed as
• File1 (Amnon,staff,RWX)
• File2 (,student,R--), (Rachel,,---)
• File3 (Mike,,R-X)

28
Access Control Lists (1)

• Use of access control lists to manage file access

29
Capability Lists

• Slicing the protection matrix by rows
• Users and processes have capability lists which
  are lists of permissions for each object
  appearing in a domain
• Hard to revoke access to objects, have to be
  found in c-lists.
• Capabilities are special objects, never
  accessible to user space objects - better
  protection
• Generic operations on c-lists
• Copy capability (from one object to another)
• Copy Object (with capability)
• Remove capability (an entry of the c-list)

30
Capabilities (1)

• Each process has a capability list

31
Capability List
procedure code
A
B
C
C-list
D
32
ACLs and Capabilities

• ACLs need not be in memory (adv), checked at the
  time of first access (disadv). C-lists need to be
  in memory (assigned at process creation)
• ACL is checked only at first access (open).
  Capability is checked for every access (ticket
  for addressing). But finer granularity! Security
  / performance tradeoff!
• Capabilities enable easy granting/copying
  amplification. No simple analog in ACLs (setUid?)

33
ACLs and Capabilities, cont.

• ACLs are more convenient for Objects changes
  (deleting objects, creating objects, changing
  access to objects).Capabilities are more
  convenient for User changes (user deletion)
• Revocation of ACLs is easy. Revocation of
  capabilities is hard
• Capabilities can be used to control Mobile code

34
Untrusted Systems
35
Trusted Systems

• Multilevel security
• Information organized into categories
• No read up
• Only read objects of a less or equal security
  level
• No write down
• Only write objects of greater or equal security
  level
• How to write non-classified info? The Watermark
  model!

36
Multilevel Security (1)

• The Bell-La Padula multilevel security model

37
(No Transcript)
38
Security in Unix

• Authentication passwords (encrypted)
• Users and Groups (limited)
• Memory and process protection via Virtual
  Memory
• File system security simplified DAC only 3
  groups of users (owner, group, all)
• Amplification - setuid

39
Domains of Protection in Unix

• Domains are defined for users
• processes have uid and gid permissions, which
  define completely their domains
• A user process can have a kernel part (via system
  calls) which moves it to a different domain
• processes EXECuting files with the SETUID
  (SETGID) bit on acquire a new uid (gid) and hence
  a new domain
• any file with a SETUID on, performs a domain
  switch

40
File System Security - Unix

• Octal Representation of Access Permissions

41
File System security - Unix

• Ownership Umask, Chown (problem with Setuid)
• Link (hard or soft)
• Amplification SetUid, SetGId

42
Protection of Files and Directories Unix
43
Unix Example for SetUid

• 1. chmod r grades
• ls 1 grades
• -rw-r--r-- 1 pat CS440 514 Apr 5 1826
  grades
• -rwx--x--x 1 pat CS440 1725 Apr 2 1026
  prgrades
• 2. chmod us prgrades Turn on SUID permission
• ls 1 prgrades
• -rws--x--x 1 pat CS440 1725 Apr 2 1026
  prgrades
• 3. chmod 600 grades Just give read/write to
  owner
• ls 1 grades
• -rw------- 1 pat CS440 514 Apr 5 1826
  grades
• -rws--x--x 1 pat CS440 1725 Apr 2 1026
  prgrades

44
Unix File System Security Violating Security
Principles SU

• Principle of Least Privilage (group access)
• Principle of Safe Defaults
• Principle of Need to Know (Others access,
  Super-user power)
• Principle of Accountability (setUid)
• Always there is Tradeoff
• Security / Convenience / Performance!

45
Windows-NT Security

• C2 Certified (mainly DAC and Authentication)
• Monitor based architecture (SRM) plus Clients
  modules (LSA, SAM) for Login Authentication
• Objects based Registry file for everything
• Authentication Passwords and Kerberos
• SID (Security ID) and SAT (Security Access
  Token). Remote authentication.
• Domains For set of machines. Machine (SID)
  Authentication.
• Groups and Subgroups

46
Windows-NT Security, cont.

• Security descriptors (in Registry)
• ACLs. ACE Access Control Entry Positive and
  Negative.
• User Profiles and Security Management.
• Auditing What and When.
• File Encryption.
• Web security, Certificates, SSL, etc.

47
Access Token

• Security ID
• Identifies a user uniquely across all the
  machines on the network (logon name)
• Group SIDs
• List of the groups to which this user belongs
• Privileges
• List of security-sensitive system services that
  this user may call

48
Access token

• Default owner
• If this process crates another object, this field
  specifies who is the owner
• Default ACL
• Initial list of protections applied to the
  objects that the user creates

49
Security Descriptor

• Flags
• Defines type and contents of a security
  descriptor
• Owner
• Owner of the object can generally perform any
  action on the security descriptor
• System Access Control List (SACL)
• Specifies what kinds of operations on the object
  should generate audit messages
• Discretionary Access Control List (DACL)
• Determines which users and groups can access this
  object for which operations

50
Windows2k - Security Descriptors

• A record that describes access rights for a
  given object ACL
• Entries in the SD can be defined by generic
  entities such as all users owner etc.
• SDs can be copied and used to describe any
  object
• Operations on SDs include adding and removing
  capabilities
• Much more flexible than Unix, can give a variety
  of rights to any set of users, per a given object

51
????? ????? ???? ?- Windows-NT
SecurityDescriptor
Security Descriptor
File
ACE
ACE
52
User Authentication

• Basic Principles. Authentication must identify
• Something the user knows
• Something the user has
• Something the user is
• This is done before user can use the system

53
Authentication Using Passwords

• (a) A successful login
• (b) Login rejected after name entered
• (c) Login rejected after name and password typed

54
Authentication Using Passwords

• How a cracker broke into LBL
• a U.S. Dept. of Energy research lab

55
Authentication Using Passwords
,
,
,
,
Password
Salt

• The use of salt to defeat precomputation of
  encrypted passwords

56
Authentication Using a Physical Object

• Magnetic cards
• magnetic stripe cards
• chip cards stored value cards, smart cards

57
Authentication Using Biometrics

• A device for measuring finger length.

58
Countermeasures

• Limiting times when someone can log in
• Automatic callback at number prespecified
• Limited number of login tries
• A database of all logins
• Simple login name/password as a trap
• security personnel notified when attacker bites

59
System Security threats

• Program Threats
• Trojan horse - a program that lets another user
  use it as if it was a system program. Thus,
  obtaining important security information, for
  example.
• Trap door - a program that includes a specially
  designed hole, that can be used only by the
  designer.
• System flaws (some ancient examples..)
• core linked to passwrd - program dump creates
  nice entries
• intervene in mkdir - after MKNOD, still in
  SETUID mode, link to passwrd, before chown to
  users.

60
Trap Doors

• (a) Normal code.
• (b) Code with a trapdoor inserted

61
Operating System SecurityTrojan Horses

• Free program made available to unsuspecting user
• Actually contains code to do harm
• Place altered version of utility program on
  victim's computer
• trick user into running that program

62
Logic Bombs

• Company programmer writes program
• potential to do harm
• OK as long as he/she enters password daily
• if programmer is fired, no password and bomb
  explodes

63
Login Spoofing

• (a) Correct login screen
• (b) Phony login screen

64
Famous Security Flaws
(a)
(b)
(c)

• The TENEX password problem

65
Buffer Overflow The most serious security problem

• (a) Situation when main program is running
• (b) After program A called
• (c) Buffer overflow shown in gray

66
Using system flaws - Worms

• November 2, 1988 attack from Cornell. Brought
  down thousands of computers on the internet
• Two parts - bootstrap and worm body
• Bootstrap part
• compiled under attacked system
• uploads worm body
• Worm body
• Hides itself
• Break passwords on new machine
• Spread bootstrap, using the new routing tables

67
Using system flaws - Worms (II)

• Methods of proliferation
• use rsh (for trusting machines) ..a trap
  door..
• use bug in finger daemon (.. Trap..)
• call finger with 536-byte parameter
• data overflaws buffer into daemon stack
• cause return into the program, residing as
  parameter
• execute /bin/sh
• use sendmail bug allowed loading executable
  copies
• Limit multiplication - when another worm is
  detected on the same machine, duplicate with a
  17 probability
• Main problem - too many worms killed systems !

68
Viruses - program segments

• Program segments attached to another executable
• When program is run, the virus proliferates
• actually a type of Trojan horse but not
  personal..
• Numerous possible actions
• erasing, modifying, encrypting files
• display extortion note send
• damage boot sector on hard disk (or ask for
  password..)
• Defenses
• look for known viruses in files
• perform checksum on files
• make directories of binary files unwritable for
  users...

69
Network Security

• External threat
• code transmitted to target machine
• code executed there, doing damage
• Goals of virus writer
• quickly spreading virus
• difficult to detect
• hard to get rid of
• Virus program can reproduce itself
• attach its code to another program
• additionally, do harm

70
Virus Damage Scenarios

• Blackmail
• Denial of service as long as virus runs
• Permanently damage hardware
• Target a competitor's computer
• do harm
• espionage
• Intra-corporate dirty tricks
• sabotage another corporate officer's files

71
How Viruses Work (1)

• Virus written in assembly language
• Inserted into another program
• use tool called a dropper
• Virus dormant until program executed
• then infects other programs
• eventually executes its payload

72
How Viruses Work (2)

• Recursive procedure that finds executable files
  on a UNIX system
• Virus could
• infect them all

73
How Viruses Work (3)

• An executable program
• With a virus at the front
• With the virus at the end
• With a virus spread over free space within
  program

74
How Viruses Work (4)

• After virus has captured interrupt, trap vectors
• After OS has retaken printer interrupt vector
• After virus has noticed loss of printer interrupt
  vector and recaptured it

75
How Viruses Spread

• Virus placed where likely to be copied
• When copied
• infects programs on hard drive, floppy
• may try to spread over LAN
• Attach to innocent looking email
• when it runs, use mailing list to replicate
• Method of detection signatures, size expansion,

76
Antivirus and Anti-Antivirus Techniques

• (a) A program
• (b) Infected program
• (c) Compressed infected program
• (d) Encrypted virus
• (e) Compressed virus with encrypted compression
  code

77
Antivirus and Anti-Antivirus Techniques

• Examples of a polymorphic virus
• All of these examples do the same thing

78
Antivirus and Anti-Antivirus Techniques

• Integrity checkers
• Behavioral checkers
• Virus avoidance
• good OS
• install only shrink-wrapped software
• use anti-virus software
• do not click on attachments to email
• frequent backups
• Recovery from virus attack
• halt computer, reboot from safe disk, run
  antivirus

79
Security in Java

• Language features verified by the Bytecode
  verifier
• Sandbox model using the Security manager
• No bypass of the security manager using the
  Class-loader

80
Security in Java Language Features

• No typedef or define
• No automatic type conversion
• No casting
• Strongly typed language
• Indexes to arrays and strings range validated
• Automatic garbage collection
• Use of OO features like Public, Private

81
Java Security (1)

• A type safe language
• compiler rejects attempts to misuse variable
• Bytecode Verifier Checks include
• 1. Attempts to forge pointers
• 2. Violation of access restrictions on private
  class members
• 3. Misuse of variables by type
• 4. Generation of stack over/underflows
• 5. Illegal conversion of variables to another
  type AND
• 6. All system calls are done via the Security
  Manager!

82
The Java Sandbox
Server
Web page
Applet
Applet (Byte code)
83
Java Security (2)

• Examples of specified protection with JDK 1.2
  possibility for Security policies!

84
Mobile Code (2)

• Applets can be interpreted by a Web browser

85
Mobile Code (3)

• How code signing works

86
Some cryptography
87
Cryptographic systems
88
Basics of Cryptography

• Relationship between the plaintext and the
  ciphertext

89
Secret-Key Cryptography

• Monoalphabetic substitution
• each letter replaced by different letter
• Given the encryption key,
• easy to find decryption key
• Secret-key crypto called symmetric-key crypto

90
Public-Key Cryptography

• All users pick a public key/private key pair
• publish the public key
• private key not published
• Public key is the encryption key
• private key is the decryption key

91
One-Way Functions

• Function such that given formula for f(x)
• easy to evaluate y f(x)
• But given y
• computationally infeasible to find x

92
Digital Signatures
(b)

• Computing a signature block
• What the receiver gets

93
Uses of Cryptography

• Protection of messages IPSEC, SSL, PGP
• File encryption
• Authentication
• PKI

94
Kerberos

• Kerberos -- the most important of the network
  authentication approaches. It is used in Windows
  2000 and other systems. It was developed at MIT
  and its name comes from Greek mythology. It has
  had several versions, the current one is version
  5. It uses the DES in its authentication
  protocol.

95
Kerberos
96
Kerberos
Once per user logon session
Request ticket granting ticket
Ticket session key
Request ticket granting ticket
Ticket session key
Once pertype of service
Request service
Provide service authenticator
Once perservice session
97
Design principles for security

• System design should be public
• assuming the intruder does not know the design is
  wrong
• Default permission should be no access
• Check for current authority
• e.g. each file-read or file-write, not just
  during open
• Give processes minimal permission
• e.g. editors have read/write access to the edited
  file only
• User authentication
• always encrypt passwords
• report failures record logins - NT
• Salting the password file (e.g. with random
  numbers)
• remote login callback limit where users can
  login

98
Design Principles for Security

• System design should be public
• Default should be no access
• Check for current authority
• Give each process least privilege possible
• Protection mechanism should be
• simple
• uniform
• in lowest layers of system
• Scheme should be psychologically acceptable

And keep it simple