SFL @ TU Dortmund
System Security
• System security governs process interactions with the system
Copyright By PowCoder代写 加微信 powcoder
• How do we define and confine a trusted OS kernel?
• Which objects (files, sockets, other processes, etc.) can a process access?
• How do we grant or revoke certain access privileges?
• How can we confine an attacker-controlled process to not do any harm?
Kernel vs. User
Privilege Rings (1/2)
• CPU enforces protection levels in hardware
• Intel designed four rings: ring-0 (most privileges) to ring-3 (least
privileges)
• System software runs in ring-0 (kernel land)
• Unprivileged processes run in ring-3 (user space)
• Device drivers were planned to run in ring-1 or ring-2
• Additional rings (-1, etc.) come with virtualization
3 (user) 2
• Protection levels provide a hardware- enforced separation between privileged and less privileged code
Privilege Rings (2/2)
• In practice, OSes use just two rings: 0 (kernel) and 3 (user)
• No separation for device drivers, they run in ring-0 as well
• CPU vendors offering just 2 rings forced OSes to this downgrade in security
• Restriction of ring-3 (“unprivileged”) code: • Several instructions are forbidden by CPU
• No access to other processes’ address space
• No direct I/O (files, hardware, bus, …)
• No direct access to ring-0 code and data • No direct access to physical memory •…
Memory Separation in Windows/Linux
• OSes (Win / Linux) split the 64-bit virtual memory in two halves
• Emulate 48-bit: Most significant 16 bits represent 17th most significant bit (MSB)
(this 48-bit addressing is also called canonical addressing)
• Lower half (17th MSB = 0) used for user land -> content process-specific
• Upper half (17th MSB = 1) used for kernel -> content identical for all
0x0000 0000 0000 0000
0x0000 7fff ffff ffff
0xffff 8000 0000 0000
0xffff ffff ffff ffff
(unused virtual
address range)
System Calls (1/2)
• User processes cannot directly access kernel land
• System calls provide the interface between user and kernel land
• System calls at a glance:
1. Unprivileged process invokes one
of the predefined system calls
2. System call traps to OS, i.e., CPU elevates privileges of the process and runs the system call handler
3. System call handler performs operations as requested by process and returns to the user (i.e., CPU downgrades privileges)
0x0000 0000 0000 0000
kernel (ring 0)
0x0000 7fff ffff ffff
0xffff 8000 0000 0000
syscall handle
0xffff ffff ffff ffff
System Calls (2/2)
• Example: System call table of x64 Linux
Syscall Number (%rax)
rt_sigprocmask
Entry point
sys_newstat
sys_rt_sigaction
sys_rt_sigprocmask
Implementation
fs/read_write.c
fs/read_write.c
sys_newfstat
sys_newlstat
fs/select.c
fs/read_write.c
arch/x86/kernel/sys_ x86_64.c
sys_mprotect
sys_munmap
mm/mprotect.c
rt_sigaction
kernel/signal.c
rt_sigreturn
stub_rt_sigreturn
kernel/signal.c
arch/x86/kernel/sign al.c
fs/ioctl.c
Virtual Memory of a User-Land Process
• Process memory is organized in using stack and heap • Stack for per-function variables (grows to lower addresses) • Heap for dynamically allocated memory
Stack: last in first out
0x0000 7FFF…FF
Other sections
(e.g.: .data)
Virtual Address Space
Stack designed for:
• Function parameters • Local variables
• Function return addr. • Temporary variables Stack grows downward.
Heap stores dynamically- allocated data items:
• malloc() etc. allocate
• free() etc. release
0x0000 0000…00
Resource Permissions
Protection Domains (1/3)
• OS maintains access to several resources (files, devices, pages, etc.)
• So far we discussed coarse-grained separation between user and kernel
• How about isolation between different users and their processes? • Protection domains
• Set of (object, rights) pairs, where rights is a (sub)set of operations a subject (e.g., user) is allowed to perform on an object (file, device, etc.)
• Users/processes are assigned to a protection domain
• Protection domains govern access privileges
Protection Domains (2/3)
Domain 1 Domain 2
rx r rw r rw
rw rw FFFFFFF 1231456
Protection Domains (3/3)
• Protection domains can be represented in a protection matrix ACL
• Protection matrices are usually sparse
• T wo main principles to store this matrix efficiently
• By column: Per object, i.e., store domains’ privileges (Access Control Lists)
• By row: Per domain, i.e., store access rights to objects (Capabilities)
File 2 File 3 File 4 File 5 File 6
Domain 3 r rw
Example: File Permissions in UNIX (1/2)
• UNIX enforces minimal access control lists (ACLs) for files
• Files belong to an owner and a group
• All types of UNIX files are maintained as inodes
• An inode is a control structure that contains file meta information • File directories are structured in a hierarchical tree (also as inodes)
• Each file has protection bits
• 9 bits to specify RWX (read, write, execute) rights to owner, group
and others
• SetUID and SetGID bits to execute a file in the owner’s user/group
• Sticky bit: if set for a directory, only owner can del/alter/rename files in dir.
Example: File Permissions in UNIX (2/2)
• Privileges are too coarse-grained in many examples • Groups can help to better organize file accesses
• However, a file can only belong to one group
• Extended ACLs can grant permissions to arbitrary number of domains
• Grant privileges with setfacl()
• Complementary to and checked in addition to minimalistic ACLs
• OS iterates over extended permissions and checks if at least one (either user or group-based rule) grants access permission
UNIX: SUID Programs
• SUID Bit allow a user to start a process with higher rights than his own
• Every process has a real and effective User / Group ID (usually equal)
• Real IDs: Given by the user -> Login as user „XYZ“
• Effective IDs: Represents the rights of a process -> Set with the
System Call setuid()
• suid / sgid: Bits to start a process with another effective ID as the
• -> Attractive target!
UNIX: TOCTOU
•Time-of-Check, Time-of-Use Attack
• Time-of-Check : Validity of assumption A on Entity E was
• Race Condition between access to entities
• Time-of-Use : Assumption A is still valid, E is used
• Time-of-Attack : Assumption A is not valid anymore
< <
UNIX: TOCTOU
• Steps to access a resource
1.Check access rights for a file with access()
2.Open file with fopen()
3.Four levels of indirection (symbolic link – hard link – inode – file descriptor)
• Windows does not suffer from that problem • Windows uses secure File Handles
- The Windows API checks open() for the probable race- conditions
Discretionary vs. Mandatory Access Control
• Discretionary AC allows owners to change their resources’ privileges
• Mandatory AC enforces that only administrators can change policies
• DAC policies are thus maintained by resource owners, whereas MAC policies can only be changed by administrators
• Examples:
• Facebook allows users to select with whom to share images (DAC)
• Linux users can specify which other users can access their files (DAC)
• Administrator-configured SELinux policies govern system privileges per program (MAC)
• A bank’s administrator governs which clerk may see which customer account, but the clerks have no way to delegate their privileges to others (MAC)
Bell-LaPadula Model
可以保证机密性(secrecy)
• Multilevel security model historically from military
• Objects (e.g., documents) and subjects (e.g., people) have a security
• Higher level means higher trust and higher responsibility
• Bell-LaPadula prevents information leaks from higher to lower security levels
• Bell-LaPadula follows two security policies
• Simple security property (no read up)
Process running at level can read only subjects with level . Intuition: Prevent that low-level subjects can steal sensitive information.
• The * property (no write down)
Process running at level can write only objects that have level
Intuition: Prevent that high-level subjects leak sensitive information.
Biba Model
可以保证完整性(integrity)
• Bell-LaPadula was designed to keep secrets, not to guarantee
• Biba model aims for integrity instead of secrecy
• Biba thus follows two security policies orthogonal to Bell- LaPadula
• Simple integrity property (no write up)
Process running at level can write only to subjects with level Intuition: Prevent that low-level subjects can modify sensitive information.
• The integrity * property (no read down)
Process running at level can read only objects that have level Intuition: Prevent that high-level subjects read information lacking integrity.
• If a system rigorously enforces Biba policies, all information that is stored at current (or higher) level has strong integrity guarantees
• But: Bell-LaPadula and Biba policies are in direct conflict
Confinement Problem
• Confinement problem
• Problem of preventing a confined process from leaking information
that the user of this process considers confidential
• Example:
• Consider a server S that the client C has to use, but C does not trust S
• Yet C has to disclose sensitive information to S
• S isolates itself to convince C that it does not leak C’s sensitive information
• S guarantees to neither store (e.g., on disk), nor to communicate (e.g., over network) the information that C considers sensitive
Confinement Problem (BLACKBOARD)
• Covert channel
• Path of communication that was not designed to be used for
communication
• Can be used between a confined and a collaborating process
• Covert channels exist mostly as resources are shared between processes
• Covert channels undermine the security of provably secure systems (such as the Bell-LaPadula system)
• Example #1: Covert channel via file locking
• Assumption: Confined process and collaborator share the same file
• For each agreed-upon time frame, the server: - sends bit 1 by locking a specific file, or
- sends bit 0 by unlocking this file
• The client checks if file is locked to determine the covert bit
• Example #2: Covert channel via CPU modulation
• Assumption: Confined process and collaborator share the same CPU(s)
• For each agreed-upon time frame, the server: - sends bit 1 by heavily utilizing the CPU(s), or
- sends bit 0 by not utilizing the CPU
• The client observes low or high CPU utilization and determines the covert bit
Process Isolation / Confinement
Process Isolation
• Process isolation aims to isolate individual processes only
• Protects a process from access from other processes
• Confines a process even if it misbehaves (e.g., after exploitation)
Process Isolation
• If single user has multiple processes, process isolation differs per OS:
• Linux: processes within same domain can see/stop each other, but reading memory is only possible via workarounds (e.g., via ptrace)
• Windows: processes within same domain can read from and write to each other’s memory (e.g., using the Read-/WriteProcessMemory()
• Users/groups act as access boundary for processes
• Users cannot interact (stop, read from, write to) with each others’ processes
• Android uses this by default: each app (process) has its own user (domain)
Fine-Grained Isolation
• Several more fine-grained process isolation frameworks exist
• chroot: move process to its own file system
• seccomp: move process into secure world with limited system calls
• SELinux: MAC policies for finegrained process privileges
• Kernel namespaces: Allows to restrict access to mount points, network interfaces, other processes, and many more
• Integrity levels: assign process pre-defined set of permissions
• Tokens: fine-grained DAC policies for objects that need further protection
• Job objects: additional, more general filtering rules for process capabilities
Linux: chroot
• Change the apparent root directory of a process (and its children)
• Process is stuck in its new root directory and cannot access resources
• Primarily invented for virtualization, but nowadays sometimes used for security
• Requires subset of system files to be copied to chroot environment (as the chroot’ed process expects them at the usual location)
• chroot is not considered a strong security feature, though
• Pending file descriptors (opened before chroot) leak handles to entire
file system
• Opened files that are later moved out of the chroot environment allow an attacker to escape the confined environment
• Ineffective against root users, which can escape chroot anyway
Linux: seccomp
• Normally, processes can perform any (unprivileged) system call
• Usually, the set of intended system calls is way smaller than all system
• Limiting programs to a few system calls reduces attack surface after exploitation
• seccomp can limit the set of system calls a process can perform • Default seccomp: limit to exit(), sigreturn(), read() and write() • seccomp-BPF: configurable policy of allowed system calls
• seccomp is very popular in the Linux world • docker
• OpenSSH • QEMU
• Firefox •...
Linux: SELinux
• SELinux adds MAC to Linux
• SELinux user space tools allow to maintain policies (only root)
• SELinux enforces these rules in kernel by intercepting system calls
• Several OSes ship SELinux rules
• Per-program rules are required
• Actions violating the rules are denied and logged
Example SELinux policy for PostgreSQL (incomplete)
# allow to create new log files in PostgreSQL log directory
allow postgresql_t postgresql_log_t : dir { add_name } ;
# allow to bind TCP socket on PostgreSQL port
allow postgresql_t postgresql_port_t : tcp_socket { name_bind } ;
Linux: Kernel Namespaces
• Namespaces limit the view of a process to the rest of the system
• Allows to create new containers for a process that seem to be a new
• Heavily used for lightweight container software (such as docker)
• Several namespaces exist in Linux
• pid: Give each process its own restricted view on processes
• net: Give each process its own network configuration (interfaces, addresses, etc.)
• mnt: Give each process its own view on the file system
• user: Give each process its own view on system users •...
Windows: Integrity Levels
• Per-process integrity levels allow to override a user’s privileges
• Five levels: untrusted (0) to system (4)
• Default level is medium (2), administrative applications have high (3) level
• Untrusted (0) and low (1) integrity processes have almost no read/write access
• Integrity levels enforce object policies
• No-Write-Up: Low-integrity processes cannot modify higher-integrity
• No-Read-Up: Low-integrity processes cannot read more sensitive objects
Windows: Access Tokens
• Windows processes have access token that determines the privileges
• Token identifies the security context of a process (account, group, privileges, etc.)
• Child processes inherit privileges from their parent
• Token can be restricted, i.e., subset of privileges can be removed
• Privileges grant access to securable objects, such as... • files and directories,
• named and anonymous pipes,
• processes and threads,
• registry keys, • etc.
• ... that have a security descriptor (using DAC)
• Tokens cannot restrict system calls
Further Reading
• Tanenbaum / Bos: Modern Operating Systems (see CMS) • Chapter 7: Virtualization (optional, except 7.2 and 7.3)
• Chapter 9.3: Controlling Access to Resources
• Chapter 9.4: Formal Models of Secure Systems
• (optional) Chrome Sandbox: An illustrative example of Windows security mechanisms put in practice (optional)
• https://chromium.googlesource.com/chromium/src/+/master/docs/design/sandbox.md#Sandbox-windows- architecture
程序代写 CS代考 加微信: powcoder QQ: 1823890830 Email: powcoder@163.com