Tidy up
This commit is contained in:
103 files changed
+3663
-3779
No files matched your search
@@ -4,23 +4,23 @@
|
||||
|
||||
- Identification
|
||||
- Authentication
|
||||
- Lets us verify who we are to the system
|
||||
- Some files are private, some are public
|
||||
- System files must be protected
|
||||
- We need to be able to access applications
|
||||
- Lets us verify who we are to the system
|
||||
- Some files are private, some are public
|
||||
- System files must be protected
|
||||
- We need to be able to access applications
|
||||
- Access control
|
||||
- Auditing
|
||||
|
||||
#### Authentication & Authorisation
|
||||
|
||||
- Subject / Principle - an active entity
|
||||
- Subject / Principal - an active entity
|
||||
- Object - resource being accessed
|
||||
- Access operation
|
||||
- Reference monitor - grants or denies access
|
||||
|
||||

|
||||

|
||||
|
||||
**Principle**
|
||||
**Principal**
|
||||
|
||||
> “An entity that can be granted access to objects or can make statements affecting access control decisions”
|
||||
|
||||
@@ -39,32 +39,32 @@
|
||||
Files or resources - memory, printers, directories
|
||||
|
||||
- Two options for focusing control:
|
||||
1. What a subject is allowed to do
|
||||
2. What may be done to an object
|
||||
1. What a subject is allowed to do
|
||||
2. What may be done to an object
|
||||
|
||||
#### General Model
|
||||
|
||||
- We’ll settle on some common access files:
|
||||
- **Read** - Simply viewing (**confidentiality**)
|
||||
- **Write** - Includes changing, appending, deleting (**integrity**)
|
||||
- **Execute** - Can run a file without knowing its contents
|
||||
- **Read** - Simply viewing (**confidentiality**)
|
||||
- **Write** - Includes changing, appending, deleting (**integrity**)
|
||||
- **Execute** - Can run a file without knowing its contents
|
||||
|
||||
##### Ownership
|
||||
|
||||
- Who is in charge of setting security policies
|
||||
- **Discretionary**: Owner can be defined for each resource
|
||||
- Owner controls who gets access
|
||||
- Owner controls who gets access
|
||||
- **Mandatory**: There could be a system-wide policy
|
||||
- e.g. a government with different levels of security (top secret, level 3 clearance, etc)
|
||||
- Not commonly used for businesses
|
||||
- Most OS’s support the concept of ownership
|
||||
- e.g. a government with different levels of security (top secret, level 3 clearance, etc)
|
||||
- Not commonly used for businesses
|
||||
- Most OSs support the concept of ownership
|
||||
|
||||
### Unix
|
||||
|
||||
- Unix simplifies access control by considering only the *user*, *group* and *others*
|
||||
- User is the current owner
|
||||
- Group is the named group entity
|
||||
- Everyone else
|
||||
- User is the current owner
|
||||
- Group is the named group entity
|
||||
- Everyone else
|
||||
- Unix offers read, write and execute access controls
|
||||
|
||||
##### Groups
|
||||
@@ -76,23 +76,23 @@ Files or resources - memory, printers, directories
|
||||
|
||||
##### UID & GID
|
||||
|
||||
- Usernames in unix are soft aliases, your UID is what determines permissions
|
||||
- User identities: UID
|
||||
- Group identities: GID
|
||||
- Usernames in Unix are soft aliases; your UID is what determines permissions
|
||||
- User identities: UID
|
||||
- Group identities: GID
|
||||
- Your IDs are stored in `/etc/passwd`
|
||||
- This stores user accounts, not just passwords
|
||||
- This stores user accounts, not just passwords
|
||||
- Root has a special UID of 0
|
||||
|
||||
###### The Shadow File
|
||||
|
||||
- In an attempt to improve password security, we can store password hashes in a shadow file
|
||||
- Readable only by root users
|
||||
- Readable only by root users
|
||||
- `/etc/shadow` stores the hashed passwords needed to authenticate users
|
||||
|
||||
#### Root (Unix Superuser)
|
||||
|
||||
- Root’s UID 0 is actually hard coded into the Linux kernel at multiple points
|
||||
- In 2003, this anonymous change was made to the error value return in the `wait4` function is Linux:
|
||||
- In 2003, this anonymous change was made to the error value return in the `wait4` function in Linux:
|
||||
|
||||
```
|
||||
if ((options == (_WCLONE|__WALL)) && (current->uid = 0))
|
||||
@@ -107,15 +107,15 @@ Note: single `=`. This was a backdoor which sets the current uid to 0, giving ro
|
||||
- Separate superuser duties (e.g. daemon, uucp)
|
||||
- Never use root as normal user
|
||||
- Audit `su` and `sudo` usage
|
||||
- In unix, everything is a file
|
||||
- In Unix, everything is a file
|
||||
- Files really represent resources
|
||||
- Organised in a tree structure, with alterations depending on the file system
|
||||
- I-nodes store permission information
|
||||
- Every resource as a owner and a group
|
||||
- I-nodes store permission information
|
||||
- Every resource has an owner and a group
|
||||
|
||||
###### I-nodes
|
||||
|
||||
- I-nodes in unix store the metadata for files
|
||||
- I-nodes in Unix store the metadata for files
|
||||
- Each file name links to an i-node which stores security information
|
||||
|
||||
```
|
||||
@@ -135,9 +135,9 @@ Change: 2022-02-11 21:26:48.260535505 +0000
|
||||
- Every resource has permission bits - held in the i-node metadata
|
||||
- Permissions for the user / group / others
|
||||
- Octal representation
|
||||
- Bit 3: read
|
||||
- Bit 2: write
|
||||
- Bit 1: execute
|
||||
- Bit 3: read
|
||||
- Bit 2: write
|
||||
- Bit 1: execute
|
||||
- Permissions are changed using `chmod` and passing three octal values
|
||||
|
||||

|
||||
@@ -155,11 +155,10 @@ Directory permissions are slightly different to files:
|
||||
|
||||
### Linux Security Modules
|
||||
|
||||
- SInce 2.6, linux provides the ability to hook into security calls
|
||||
- Since 2.6, Linux provides the ability to hook into security calls
|
||||
- This adds the ability to perform more complex Mandatory Access Control after standard Unix DAC
|
||||
- DAC check happens irrespective of whether SM is operationa.
|
||||
- DAC check happens irrespective of whether SM is operational.
|
||||
|
||||

|
||||
|
||||
- If the security module fails, it does not matter as the discretionary access check has already run.
|
||||
|
||||
Reference in new issue
Block a user