XP The Florida State University

Document Sample
XP The Florida State University Powered By Docstoc
					Protection and Security

      Sarah Diesburg
      Operating Systems
      COP 4610

   Security: policy of authorizing
       Prevents intentional misuses of a system
   Protection: the actual mechanisms
    implemented to enforce the
    specialized policy
       Prevents either accidental or intentional
Security Goals

   Data confidentiality: secret data
    remains secret
   Data integrity: unauthorized users
    should not be able to modify data
   System availability: nobody can
    make a system unusable
Security Components

   Authentication determines who the
    user is
   Authorization determines who is
    allowed to do what
   Enforcement makes it so people can
    do only what they are allowed to do

   The most common approach:
       If I know the secret, the machine can
        assume that I’m the user
   Problems:
    1. Password storage
    2. Poor passwords
Password Storage

   Encryption
       Uses a key to transform the data
       Difficult to reverse without the key
   UNIX stores encrypted passwords in
       Uses one-way transformations
       Encrypts a typed password and
        compares encrypted passwords
Poor Passwords

   Short passwords
       Easy to crack
   Long passwords
       Tend to be written down somewhere
Original UNIX

   Required only lower-case, 5-lettered
   265 or 1 million combinations
       In 1975, it would take one day to crack
        one password
       Today, we can go through all those
        combinations < 1 second
Partial Solutions

   Extend password with a unique
   Require more complex passwords
       6 letters of upper, lower cases, numbers,
        and special characters
       706 or 100 billion combinations
       Unfortunately, people still pick common
Partial Solutions

   Delay every login by 1 second
   Assign very long passwords
       Give everyone a password calculator
        (credit card)
       Requires a physical theft to steal the
Authentication in Distributed

   Private key encryption of data
       Encrypt(Key, Plaintext) = Cipher text
       Decrypt(Key, Cipher text) = Plaintext
   Hard to reverse without the key
   With the plaintext and the cipher text,
    one cannot derive the key
   Provides secrecy and authentication,
    as long as the key stays secret
How to distribute the keys?

   Authentication server
       Keeps a list of keys
         Kerberos Protocol

         Keyxy is needed to talk between x and y

                                 Server S

Encrypt(KeyAS, “I want KeyAB”)

                    Client A                Client B

                     KeyAS                   KeyBS
        Kerberos Protocol

        Keyxy is needed to talk between x and y

                                   Server S

Encrypt(KeyAS,“Here is KeyAB and
a message to B”)

                   Client A                   Client B

                    KeyAS                      KeyBS
Kerberos Protocol

Keyxy is needed to talk between x and y

                         Server S

      Client A                                 Client B

       KeyAS                                    KeyBS

            Encrypt(KeyBS, “use KeyAB to talk to A”)
Additional Details

   Expiration timestamp for a key
       Prevents a machine from replaying
        messages (e.g., “deposit $100”)
   Checksum for an encrypted message
       Prevents modifications to a message
        (e.g., “deposit $1000”)
   KeyAS and KeyBS are renewed
    periodically to reduce their exposures
Public Key Encryption

   Separates authentication from secrecy
   Involves a public key and private key
       Encrypt(Keypublic, plaintext) = cipher text
       Decrypt(Keyprivate, cipher text) = plaintext

       Encrypt(Keyprivate, plaintext) = cipher text
       Decrypt(Keypublic, cipher text) = plaintext
Public Key Encryption

   Idea:
       Private key is kept secret
       Public key is advertised
Public Key Encryption

   Encrypt(Keymy_public, “Hi, Sarah”)
       Anyone can create it, but only I can read
        it (secrecy)
   Encrypt(Keymy_private, “I’m Sarah”)
       Everyone can read it, but only I can
        create it (authentication)
Public Key Encryption

   Encrypt(Keyyour_public,
           “I know your secret”))
       Only I can create it, and only you can
        read it

      Access matrix describes who can do
            File 1       Lisa’s diary File3
Bart        read,write   read
Lisa                     read, write

  -The matrix tends to be sparse
Access Control List

   Stores all permissions for all users with
    each object
   Analogy: a guard in front of a door
       Checks for a list of people allowed to
   UNIX: permission of each file is
    specified according to its owner,
    group, and the world
Capability List

   Stores all objects a process can touch
   Analogy: Keys
       A key owner has the right of entry
   Example: page tables
       Each process has a list of pages that it
        can access
Access Control List vs.
Capability List

   Access control list (commonly used)
       Easy to know who can access the object
       Hard to know which objects a user can
   Capability list
       A user knows the list of objects to access
       Hard to know who can access an object
           More difficult to revoke capabilities

   Enforcer programs check passwords,
    access control lists, and so on…
   In UNIX, enforcers are run as
   If there is a bug, you are hosed!
The State of the World in

   Authentication
       Poor passwords
       Nobody encrypts emails
   Authorization
       Coarse-grained access control list
       Often turned off for sharing
   Enforcement
       Buggy operating systems
Classes of Security Problems

   Eavesdropping is the listener
       Tap into the Ethernet and see everything
       Countermeasure: pressurized cabled
   Abuse of privilege
       If the superuser is evil, there is nothing
        you can do
Classes of Security Problems

   Imposter breaks into the system by
    pretending to be someone else
       Recorded voice and facial image
       Countermeasure: behavioral
        monitoring to look for suspicious
           Overwriting the boot block
Classes of Security Problems

   A Trojan horse is a seemingly
    innocent program that performs an
    unexpected function
       Countermeasure: integrity checking
           Periodically, check binaries against their
Classes of Security Problems

   Salami attack builds up an attack,
    one-bit at a time
       Example: send partial pennies to a bank
       Countermeasure: code reviews
Classes of Security Problems

   Logic bombs: a programmer may
    secretly insert a piece of code into the
    production system
       A programmer feeds the system
        password periodically
       If the programmer is fired, the logic bomb
        goes off
       Countermeasure: code reviews
Classes of Security Problems

   Denial-of-service attacks aim to
    reduce system availability
       A handful of machines can flood a victim
        machine to disrupt its normal use
       Countermeasure: open
Pentagon Traffic Analysis

   Before the 1991 Persian Gulf War
       Foreign intelligence tried to predict the
        starting date of the war

Pentagon Traffic Analysis

   So much for the element of surprise…

   Used to be the most popular system at
    universities before UNIX
   Thought to be very secure

   Source code for the password check:
    for (j = 0; j < 8; j++) {
      if (input[j] != pw[j]) {
           // go to error;
   Need to go through 2568 combinations

   Unfortunately, Tenex used virtual

              in memory      on disk
   A fast password check means that the
    first character is wrong (error)
   A slow check means that the first
    character is correct (page fault)

   2568 checks to crack a password is
    reduced down to 256 * 8 checks
The Internet Worm

   In 1988, a Cornell graduate student,
    RTM, released a worm into the
   The worm used three attacks
       rsh
       fingerd
       sendmail
The Internet Worm

   Some machines trust other machines,
    the use of rsh was sufficient to get
    into a remote machine without
The Internet Worm

   finger command did not check the
    input buffer size
       finger name@location
       Overflow the buffer
       Overwrite the return address of a
       Jump and execute a shell (under root
The Internet Worm

   sendmail allowed the worm to mail a
    copy of the code and get it executed

   The worm was caught due to multiple
       People noticed the high CPU load