E0-256

Computer Systems Security

Vinod Ganapathy
Lecture 1: Introduction

Slide #1-1
 Course Info
Everything you need for the course is at the
class website:
http://www.csa.iisc.ac.in/~vg/teaching/E0-256

Slide #1-2
 Syllabus
• Goal of the course:
• To get you up-to-speed on the state-
of-the-art in computer security
• The field is very dynamic: attacks and
defences continuously evolve.
• Most textbooks are woefully out of date.
• So, we will read research papers.
 Syllabus
• Computer security is a VERY broad area.
• Impossible to cover breadth in a single course:
• We will focus on some system security issues
• Memory-errors and sandboxes, Web, Cloud, IoT
and other emerging areas
• Even for these topics, we’ll only see the tip of the
iceberg. The realities are vast and deep. Goal is to
give you a taste of what’s there and encourage
you to start looking.
• Not even touching cryptography or privacy (see
other courses in the department)
 Reading research papers
• Not written in your usual textbook style
• Each paper written in a slightly different style
• Can take 3-4 hours to read a paper when
you’re starting off to truly understand and
appreciate the ideas that it presents.
• One of the goals of the course is to teach
you how to read research papers
• Getting to the core ideas of the paper
• Adding these core ideas to your “toolbox”
 Reading research papers
• Try to read the paper before coming to class.
– You may not understand everything, and
that’s okay. Just get a general feel for the
topic that the paper covers.
• In class, we will discuss the context,
background and technical details of the paper.
• Go home, and study the paper with your new-
found understanding.
 Reading research papers
• Most papers that we will read are seminal
research results
• Google the names of the authors
• These are the big-players in computer
systems security.
• Learn about their research by perusing
through other papers they have written
• A good way to come up with project ideas
 Other course-related stuff
• Weekly workload and what is expected.
• Evaluation components:
• HWs (not graded) +
• 2 Exams +
• Project
• Grading criteria
• Project details
ALL THESE DETAILS ARE ON THE CLASS
WEB PAGE!
 Grading
What this means
• If all of you do well, you all get A+
grades. The converse holds too :-)
• WYSIWYG:
• No room for uncertainty due to
“curving” issues.
• No back-and-forth discussions
at end of semester about the
grade you got
• Grades are non-negotiable
 Exams
• Will test deep understanding of material
rather than mere knowledge of material

• We have a strict, no-nonsense policy

against cheating. See the class webpage for
details.
 Project details
• See the class webpage: You’ll be building
an in-kernel sandbox to confine processes.
 Project details: “Yes” answers

• Yes, there is going to be a ton of learning

and coding
• Yes, you’re going to have to pace it out
• Yes, you’re going to ask for extensions to
the submission deadline.
 Project details: “No” answers
• No, there will be no extensions to the final
deliverable deadline
• No, what you heard from your seniors last
year is not going to help you this year
• No, copying code from others is absolutely not
acceptable.
 Attending class
You are encouraged to attend every class. But you're all
grown ups -- So no attendance policy will be enforced.

BUT, in each class, I will often cover material that is not in

the papers, not in the slides, and not in any textbook. The
exams may contain questions based on this material.

Slide #1-14
 Class discipline
Come to class on time
• Class starts at 10:00am, not 10:10am
• Unless otherwise noted, e.g., if there is
an interesting department seminar
(which I may ask you to attend as well).
• Sauntering into class 10-15 minutes late
is unacceptable

Slide #1-15
 Contacting us
++ Attend and ask questions in class
++ Be curious. Seek out and read research papers on
your own. I’m happy to provide pointers and you can
contact me or my students (in the CSSL lab) for
references to papers in topics that you’re interested in
pursuing further.

Slide #1-16
 Quiz time
Program P.c
Program Q.c
[P1] int *p;
[Q1] int *q;
[P2] p = 0x12345678h;
[Q2] q = 0x12345678h;
[P3] *p = 1;
[P4] printf (“%d”, *p); [Q3] *q = 2;

Consider the above two programs P.c and Q.c.

I have with me a uni-processor machine (i.e., only one CPU), that runs a
standard time-sharing operating system.
I then compile and run the programs concurrently, as shown in the next
slide.
 Quiz time
Program P.c
Program Q.c
[P1] int *p;
[Q1] int *q;
[P2] p = 0x12345678h;
[Q2] q = 0x12345678h;
[P3] *p = 1;
[P4] printf (“%d”, *p); [Q3] *q = 2;

$ gcc P.c -o P.out

$ gcc Q.c -o Q.out
$ ./P.out & ./Q.out

What are the output(s) of the printf statement on line [P4]?

Computer security is the study of …

• Weaknesses in systems and attacks

against them.
• Defending against such attacks
• Pro-actively protecting data against
various attacker models
Q1: Can you define a “secure system”?
Q2: Real examples of “secure systems”?
Slide #1-19
 A “cold boot” attack

Photos courtesy of: https://citp.princeton.edu/research/memory/media/

Slide #1-20
 A “cold boot” attack

Photos courtesy of: https://citp.princeton.edu/research/memory/media/

Slide #1-21
 Basic Components
• Confidentiality
– Keeping data and resources hidden
• Integrity
– Data integrity (integrity)
– Origin integrity (authentication)
• Availability
– Enabling access to data and resources

Slide #1-22
 Goals of Security
• Prevention
– Prevent attackers from violating security
policy
• Detection
– Detect attackers’ violation of security policy
• Recovery
– Stop attack, assess and repair damage
– Continue to function correctly even if attack
succeeds
Slide #1-23
 Threat Models
• A threat model is a set of assumptions
about the power of an adversary.
• The concept of a “secure system” is
defined with respect to a threat model
• Examples of threat models?

Slide #1-24
 Trusted Computing Base
• To prove that a system is “secure”
against a particular adversary, we often
make certain assumptions about
portions of the system.
• Those constitute the Trusted
Computing Base (TCB) of the system
• If the TCB is compromised, can no
longer guarantee security of the system.
Slide #1-25
 Trusted Computing Base
• Examples of the TCB on real systems?
• Given the TCB, is it reasonable for us to
place trust in the TCB? Or is our trust
misplaced?
• How low can you go on a real
system?

Slide #1-26
 Policies and Mechanisms
• Policy says what is, and is not, allowed
– This defines “security” for the
site/system/etc.
• Mechanisms enforce policies
• Real-world example: locks on door.
• Composition of policies
– If policies conflict, discrepancies may
create security vulnerabilities

Slide #1-27
 Policies and Mechanisms
• Policies
– Unambiguously partition system states
– Correctly capture security requirements
• Mechanisms
– Assumed to enforce policy
– Support mechanisms work correctly

Slide #1-28