165 lines
4.9 KiB
Markdown
165 lines
4.9 KiB
Markdown
# 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 / Principal - an active entity
|
||
- Object - resource being accessed
|
||
- Access operation
|
||
- Reference monitor - grants or denies access
|
||
|
||
|
||
|
||
**Principal**
|
||
|
||
> “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 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
|
||
- 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 in 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 has an 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 operational.
|
||
|
||
|
||
|
||
- If the security module fails, it does not matter as the discretionary access check has already run.
|