notes/docs/lectures/security/07_unix_security.md

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.