This commit is contained in:
John Gatward committed 2026-10-04 15:24:17 +01:00
1 parent d0f27f276b
commit d6f54d4ec2
103 files changed
+3663 -3779

No files matched your search

+34 -35
View File
@@ -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
![1645720842.png](img/1645720842.png)
![1645720842.png](img/1645720842.png)
**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
![1645722860.png](img/1645722860.png)
@@ -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.
![1645723378.png](img/1645723378.png)
- If the security module fails, it does not matter as the discretionary access check has already run.