Add the rest of university notes
This commit is contained in:
366 files changed
+9844
-110
No files matched your search
@@ -0,0 +1,165 @@
|
||||
# Unix and Linux Security
|
||||
|
||||
### Role of the OS
|
||||
|
||||
- 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
|
||||
- Access control
|
||||
- Auditing
|
||||
|
||||
#### Authentication & Authorisation
|
||||
|
||||
- Subject / Principle - an active entity
|
||||
- Object - resource being accessed
|
||||
- Access operation
|
||||
- Reference monitor - grants or denies access
|
||||
|
||||
|
||||
|
||||
**Principle**
|
||||
|
||||
> “An entity that can be granted access to objects or can make statements affecting access control decisions”
|
||||
|
||||
- e.g. user identity in an OS
|
||||
- Used when discussing security policies
|
||||
|
||||
**Subject**
|
||||
|
||||
> “An active entity within an IT system”
|
||||
|
||||
- e.g. process running under a user identity
|
||||
- Used when discussing operational systems enforcing policies
|
||||
|
||||
**Objects**
|
||||
|
||||
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
|
||||
|
||||
#### 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
|
||||
|
||||
##### Ownership
|
||||
|
||||
- Who is in charge of setting security policies
|
||||
- **Discretionary**: Owner can be defined for each resource
|
||||
- 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
|
||||
|
||||
### 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
|
||||
- Unix offers read, write and execute access controls
|
||||
|
||||
##### Groups
|
||||
|
||||
- Users with similar access rights can be collected into groups
|
||||
- Groups are given permissions to access objects
|
||||
|
||||
|
||||
|
||||
##### UID & 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
|
||||
- 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
|
||||
- `/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:
|
||||
|
||||
```
|
||||
if ((options == (_WCLONE|__WALL)) && (current->uid = 0))
|
||||
retval = -EINVAL
|
||||
```
|
||||
|
||||
Note: single `=`. This was a backdoor which sets the current uid to 0, giving root perms
|
||||
|
||||
###### Root Management
|
||||
|
||||
- Write protect `/etc/passwd` and `/etc/group`
|
||||
- Separate superuser duties (e.g. daemon, uucp)
|
||||
- Never use root as normal user
|
||||
- Audit `su` and `sudo` usage
|
||||
- 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
|
||||
|
||||
- I-nodes in unix store the metadata for files
|
||||
- Each file name links to an i-node which stores security information
|
||||
|
||||
```
|
||||
❯ stat /etc/passwd
|
||||
File: /etc/passwd
|
||||
Size: 1543 Blocks: 8 IO Block: 4096 regular file
|
||||
Device: 8,3 Inode: 27799243 Links: 1
|
||||
Access: (0644/-rw-r--r--) Uid: ( 0/ root) Gid: ( 0/ root)
|
||||
Access: 2022-02-23 20:19:14.126528209 +0000
|
||||
Modify: 2022-02-11 21:26:48.253868839 +0000
|
||||
Change: 2022-02-11 21:26:48.260535505 +0000
|
||||
Birth: 2022-02-11 21:26:48.253868839 +0000
|
||||
```
|
||||
|
||||
##### Permissions
|
||||
|
||||
- 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
|
||||
- Permissions are changed using `chmod` and passing three octal values
|
||||
|
||||
|
||||
|
||||
Directory permissions are slightly different to files:
|
||||
|
||||
- `r` - list files within the directory
|
||||
- `w` - add or remove files
|
||||
- `x` - traverse the directory, open files in the directory
|
||||
|
||||
#### SUID
|
||||
|
||||
- Set UID: set the effective user to be the file owner when executed
|
||||
- Necessary to allow non-privileged access to privileged e.g. passwords
|
||||
|
||||
### Linux Security Modules
|
||||
|
||||
- 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.
|
||||
|
||||
|
||||
|
||||
- If the security module fails, it does not matter as the discretionary access check has already run.
|
||||
|
||||
Reference in new issue
Block a user