Security 1 © 2000 Franz Kurfess Course Overview Principles of Operating Systems  Introduction  Computer System Structures  Operating System Structures  Processes  Process Synchronization  Deadlocks  CPU Scheduling  Memory Management  Virtual Memory  File Management  Security  Networking  Distributed Systems  Case Studies  Conclusions

Security 2 © 2000 Franz Kurfess Chapter Overview Security  Motivation  Objectives  Protection  protection of resources  protection methods  Access Control  Security  threats  protection mechanisms  Important Concepts and Terms  Chapter Summary

Security 3 © 2000 Franz Kurfess Motivation  computer systems may be of considerable value and must be protected from damage  hardware, software, and stored data may be essential for the performance of tasks and need to be available when needed  system objects need to be protected from inadvertent unauthorized access or use  there is the possibility of intrusion, modification, deletion, etc. with malicious intent

Security 4 © 2000 Franz Kurfess Objectives  know basic protection methods and mechanisms  be aware of the most common threats to system security  evaluate tradeoffs between performance, ease of use, flexibility, etc. on one hand and security on the other hand

Security 5 © 2000 Franz Kurfess Protection  methods and mechanisms that check the legality of an operation on an object in the computer system  legality refers to  the authorization to perform an operation  the appropriate use of an operation  the validity of the parameters  objects can be  hardware components  software entities  OS components, user programs  files, processes, pipes, etc  data

Security 6 © 2000 Franz Kurfess Policy vs. Mechanism  protection = policy + mechanism  policy  set of rules implemented by a mechanism  determined by the management of the system  mechanism  means for accomplishing a task  used for implementing and enforcing a policy

Security 7 © 2000 Franz Kurfess Computer Objects  objects in a computer system that need to be protected  hardware objects  CPU, memory segments, hard disk, printers, tape drives, etc.  software objects  files, processes, databases, semaphores, pipes, etc.

Security 8 © 2000 Franz Kurfess Protection Domain  a domain is a set of rights to perform certain operations on certain objects  specified as (objects, rights) pairs  each pair specifies an object and operations that can be performed on the object  limit and control access of processes  to objects they are authorized to use  only with operations they are authorized for

Security 9 © 2000 Franz Kurfess Minimum Privilege Principle  a process should have only the capabilities needed to perform its task  a protection domain must be tailored to each individual process  not practical for most systems  in practice, processes with similar domains are grouped together

Security 10 © 2000 Franz Kurfess Protection Domains in UNIX  the domain of a process is determined by  its user id (uid)  its group id (gid)  a process may switch temporarily between different domains  e.g. to execute a program owned by another user  this is a security problem, especially when user processes switch to the root domain

Security 11 © 2000 Franz Kurfess Access to Resources  computer system resources  hardware  deliberate or accidental damage, theft, unauthorized use  physical access to hardware may be restricted  software  execution, modification, deletion, unauthorized copying  restricted privileges, configuration management  data  modification or destruction, unauthorized use  restricted privileges, encryption, off-line storage  communication  eavesdropping, traffic analysis, intrusion, forging of messages, denial of service  prevention, detection, encryption, isolation

Security 12 © 2000 Franz Kurfess Access Control  subject  entity requesting access  usually a process (UID and GID on UNIX)  users are represented by processes  object:  entity to be accessed  CPU, memory, network, files, programs  access right  operations the subject is allowed to perform on the object

Security 13 © 2000 Franz Kurfess Unix Access Control  subjects  divided into three domains  user, group and others (not user)  objects  primarily files  access to devices through the file system  access rights  three types  read  write  execute

Security 14 © 2000 Franz Kurfess Access Matrix  specifies for each domain and each object the permissible operations  rows hold domains  objects are in the columns  entry access(i,j)  specifies the set of operations that a process executing in domain Di can perform on object Oj

Security 15 © 2000 Franz Kurfess Access Matrix Diagram File1 File2 File3 Printer Domain rrw rx r w  the operations specified in the entry are allowed for processes in a certain domain for a particular object

Security 16 © 2000 Franz Kurfess Domain Switching in an Access Matrix File1 File2 File3 Printer D1 D2 D3 Domain rrw rx r w switch  switching between domains can also be controlled by the access matrix  additional columns for the target domain

Security 17 © 2000 Franz Kurfess Implementation of Access Matrices  global table  access lists  capability lists

Security 18 © 2000 Franz Kurfess Global Table  set of ordered triplets  for each operation of a subject on an object, the table is searched for a triplet such that  the subject must be in the domain  the object must be present  the operation must be part of the rights  advantage  simple realization  drawbacks  large tables, requiring virtual memory or I/O operations  groupings of entries not possible

Security 19 © 2000 Franz Kurfess Access Control Lists  each object has a list of pairs with (domain, access rights)  specifies which operations may be performed by which entity  columns are implemented as lists  only non-empty entries are stored  used in the VMS operating system

Security 20 © 2000 Franz Kurfess Example  File1: (john, rw)  File2: (mary, rwx)  File3: (john, r), (mary, rw), (fred, rx)  File4: (*, rx)  File5: (fred, -), (*, rw)

Security 21 © 2000 Franz Kurfess Capability List  for each domain in the access matrix we associate a list of objects along with the type of access for each object  each row is implemented as a list  objects within a domain  operations allowed on the objects  a process presents the capability for an operation to the OS before the operation is performed  maintained by the OS, not directly accessible to the users

Security 22 © 2000 Franz Kurfess Example File r w - Pointer to file2 File r - x Pointer to file1 File r w x Pointer to file3 File - w - Pointer to file4 Type Rights Object

Security 23 © 2000 Franz Kurfess Comparison  access lists  correspond directly to the needs of the users  determining access rights for a particular domain is difficult  permissions for all objects must be specified  frequently a default list is used, and only deviations are noted explicitly  every access to an object must be checked  requires a search of the access list  capability lists  do not correspond directly to the needs of the users  useful for finding information on a particular process  revocation of capabilities may be inefficient  not very frequently used in their pure form  sometimes used as cache for information in the access list

Security 24 © 2000 Franz Kurfess Modification of Access Rights  permissions for operations on objects may change dynamically in a system  this can lead to the extension or revocation of access rights  easy with an access-list scheme  corresponding rights are modified  difficult with capability lists  capabilities are distributed throughout the system, and must be found first

Security 25 © 2000 Franz Kurfess Authorization  granting of permissions for operations on objects to subjects

Security 26 © 2000 Franz Kurfess Authentication  users  other systems

Security 27 © 2000 Franz Kurfess User Authentication  identification of users at login time  an be addressed through  passwords  physical identification

Security 28 © 2000 Franz Kurfess Passwords  legitimate users identify themselves by providing an account id and a password  if the password matches the one stored in the system, the user is considered legitimate  the password must be kept secret  must not be exposed by the user  must be stored internally in encrypted format or in a protected place  easy to understand and use  low implementation overhead

Security 29 © 2000 Franz Kurfess Password Problems  often easy to defeat  password guessing with the use of a list of likely words  watching while the user types the password (shoulder surfing)  network sniffing  account sharing

Security 30 © 2000 Franz Kurfess Example Password Cracking  7-character passwords chosen from a 95 printable character set: 95 7 (or 7x10 13 approx.)  at 1000 encryption/sec it will take 2000 years to create the complete list

Security 31 © 2000 Franz Kurfess Password Secrecy  extension and encryption  associate an n-bit random number with each password  the number is stored in the password file unencrypted  the password and the random number are first concatenated and then encrypted together and stored in password file  increases the size of the possible passwords by 2 N

Security 32 © 2000 Franz Kurfess Passwords Provisions  system-generated passwords  random, easy to remember, but nonsense words (i.e. vriendly) are generate by the system  regular change of passwords  may defeat the purpose  users write down passwords  toggling between passwords  use of month/year in the password  paired passwords  users provide a list of questions and answers that will be stored in encrypted format  the system randomly selects an entry which the user has to complete  user picks an algorithm

Security 33 © 2000 Franz Kurfess One-Time Passwords  each password can be used only once  frequently based on special hardware calculators or code books to determine the one-time password  complicated to administer

Security 34 © 2000 Franz Kurfess Physical Identification  plastic card with magnetic stripe and password (cash machines)  often augmented by personal identification numbers (PIN)  fingerprints, voice prints, visual recognition  signature

Security 35 © 2000 Franz Kurfess Security  application of protection methods and mechanisms to maintain the safe operation of a computer system  must also take into account the external environment of the system  cannot rely on orderly behavior of users and processes  users may try to circumvent protection mechanisms

Security 36 © 2000 Franz Kurfess Security Aspects  physical security  prevention of unauthorized access to physical systems  restriction to legal use of systems  operational security  subjects may only execute legal operations on objects

Security 37 © 2000 Franz Kurfess Security Threats  technical  interruption  interception  modification  fabrication  nontechnical (“social engineering”)

Security 38 © 2000 Franz Kurfess Security Threats in OSes  most operating systems have major security problems  penetration teams can be used to test security and expose problems

Security 39 © 2000 Franz Kurfess Common Attack Methods  snooping and sniffing  listening in on network traffic  ask for memory pages, disk space or tapes and just read them (don't fill them)  many systems don’t delete old information  trial and error on system calls  illegal system calls, legal system calls with illegal parameters, or legal system calls with legal but unreasonable parameters  example: “ping of death” attack  login interrupt  start logging in and then hit DEL RUBOUT BREAK (or other control keys) halfway through

Security 40 © 2000 Franz Kurfess Attack Methods (Cont.)  OS meddling  modify complex OS data structures residing in memory  do don’ts  look for manuals that say Do not do X and try as many combinations of X as possible.  social engineering  bribe or trick the security personnel

Security 41 © 2000 Franz Kurfess Intruders  persons from outside seek unauthorized access to a computer system  frequently via network connection  intruders are often referred to as hackers or crackers  legitimate users make unauthorized use of a system  evasion of auditing or access controls

Security 42 © 2000 Franz Kurfess Program and System Threats  Trapdoors  Logic Bombs  Trojan Horses  Viruses  Bacteria  Worms

Security 43 © 2000 Franz Kurfess Taxonomy of Software Threats [Bowles and Pelaez, 1992] Malicious Programs Trap Door Logic Bomb Trojan Horse VirusBacteriumWorm Needs Host Program Indepen- dent replicate

Security 44 © 2000 Franz Kurfess Trap Door  hidden entry point to the system  often left by the designer of a program  for debugging or malicious purposes  can circumvent normal security procedures  can be very difficult to detect

Security 45 © 2000 Franz Kurfess Example Trap Door  an employee of a bank works on the transaction processing system used by the bank  to be prepared for unpleasant situations at work, she leaves an entry point into the system  she’s fired for security violations  after she’s fired, she gains access via modem, transfers a large amount of money to an account on a Caribbean island, and erases all files

Security 46 © 2000 Franz Kurfess Confinement Example  you’re a great physicist working on a novel approach to the unified theory of everything  unfortunately, your programming skills are not sufficient, and you have to trust programmers  they know only the code, but not some critical values that you enter interactively  you inspect their programs, compile and install them yourself to make sure that there is no communication outside your own account  you perform all your simulations and calculations  you’re ready to publish your results when you see an article written by your programmers with your results

Security 47 © 2000 Franz Kurfess Confinement Problem  can programs be written in such a way that the information used and generated cannot be communicated outside the domain?  no network connection  no writing to files outside the domain  no usage of peripheral devices  problem: covert channels  information can be transmitted through indirect ways  relies on properties of the process execution that can be observed by other processes  length of CPU bursts, paging rate, etc.

Security 48 © 2000 Franz Kurfess Logic Bombs  segment in a regular program that checks for certain conditions  when the conditions are met, some unwanted functions are executed

Security 49 © 2000 Franz Kurfess Example Logic Bomb  a contractor implements a logic bomb in a library circulation system  the bomb is designed to go off on a certain date unless the contractor had been paid

Security 50 © 2000 Franz Kurfess Trojan Horses  (seemingly) useful program containing hidden code that may perform unwanted functions  hidden segment misuses its current environments  runs in the user’s environment with all the user’s privileges  often hidden in regular programs  e.g. login program, , editor

Security 51 © 2000 Franz Kurfess Examples Trojan Horse  Example 1: True friends  you’re working on a programming assignment together with your friend  for testing purposes, you make your programs executable for each other  you invoke your friend’s program, and it deletes all your files  Example 2: Password Stealing  a user writes a program that looks exactly like the login procedure for a multi-user system  it is left on the terminal for the next unsuspecting user  this program reads the password and stores it  then it exits with an error message and lets the user continue with the regular login process

Security 52 © 2000 Franz Kurfess Viruses  fragment of code embedded in a legitimate program  designed to spread into other programs and systems  may be destructive or simply annoying  display of messages  program malfunctions  modification or deletion of files  system crash  most prevalent on single-user systems  weak protection  curiosity and negligence of users

Security 53 © 2000 Franz Kurfess Virus Protection  antivirus programs  practically all current programs are effective only against particular known viruses  safe computing  purchase only unopened media from reputable sources  avoid shared media  floppy disks, bulletin boards  if you have to share media, apply antivirus programs immediately

Security 54 © 2000 Franz Kurfess Bacteria  programs that consume system resources by replicating themselves  bacteria may reproduce exponentially, eventually taking up all resources

Security 55 © 2000 Franz Kurfess Worms  programs that replicate themselves and send copies across network connections  may perform unwanted functions in addition to replication

Security 56 © 2000 Franz Kurfess Internet Worm  one of the greatest computer security violations of all times  Robert Morris, Cornell University, first year graduate student  unleashed Nov. 2, 1988  propagated to thousands of computers on the Internet  Sun 3 workstations and VAX computers running Unix BSD 4.x

Security 57 © 2000 Franz Kurfess Internet Worm cont.  worm components  grappling hook (99 lines of C code)  the worm proper  strategy  compile and execute the grappling hook on the machine under attack  upload main worm  contact new hosts  spread the grappling hook

Security 58 © 2000 Franz Kurfess Worm Diagram Worm Grappling Hook Infected SystemTarget System finger rsh sendmail worm sent worm request

Security 59 © 2000 Franz Kurfess Internet Worm cont.  transmission methods to infect new machines:  rsh  finger  sendmail

Security 60 © 2000 Franz Kurfess Internet Worm cont.  limited replication  on an already infected machines new copies of the worm would exit, except for every seventh instance  caused a major disruption on affected systems  may have been intended as harmless

Security 61 © 2000 Franz Kurfess Remote Shell Flaw  frequently accessed remote hosts can be listed in a file.xhosts  remote shells can be invoked without password  the worm used these files to propagate to trusted new hosts

Security 62 © 2000 Franz Kurfess  invoking finger with an argument that exceeds the buffer of the finger demon results in an overwrite of the stack frame  the finger demon continued with the execution of the argument instead of returning to its main routine Finger Flaw

Security 63 © 2000 Franz Kurfess Sendmail Flaw  the debugging option of the sendmail program is often left on as a background process  intended for testing purposes  usually invoked with a user address  the worm called debug with commands to mail and execute a copy of the grappling hook

Security 64 © 2000 Franz Kurfess The Worm’s Demise  on the evening of the next day countermeasures were circulated to system administrators  reasons for success  quick electronic communication  access to source code  distribution of source code and executables to remote machines  collaboration of experts  Morris was convicted in federal court ($10,000 fine, 3 years probation, 400 hours of community service, legal fees)

Security 65 © 2000 Franz Kurfess Countermeasures  prevention  possible threats are anticipated  this is not possible for all threats  mechanisms are installed to prevent attacks  detection  in case of an attack, it is identified and corrective measures are taken

Security 66 © 2000 Franz Kurfess Countermeasure Examples  access restrictions  users are only allowed to login from a specific terminal, during certain days of the week, during certain hours of the day.  system dials the user back at a predetermined phone number  login  increase login time to discourage repeated login tries  record all logins  traps  easy to break in accounts  seemingly interesting information for intruders

Security 67 © 2000 Franz Kurfess Threat Monitoring  limited login attempts  if more than a few login attempts are unsuccessful, the login process is aborted  audit log  records time, user, type of access to objects  useful for recovery and prevention  considerable overhead  security check  systematic checks for security holes  usually done during low traffic times

Security 68 © 2000 Franz Kurfess Security Checks  periodic exploration of potential security holes  weak passwords  short, easy to guess  unauthorized set-uid programs  unauthorized programs in system directories  suspicious processes  running time, behavior, access to resources  improper file and directory protections  user and system directories and files  password file, device drivers, system programs  modifications to system programs

Security 69 © 2000 Franz Kurfess Design Principles for Security  system design should be public  better verification and discovery of flaws  minimum privilege principle  give each process the least privilege possible  default should be no access  check for authority and authentication  simple, uniform protection mechanisms at low levels  acceptable for users

Security 70 © 2000 Franz Kurfess Encryption  mainly used for transmission and storage of sensitive information  e.g. password file in Unix  basic mechanism  information is encrypted into an unintelligible format  this is stored or transmitted  the receiver or reader must decrypt it into readable format  encryption frequently relies on operations that can be done efficiently in one direction, but the inverse operation is very difficult to do  e.g. factorization of large integers

Security 71 © 2000 Franz Kurfess Important Concepts and Terms  access control  access control list  audit log  authentication  capability list  confinement problem  deadlock  decryption  digital signature  encryption  external security  internal security  object  operation  permission  private key cryptosystem  privilege  privileged instruction  protection  protection domain  right  security policy  starvation  subject  system mode  trojan horse  user mode  virus

Security 72 © 2000 Franz Kurfess Chapter Summary  physical and operational safety of computer systems can be important aspects  protection methods and mechanisms are available to prevent unauthorized access to and use of computer systems  especially networked computers are vulnerable to security threats like  trapdoors, logic bombs, Trojan horses, viruses, bacteria, worms  the main types of countermechanisms are  prevention and detection