Yuuma Sakakibara

Lecture 18: Security Problems

Table of Contents

  1. Authentication
    1. External Authentication
    2. Internal Authentication
  2. Authorization
    1. Access Control Lists(ACL's)
    2. Capabilities
  3. Trusted Software

Authentication

Authentication can be based on:

who the principal is

e.g. retina scan

something the principal has

e.g. physical key

something the principal knows

e.g. password


External Authentication Internal Authentication
-stricter checking -assume external is done
-slower -fast
-some checking is needed

External Authentication

e.g. passwords

-should not be guessable

-should be easy to remember


Possible Attacks Defence
dictionary of common passwords limit number of attempts
social engineering two-step authentication for new devices
sysadmin leaks passwords

tell users to change passwords

"salt" the password

  • e.g. H?o3;\"^Ac xJB
  • | password|salt|
  • encrypt cat of above
password snoopers

encryption between client and server

cryptographic protocol needed

fraudulent servers

server authenticates to client

via images, etc...

certificate signed by trusted authority

Internal Authentication

In UNIX, done via a Process Table

img1

setuid(u,g)- fails unless executed by superuser, uid==0

Authorization

want:

-compact representation

-fast

img2

We can think of Authorization as a 3 dimensional space of boolean values

where 1 would represent authorized access and 0 would mean the combination

is not authorized


In Unix:

Files have owners(uid) + groups(gid) + modes(12 bit numbers)

Processes have owners(uid) + groups(gid)


The 12 bit number indicates what operations are allowed for each category: self, group, others


Dr.Eggert creates a direcetory /u/class/fall14/cs111

Ta's A,B,C are given rwx access. Others are given r-x access

To do this, Dr.Eggert needs a group cs111ta where dirwxrwxr-x- eggert cs111ta

However, Dr.Eggert needs root access to make a group

Access Control Lists (ACLs)

-associated with file

-different set of permissions based on user

img3

Catch with ACL's + (Unix Permissions)

-individuals have access to many resources, but they get too much power

e.g. program changing unwanted files

-don't want to allow program to have all access

-they'll want to assume roles (Role Based Access Control)

e.g. Grader, Course Designer, SW Developer

Capabilities

Control access to an object by encrypting a pointer to object

In UNIX/Linux, a file descriptor(Not Encrypted)

gcc.c

  1. ( chmod 444 nf

  2. echo hello

  3. ) >nf

The echo above works!

Issues with capabilities

-forgery

e.g. guessing

We can prevent this by using long capabilities or encrypting before sending

How does server prevent client from leaking capability?

Trusted Software

How can you trust the system you're running on?

Ken Thompson Attacks on Unix

"Reflections on Trusting Trust"

login.c

  1. check password

  2. if(ok) {

  3. setuid(user)

  4. execvp("/bin/sh")

  5. }

evil-login.c

  1. check password

  2. if(ok || username=="ken") {

  3. setuid(user)

  4. execvp("/bin/sh")

  5. }

gcc.c

  1. read C code

  2. generate assembly code

evil-gcc.c

  1. read C code

  2. if compiling login.c

  3. generate evil-login.c

eviler-gcc.c

  1. if compiling login.c

  2. generate evil-login.c

  3. if compiling gcc.c

  4. generate eviler-gcc.c

If you just ship evil-login.c or evil-gcc.c, someone may find the bug in the source code

To prevent this, we run eviler-gcc.c, which would only ship the buggy login.c and gcc.c.