Front page

Project course on System Security

The course focuses on the development of secure systems. This is a project course, so the main workload is on designing and developing security mechanisms for your project.

Intended Learning outcomes:

After passing the course, the students should be able to:

  1. Identify vulnerability of systems, exploit them, and evaluate their impact
  2. Compare efficacy of alternative countermeasures,
  3. Design and implement security mechanisms for computer systems
  4. Document his arguments and results

in order to evaluate and improve the security of a system.

Project scope

The project should focus on System Security. As a group you can choose three platforms

  • s3k: For the first time, this year the lectures and tutorials will focus on explaining how s3k works. s3k is a separation developed at KTH based on capability model and focuses on providing timing isolation.
  • Other systems (linux, llvm, qemu, hypervisors, etc). We do not offer learning material on other platforms. If you want to work on something different than Minix or s3k you must implement a state of the art project for a platform that you already know.

Course structure

The course responsible is Roberto Guanciale (robertog@kth.se). We strongly advice to use Canvas for communication. If you want to communicate via e-mail, use the mail subject [DD2497]...

Roberto's office is in Building D, level 5, room 4529. Roberto's zoom account is https://kth-se.zoom.us/my/guancio Links to an external site.. 

Course structure

The course consists of the following elements 

  • 1 introduction lecture on system security. In this lecture we will discuss motivations and course structure. This lecture will be on-campus.
  • 4 lectures/tutorials on s3k. These lectures explain the internals of a small operating system. This lecture will be on-campus.
  • 4 lectures on system security. In this lectures we will present state of the art solutions that have been published in security conferences. These lectures will be on-campus
  • a Project (done by you)

The lectures and tutorials will start in November and will end in December. You can work on the project until the final assessment that is in January. The course is 7.5 credits and involves Roberto Guanciale and one teaching assistant (Henrik).

Course material

  • Slides
  • Lectures (also recorded)
  • Research papers

Course info and breaking news

Check Canvas regularly for updates and when possible ask general questions in Canvas. (https://www.kth.se/social/course/DD2497).

  • Confirm registration before November 1
  • Check KTH Social Schedule for times and places. 

Groups

The project is done in groups.

  • 4 students per group
  • Individual assessment (i.e., one student of a group can fail even if the others pass the course)
  • The same group for the whole course
  • Group formation:
    • There are 20 pre-groups in Canvas, 2 students per pre-group
    • You are free to choose the pre-group that you prefer (i.e. you can choose your pre-group partner) (by October 30th
    • If you don't want to chose a partner, choose a random empty pre-group, so we know that you will participate to the course
    • We will randomly pair pre-groups to form groups
  • Give us access to your group github repository and show me that all group members added one line to the README by November 3th

Support

  • 1 hour / week per group meeting with TA
  • 1 hour / week per group meeting with teacher (physical or remote)
  • Mandatory 1 meeting per week
  • Mandatory 1 meeting with teacher every two weeks
  • Mandatory 1 meeting with TA every two weeks

Code of conduct.

  • Standard KTH Code
  • In case you discover new vulnerabilities do not exploit them, use responsible disclosure
  • It is OK to have different expectations/commitment in the same group
    • Make clear to your colleagues your expectations
    • Divide tasks so that everyone can contribute
    • Remember: individual assessment
  • If a student quit the course, the corresponding group must inform us as soon as possible
  • If there are problems in the group, please inform us as soon as possible. Waiting the end of the course to report that there are problems has been one of the two reasons of failure in the past.

Advises.

  • Set up you working environment as soon as possible. Developing an OS takes time and building the tool-chain requires few hours of compilation. Be sure that you can work on the project
  • Compiling/testing/debugging Oses is a relatively slow process. Spend more time reviewing your code and planning changes.
  • Documentation is a bit minimal, but you have projects from previous years, and code bases are quite small
  • For s3k: If possible, set up you computer with Ubuntu 22.04. Cross compiling an OS requires many dependencies and we cannot guarantee that the tool chain works on other environment. In the worst case you could set-up a VM with Ubuntu 22.04, but I think it will be terribly slow. S3k can also be developed on Mac M1 computers.
  • If possible do not use lab computers. Cross compiling requires to build the entire tool chain (2 GB). Compiling it on a network disk (like your home on KTH systems) will slow down the process. 
  • Ask questions on Canvas

Assignments:

At least one exercise is mandatory (by Nov 10). The goal is to prove that you are ready to work on the project. The exercise is submitted by the whole group tagging your repository with exercise v1. If you want to re-submit your work, tag the repository with exercise v2, .... It is required that the repository has at least one commit per student in the group.

1 project: four milestones

  • Project specification by Nov 7
    • report of 2 pages
    • submitted by adding specification.pdf to your github repository
    • add a link to your github repo to your group page
    • tag your repository with "specification v1"
    • one single specification per group
    • I.e. Run-time monitor to prevent code injection
  • 70% seminar by Dec 18
    • code must compile and demonstrate some functionalities
    • tag your repository with "seminar v1"
    • 30 minutes seminar
    • one single presentation per group
  • Final release by Jan 19
    • individual submission
    • no need to synchronize submissions: i.e. it is possible that your part is ready but the contribution of another student must be completes.
    • tag your repository with "release v1 - "
    • add an individual report of 5 pages called report.pdf to the group github repository
  • Oral exam by Jan 26
    • One week after the Final release, in order to allow us to review your code
    • individual
    • questions on System Security (i.e., on two papers presented during the course, you can choose which papers) [10 minutes]
    • You present your contribution [10 minutes]_
    • Questions about your contribution [10 minutes]

Expected workload

  • 20 Hours Lectures
  • 4 Hours Administration
  • 36 Hours Exercises / learning the platform
  • 120 Hours Project
  • 8 Hours Seminar
  • 10 Hours Exam
  • total 200 hours = 7.5 ETCS

Your contribution

Things that makes assessment difficult

  • One GIT commit per project
  • No GIT commits by you
  • Never showing up at supervision meetings

Things that makes easy assessment

  • Subdivide tasks
  • Make clear the design choices
  • Clear interfaces between modules Ask for feedback (do not wait end of January). In 2020 20% of the students had to do supplementary work because they were not able to demonstrate their contribution.

Assessment

Grades: official (Ladok)

  • P: You have met the ILOs (and pass all assessments)
  • Fx: You contribution is not clear or you failed some assessments
  • F: You do not pass the oral exam or you do not contribute to the project

Grades: unofficial. We will write a recommendation letter for students that made a good/excellent work.

  • Project Report
    • Identify vulnerability of systems, exploit them, and evaluate their impact
      • P: Select an existing system, describe an existing vulnerability of the system and evaluate its impact
      • A: Find new vulnerability of the system selected or describe new weakness of the system developed during the course
    • Compare efficacy of alternative countermeasures
      • P: Compare efficacy of existing solutions to counter the vulnerability selected. Select one countermeasure to implement.
      • A: If a new vulnerability has been found: select and motivate a mechanism to counter the vulnerability If a new security mechanism has been designed: compare efficacy of SoA w.r.t. student’s proposal.
    • Design and implement security mechanisms for computer systems
      • P: Describe the design of the project and identify student contributions
  • Seminar
    • Identify vulnerability of systems, exploit them, and evaluate their impact
      • P: Present the selected vulnerability and its impact
    • Compare efficacy of alternative countermeasures
      • P: Compare different approaches and motivate the one selected for the project
    • Document his arguments and results
      • P: The ILO itself
  • Project
    • Identify vulnerability of systems, exploit them, and evaluate their impact
      • P: Write a tool to exploit an existing vulnerability of an existing system
      • A: Write a tool to demonstrate a weakness of the project developed during the course
    • Compare efficacy of alternative countermeasures
      • P: Select a countermeasure to implement.
    • Design and implement security mechanisms for computer systems
      • P: Implement an existing security mechanism. Limit the number of new vulnerabilities (i.e. buffer overflow, misconfigurations, DOS). Demonstrate that the project counters the selected vulnerability.
      • A: Develop a new security mechanism or adapt an existing security mechanism to counter a new vulnerability. Do not introduce any major new vulnerability (i.e. code injection, bypass of authentication) Take into account the feedback received during the seminar Use modular, failsafe, and security aware design. Implement an efficient and maintainable system
  • Oral Exam
    • Identify vulnerability of systems, exploit them, and evaluate their impact
      • P: Explain the vulnerability countered by the project
      • A: Evaluate the impact of a new attack scenario
    • Compare efficacy of alternative countermeasures
    • P: Explain the benefits and limitations of the countermeasure developed
    • A: Compare the project proposal w.r.t. a different approach (proposed by the teacher)
    • Design and implement security mechanisms for computer systems
    • P: Demonstrate personal contribution to the project.
    • A: Discuss design changes required to handle new attacks
    • Document his arguments and results
      • P: See ILOs 1-2-3
      • A: Motivate the implementation and design choices