SystemsSec 2016W Lecture 3: Difference between revisions
Jakebrown05 (talk | contribs) No edit summary |
Derekaubin (talk | contribs) mNo edit summary |
||
(3 intermediate revisions by one other user not shown) | |||
Line 1: | Line 1: | ||
Topics & Readings | '''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 | |||
'''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) | |||
* 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. | |||
* Journal outline | |||
* 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 | 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]*** | - ***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 | 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 | 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: 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? | |||
** 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) | 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) | 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 * | * Assignment next week * | ||
Line 102: | Line 104: | ||
** 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” | |||
*** 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 |
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