SystemsSec 2016W Lecture 3

From Soma-notes
Revision as of 20:41, 18 January 2016 by Derekaubin (talk | contribs)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

Topics & Readings

  • Trent Jaeger's Operating Systems Security is the textbook we are currently using (Reading it Helps)
  • Notes
  • Chat
  • Names
  • Hacking Journal → Starting next week (Hand in weekly)
    • Grading
    • Brainstorming


Class Notes:

Hacking Journal:

2 Note takers per class for participation marks. Make sure to say your name before you talk in order to receive participation marks. Check e-mails for DISCORD app, for a chat room that is set up for this course to discuss Hacking topics.

Hacking Journal (Record of PAIN)

  • Weekly hand-ins (3-4 hours a week)
  • Grades per week as follows:
                       0 → no Submission, 1 → Handed in, 2 → On the right track
  • End of semester the grade will be given based on journals as a whole.
  • Journal outline
  • Date, Time, Durations, Description or explanation of hack or a development of your thinking behind the process chosen. (TXT File)

Brainstorming:

         You may use the text book, tutorials,  and class exercises to get you started (getting familiar with hacking and defense against hacking).
  • Hacking opportunities (Breadth/Depth)
  • Class exercises/tutorials
  • Not just breaking into a system but rather how you can mess with a security feature. Playful fun hacks.
  • Not just tutorials, more so playing
  • Analysis of how a hack could be done (security analysis) but not only these
  • Not just one project all semester
  • You may extend on projects from other classes but not use the same thing.
  • Setting up of systems to be used for hacking opportunities is highly encouraged. Specifically Linux systems
  • The set up can be documented in your hacking journal
  • Making systems do what they are not supposed to do
  • Repository of exploits for many types of machines (METASPLOIT)
  • Many system specific exploits
  • Hackthissite.org is a good place to start for web security
  • We are allowed to run an old OS and play with its security systems (Old or New)
  • Weekly submissions will be marked based on progression throughout the course (Moving forward)
       - ***MONDAY WILL BE FIRST SUBMISSION OF HACKING JOURNAL [MIDNIGHT ON MONDAY]***
  • Expected to be submitted on time
  • Don’t be a developer be a hacker (Security Hacking)
  • Key loggers are boring, don’t make one unless Android version. If you are going to build something, then do it where little already exits.
  • Bug bounties (You keep the money!)
  • Do research till you cant find much info on a topic and then work from there.
  • Do not work on non-authorized systems
  • Teams are allowed but don’t be a freeloader
  • Go off the rails and collaborate!
  • Hoping that some students will find interesting vulnerabilities

Important Concepts

  • Protection domains
  • separating O/S into boundaries so things don’t mess with other things unless they are supposed to. O/S’s try to separate things into different parts, Processes and resources. We don’t not want either to access everything on the system.
  • Access matrix

Processes| Resource

                  | A | B | C |		
1   |             | r | rw| w |
2   |             | r | r | w |
3   |             |   | rw| r |

This matrix will be very sparse. We want something to aggregate. We need to aggregate process and resources. This is normally not enough.

  • Capabilities vs ACL’s (Access Control Lists)

Capabilities: Each process has a list of what it can access

       ACL’s: A list associated with each object that contains all the processes that can access that object.

Unix permissions are very impoverished ACL.

* A process should not be able to change its own capabilities

  • But why do this at all?
    • Rules and restrictions but why?
    • Done so programs don’t leak info of one user to another.
    • i.e. Top secret info
    • How do we make sure no one cheat’s?

Mandatory Access Control (MAC)

    • Permissions are set and stone
    • Cannot be changed at run time
    • Must boot into special mode with password
    • Rigid system
    • SELINUX
    • Root can’t do everything!

Discretionary Access Control (DAC)

    • Most of us use these systems
    • Users have the ability to change things
    • Windows and Linux are discretionary

* Assignment next week *


This is all from chapter 2 information from the textbook. Assignments will be confirmation of tests.


    • Reference Monitor

How do we keep programs from breaking these rules?

      • Make sure all rule enforcement runs through a small program “The Rule Enforcer”
      • You cannot by pass or mess with it
      • There must be no bugs therefor elaborate testing must be done.
      • Forbid inter communications between processes
      • What about covert channels?
    • MULTICS