OS Notes

Access Control - Permission Models

Access control in OS — access control lists (ACLs), capability lists, Unix permission model, Windows NTFS permissions, POSIX ACLs, and implementing fine-grained access policies.

Introduction

Access control is the mechanism by which the operating system decides whether to permit or deny a specific operation by a specific subject on a specific object. Every time you open a file, connect to a network port, or execute a program, the OS performs an access control check — usually in microseconds, invisible to you but fundamentally critical to system security.

Without access control, any user could read anyone else's files, any process could overwrite system binaries, and any network connection could access any service. Access control transforms a shared computer from chaos into a structured, secure environment.

The Access Control Decision

Every access control check involves three components:

Subject: The entity requesting access (user, process, thread)
Object: The resource being accessed (file, device, network socket, memory region)
Operation: What the subject wants to do (read, write, execute, delete, append)

The access control system evaluates: "Should subject S be allowed to perform operation O on object R?"

Access Control Lists (ACLs)

An ACL is attached to each object, listing which subjects can perform which operations.

File	/documents/report.pdf
alice	read, write
bob	read
group_managers	read, write
others	(no access)

Unix Basic Permissions (Simplified ACL)

Unix uses a simplified three-entry ACL for every file:

Example

-rwxr-x--- 1 alice managers 4096 Jun 10 09:00 report.pdf ||| ||| ||| ||| ||| └── Others: no permissions ||| └───── Group (managers): read + execute └──────── Owner (alice): read + write + execute

Three permission types:

r (read): View file contents / list directory contents
w (write): Modify file / create-delete files in directory
x (execute): Run as program / traverse (cd into) directory

Setting permissions:

bash example

# Numeric notation (octal)
chmod 750 script.sh    # rwxr-x--- (owner=7, group=5, other=0)
# 7 = 4+2+1 = read+write+execute
# 5 = 4+0+1 = read+execute
# 0 = no permissions

# Symbolic notation
chmod u+x script.sh    # Add execute for owner
chmod g-w file.txt     # Remove write from group
chmod o=r file.txt     # Set others to read-only

POSIX Extended ACLs

When three entries are not enough (you need per-user permissions beyond owner/group/other):

bash example

# Grant bob read access specifically
setfacl -m u:bob:r-- confidential.doc

# Grant the 'auditors' group read+execute
setfacl -m g:auditors:r-x /var/log/secure/

# View complete ACL
getfacl confidential.doc
# Output:
# file: confidential.doc
# owner: alice
# group: staff
# user::rw-
# user:bob:r--
# group::r--
# group:auditors:r-x
# mask::r-x
# other::---

# Set default ACL for new files in directory
setfacl -d -m g:team:rw /shared/projects/

The mask entry limits the maximum permissions for named users and groups (effective permissions = entry AND mask).

Windows NTFS Permissions

Windows uses a more complex ACL system with fine-grained permissions:

File	C:\Reports\quarterly.xlsx
ALLOW Alice	Full Control
ALLOW Managers Group	Read, Write
ALLOW Everyone	Read
DENY Intern_Group	Write

Key NTFS concepts:

Explicit permissions vs Inherited permissions (from parent folder)
Allow vs Deny entries (Deny always wins over Allow)
Permission inheritance: Child objects inherit parent's ACL by default
Granular rights: Read attributes, Write attributes, Delete, Change permissions, Take ownership

Capability Lists

The alternative to ACLs — instead of attaching permissions to objects, attach them to subjects:

capability_1	{object: /documents/report.pdf, rights: read, write}
capability_2	{object: printer_1, rights: print}
capability_3	{object: /shared/data/, rights: read}

A capability is an unforgeable token that grants specific access. If you possess the capability, you have the access — no further lookup needed.

ACL approach: "Who can access this file?" (check the file's list) Capability approach: "What can this user access?" (check the user's tokens)

Feature	ACL	Capability
Revocation	Easy (modify file's list)	Hard (find and invalidate all copies)
Discovery	Easy ("who has access?")	Hard (check every user's list)
Delegation	Hard	Easy (pass capability to another)
Least privilege	Requires explicit restriction	Natural (only have capabilities you were given)
Confused deputy	Vulnerable	Prevented

The Confused Deputy Problem

A classic security issue that capabilities solve:

Imagine a compiler that writes output to a user-specified file. With ACL-based access, the compiler runs with its own permissions. A malicious user tells the compiler to write to /etc/passwd — the compiler has write access to system files (it needs to write to output directories), so the operation succeeds. The compiler acted as a "confused deputy" — it used its own authority on behalf of the user's request.

With capabilities, the user must provide a capability for the output file. The user does not have a capability for /etc/passwd, so they cannot provide one to the compiler. Problem solved.

Access Control in Practice

Linux: DAC + Optional MAC

bash example

# Standard DAC (discretionary)
chmod 640 /etc/myapp/config.ini
chown myapp:myapp /etc/myapp/config.ini

# Optional MAC (mandatory) with SELinux
# Even if DAC allows access, SELinux can still deny
chcon -t httpd_config_t /etc/myapp/config.ini
# Now only processes with httpd_t domain can read it

Role-Based Access Control in Databases

sql example

-- Create roles
CREATE ROLE analyst;
CREATE ROLE admin;

-- Assign permissions to roles
GRANT SELECT ON sales_data TO analyst;
GRANT ALL PRIVILEGES ON ALL TABLES TO admin;

-- Assign users to roles
GRANT analyst TO bob;
GRANT admin TO alice;

Access Control Implementation Considerations

Default deny: If no rule grants access, deny by default (fail-safe)
Deny overrides allow: When conflicts exist, deny rules take precedence
Minimize permissions: Follow principle of least privilege
Regular auditing: Review who has access and revoke unnecessary permissions
Separation of duties: Require multiple people for critical operations
Time-based access: Some permissions valid only during business hours

Key Takeaways

Access control enforces who can do what to which resource
ACLs (attached to objects) are standard in Unix and Windows file systems
Capabilities (held by subjects) provide natural least privilege but harder revocation
Unix permissions (rwx for owner/group/other) are a simplified three-entry ACL
POSIX ACLs extend Unix permissions for fine-grained per-user access
Windows NTFS provides richer ACLs with inheritance and explicit deny entries
Modern systems layer DAC + MAC + RBAC for comprehensive protection

Exam Focus

Revise definitions, diagrams, examples, and short-answer points for Access Control - Permission Models.

Interview Use

Prepare one clear explanation, one practical example, and one common mistake for this Operating Systems topic.

Search Terms

operating-systems, operating systems, operating, systems, security, and, protection, access

Continue learning this concept

Security And ProtectionAuthentication - User VerificationAuthentication in Operating Systems — methods of user identity verification including passwords, biometrics, multi-factor authentication, Kerberos protocol, and challenge-response mechanisms.Security And ProtectionAuthorization - Access ControlAuthorization in Operating Systems — determining what authenticated users can do, access control models (DAC, MAC, RBAC), access control matrices, capability lists, and the principle of least privilege.Security And ProtectionMalware and Threats - Security ThreatsOperating system security threats — types of malware (viruses, worms, trojans, ransomware, rootkits), attack vectors, exploitation techniques, and how operating systems defend against threats.Security And ProtectionOS Security Basics - Threats and ControlsOperating system security fundamentals — security goals (CIA triad), threat categories, security mechanisms, protection rings, trusted computing base, and the principles of secure OS design.Security And ProtectionProtection Mechanisms - Security ImplementationOS protection mechanisms — protection domains, rings, access matrix implementation, hardware protection (memory, CPU, I/O), capability-based systems, and sandboxing techniques.Security And ProtectionSecurity Best Practices - OS HardeningOperating system security best practices — system hardening techniques, patch management, network security, audit logging, backup strategies, and building defense-in-depth architectures.

PreviousShell Scripting Projects NextAuthentication - User Verification

OS Notes

Access Control - Permission Models

Access control in OS — access control lists (ACLs), capability lists, Unix permission model, Windows NTFS permissions, POSIX ACLs, and implementing fine-grained access policies.

Introduction

The Access Control Decision

Every access control check involves three components:

Subject: The entity requesting access (user, process, thread)
Object: The resource being accessed (file, device, network socket, memory region)
Operation: What the subject wants to do (read, write, execute, delete, append)

The access control system evaluates: "Should subject S be allowed to perform operation O on object R?"

Access Control Lists (ACLs)

An ACL is attached to each object, listing which subjects can perform which operations.

File	/documents/report.pdf
alice	read, write
bob	read
group_managers	read, write
others	(no access)

Unix Basic Permissions (Simplified ACL)

Unix uses a simplified three-entry ACL for every file:

Example

Three permission types:

r (read): View file contents / list directory contents
w (write): Modify file / create-delete files in directory
x (execute): Run as program / traverse (cd into) directory

Setting permissions:

bash example

# Numeric notation (octal)
chmod 750 script.sh    # rwxr-x--- (owner=7, group=5, other=0)
# 7 = 4+2+1 = read+write+execute
# 5 = 4+0+1 = read+execute
# 0 = no permissions

# Symbolic notation
chmod u+x script.sh    # Add execute for owner
chmod g-w file.txt     # Remove write from group
chmod o=r file.txt     # Set others to read-only

POSIX Extended ACLs

When three entries are not enough (you need per-user permissions beyond owner/group/other):

bash example

# Grant bob read access specifically
setfacl -m u:bob:r-- confidential.doc

# Grant the 'auditors' group read+execute
setfacl -m g:auditors:r-x /var/log/secure/

# View complete ACL
getfacl confidential.doc
# Output:
# file: confidential.doc
# owner: alice
# group: staff
# user::rw-
# user:bob:r--
# group::r--
# group:auditors:r-x
# mask::r-x
# other::---

# Set default ACL for new files in directory
setfacl -d -m g:team:rw /shared/projects/

The mask entry limits the maximum permissions for named users and groups (effective permissions = entry AND mask).

Windows NTFS Permissions

Windows uses a more complex ACL system with fine-grained permissions:

File	C:\Reports\quarterly.xlsx
ALLOW Alice	Full Control
ALLOW Managers Group	Read, Write
ALLOW Everyone	Read
DENY Intern_Group	Write

Key NTFS concepts:

Explicit permissions vs Inherited permissions (from parent folder)
Allow vs Deny entries (Deny always wins over Allow)
Permission inheritance: Child objects inherit parent's ACL by default
Granular rights: Read attributes, Write attributes, Delete, Change permissions, Take ownership

Capability Lists

The alternative to ACLs — instead of attaching permissions to objects, attach them to subjects:

capability_1	{object: /documents/report.pdf, rights: read, write}
capability_2	{object: printer_1, rights: print}
capability_3	{object: /shared/data/, rights: read}

A capability is an unforgeable token that grants specific access. If you possess the capability, you have the access — no further lookup needed.

ACL approach: "Who can access this file?" (check the file's list) Capability approach: "What can this user access?" (check the user's tokens)

Feature	ACL	Capability
Revocation	Easy (modify file's list)	Hard (find and invalidate all copies)
Discovery	Easy ("who has access?")	Hard (check every user's list)
Delegation	Hard	Easy (pass capability to another)
Least privilege	Requires explicit restriction	Natural (only have capabilities you were given)
Confused deputy	Vulnerable	Prevented

The Confused Deputy Problem

A classic security issue that capabilities solve:

With capabilities, the user must provide a capability for the output file. The user does not have a capability for /etc/passwd, so they cannot provide one to the compiler. Problem solved.

Access Control in Practice

Linux: DAC + Optional MAC

bash example

# Standard DAC (discretionary)
chmod 640 /etc/myapp/config.ini
chown myapp:myapp /etc/myapp/config.ini

# Optional MAC (mandatory) with SELinux
# Even if DAC allows access, SELinux can still deny
chcon -t httpd_config_t /etc/myapp/config.ini
# Now only processes with httpd_t domain can read it

Role-Based Access Control in Databases

sql example

-- Create roles
CREATE ROLE analyst;
CREATE ROLE admin;

-- Assign permissions to roles
GRANT SELECT ON sales_data TO analyst;
GRANT ALL PRIVILEGES ON ALL TABLES TO admin;

-- Assign users to roles
GRANT analyst TO bob;
GRANT admin TO alice;

Access Control Implementation Considerations

Default deny: If no rule grants access, deny by default (fail-safe)
Deny overrides allow: When conflicts exist, deny rules take precedence
Minimize permissions: Follow principle of least privilege
Regular auditing: Review who has access and revoke unnecessary permissions
Separation of duties: Require multiple people for critical operations
Time-based access: Some permissions valid only during business hours

Key Takeaways

Access control enforces who can do what to which resource
ACLs (attached to objects) are standard in Unix and Windows file systems
Capabilities (held by subjects) provide natural least privilege but harder revocation
Unix permissions (rwx for owner/group/other) are a simplified three-entry ACL
POSIX ACLs extend Unix permissions for fine-grained per-user access
Windows NTFS provides richer ACLs with inheritance and explicit deny entries
Modern systems layer DAC + MAC + RBAC for comprehensive protection

Exam Focus

Revise definitions, diagrams, examples, and short-answer points for Access Control - Permission Models.

Interview Use

Prepare one clear explanation, one practical example, and one common mistake for this Operating Systems topic.

Search Terms

operating-systems, operating systems, operating, systems, security, and, protection, access

Continue learning this concept

PreviousShell Scripting Projects NextAuthentication - User Verification