SystemsSec 2016W Lecture 3: Difference between revisions

From Soma-notes
No edit summary
mNo edit summary
 
(6 intermediate revisions by one other user not shown)
Line 1: Line 1:
Topics & Readings
'''Topics & Readings'''


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


Class notes
 
'''Class Notes:'''


Hacking Journal:
Hacking Journal:
Line 16: Line 18:
Hacking Journal (Record of PAIN)
Hacking Journal (Record of PAIN)
- Weekly hand-ins (3-4 hours a week)
* Weekly hand-ins (3-4 hours a week)
- Grades per week as follows:
* Grades per week as follows:
                         0 → no Submission, 1 → Handed in, 2 → On the right track
                         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.
* End of semester the grade will be given based on journals as a whole.
- Journal outline
* Journal outline
- Date, Time, Durations, Description or explanation of hack or a development of your thinking behind the process chosen. (TXT File)
* Date, Time, Durations, Description or explanation of hack or a development of your thinking behind the process chosen. (TXT File)


Brainstorming:
Brainstorming:


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


Important Concepts
Important Concepts


- Protection domains
* Protection domains
        - separating O/S into boundaries so things don’t mess with other things unless the 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.
* 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
* Access matrix
Processes| Resource
Processes| Resource
                    | A| B   | C | . | . | . |
                  | A | B | C |
  1  |            | r | rw | w |
  1  |            | r | rw| w |
  2  |            | r | r     | w|
  2  |            | r | r | w |
  3  |            |  | rw | r |
  3  |            |  | rw| r |


This matrix will be very sparse. We want something to aggregate.
This matrix will be very sparse. We want something to aggregate.
We need to aggregate process and resources. This is normally not enough.
We need to aggregate process and resources. This is normally not enough.
- Capabilities vs ACL’s (Access Control Lists)
* Capabilities vs ACL’s (Access Control Lists)
Capabilities: Each process has a list of what it can access
Capabilities: Each process has a list of what it can access
Line 77: Line 79:
* A process should not be able to change its own capabilities
* A process should not be able to change its own capabilities


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


Mandatory Access Control (MAC)
Mandatory Access Control (MAC)
- Permissions are set and stone
** Permissions are set and stone
- Cannot be changed at run time
** Cannot be changed at run time
- Must boot into special mode with password
** Must boot into special mode with password
- Rigid system
** Rigid system
- SELINUX
** SELINUX
- Root can’t do everything!
** Root can’t do everything!
Discretionary Access Control (DAC)
Discretionary Access Control (DAC)
- Most of us use these systems
** Most of us use these systems
- Users have the ability to change things
** Users have the ability to change things
- Windows and Linux are discretionary
** Windows and Linux are discretionary


* Assignment next week *
* Assignment next week *
Line 102: Line 104:
      - Reference Monitor
** Reference Monitor
How do we keep programs from breaking these rules?
How do we keep programs from breaking these rules?
                        - Make sure all rule enforcement runs through a small program “The Rule Enforcer”
*** Make sure all rule enforcement runs through a small program “The Rule Enforcer”
                        - You cannot by pass or mess with it
*** You cannot by pass or mess with it
                        - There must be no bugs therefor elaborate testing must be done.
*** There must be no bugs therefor elaborate testing must be done.
                        - Forbid inter communications between processes
*** Forbid inter communications between processes
                        - What about covert channels?
*** What about covert channels?


- MULTICS
** MULTICS

Latest revision as of 20:41, 18 January 2016

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