Summary Operating System Security PDF

Summary Operating System Security Marie Simon s1023848 January 10, 2020 1 Authentication The process of proving that enitity X is indeed X OS manages access of processes to resources...

Summary Operating System Security Marie Simon s1023848 January 10, 2020 1 Authentication The process of proving that enitity X is indeed X OS manages access of processes to resources For that the OS needs to know who someone is and whether someone or something is, in fact, who or what it declares itself to be → Authentication – Typically perform a user authentication as login procedure – Start a shell mapped to the logged-in user – Shell is (basically) an interface to run other programs – All programs run from this shell are mapped to the logged-in user Worst case authentication failure: impersonation Authentication is possible by: What you know (passwords, challenge-response) – But typically people are bad at finding strong passwords (123456, 123456789, qwerty What you are (biometrics like fingerprints, retina scan, voice match...) – fake fingerprints – Voice may be distorted by cold, recordings could be used – Handwriting has low accuracy, can easily be fakes What you have (tokens, smartcard) – Need to protect possession stealing or finding from other people – copying needs to be avoided by tamper-proof hardware, anti-counterfeiting techniques – replay-attacks could be possible (device-dependent, use challenge-response) Multifactor authentication (any combination of the above mentioned) 1.1 Unix users Three types of accounts root account - superuser – User ID is always 0 – root processes perform system boot, user authentication, administration, network service etc. – root may access change permissions on all files – root may ”impersonate” any other user A process belonging to root may change its user ID to that of another user Once a process changed from ID 0 to another ID, there is no way back 1  – Security nighmare when attacker gets root access system accounts - needed for specific functions of the system user accounts - provide interactive access to the system Important files: /etc/passwd - User’s account information /etc/shadow - User’s password information including hashes of the passwords /etc/group, /etc/gshadow for groups of users 1.1.1 Classical Unix authentication Authentication by what you know Init process starts login (runs as root) Correct password: login changes to new user and executes a shell Comparison of password hash against info stored in file originally in /etc/passwd now in /etct/shadow 1.2 Authentication over the network Large corporate networks want to keep user information central User is added to one central directory, can log into any machine Various ”simple” ways to set up a protocol Client sends password, server hashes and compares Client sends hash, server compares Server sends hash, client compares Also more complex options e.g. challenge-response Disadvantage of central login server could be the single point of failure Different common protocols (NIS, LDAP, Kerberos) NTLM authentication protocol A challenge-response protocol 1. Server sends Challenge C 2  2. User calculates three keys K1|K2|K3 from the hash of his password 3. User sends a response with those keys and the challenge Problem: Response only depends on the password hash, not the password. Attacker only needs to obtain the hash, so the whole point of storing password hashes is gone since the hash becomes essentially the password Attack is known ash ”pass the hash” Automated by metasploit Kerberos is the protocol of choice but NTLM is still supported, almost any larger Windows network has NTLM somewhere 1.3 Pluggable authentication modules (PAM) Local login is not the only program that needs user authentication SSH (remote login) Graphical login (GDM, LightDM) Screen locks (screensaver) su and sudo Historically every program needs to manage that independently Idea now: Centralize authentication, make functionality available through library → PAM (developed 1995) Example usage: Control login attempts to shell, so that only successful authentication and authorized events are allowed Control who can use su to switch identities or passwd to change passwords Add a new module (e.g fingerprint authentication) → directly available to all PAM enabled programs PAM activities auth The activity of user authentication, typically by passwords, but can also use tokens, fingerprints etc account After a user is identified, decide whether he is allowed to log in. For example, can restrict login times session Now that the host is ready to allow entrance, it allocates resources, for example mount home directory, set resource usage limits, cpu, memory, shell, print greeting message password Update the user’s credentials (typically password) 3 PAM control flags requisite if module fails, immediately return failure and stop required if module fails, continue, but return failure in the end sufficient if module passes, return pass and stop (any remaining PAM modules in the stack are terminated) optional pass/fail result is ignored (not for authentication tasks, for tasks like spanning a shell and loading it wiht environmental variables) 2 Authorization The process of deciding if enitity X is allowed to have access to resource Y 2.1 Protection rings OS needs to control access to resources Idea: Access to resources is only given for highly-privileged code Non-privileged code needs to ask the OS to perform operations on resources Separate code in protection rings Hardware-enforced by CPU architectures Hierarchy from most to least privileged Ring 0 is level with most privileges and interacts most directly with the physical hardware (CPU and memory) Certain instructions can only be executed by ring-0 code Trying to execute a ring 0 instruction from ring 3 results in SIGILL (illegal instruction) 4 Linux (and Windows) use a simpler supervisor-mode model: Operating system runs wiht supervisor flag enabled (ring 0 → kernel space) User programs run wiht supervisor flag disabled (ring 3 → user space) 2.2 System Calls If processes start in ring 3, how do they execute ring 0 code (e.g I/O operations, file system manipulation...) Transition from user space to kernel space happens through a well defined interface, a set of system call (syscalls) A system call is a request from user space to the OS to perform a certain operation Access to system calls is typically implemented through the standard library Examples: Process control create or terminate process, load, execute, wait, signal event, allocate and free memory... File management create, delete, open, close, read, write, get/set file attributes Device management request or release device, read, write, get/set device attributes,... Information maintenance get/set time or date, system data, device attributes,... Communication create, delete, communication connections, send, receive messages, transfer status information, attach or detach remote devices,... Protection get/set file permissions,... 2.2.1 Trusted Code Base (TCB) Trustes computing base of Linux is all code running in kernel space and several processes running with root permissions (e.g initprocess,login(user authentication), network services) User processes need to be protected from each other and the TCB from all user processes Malicious application should not be able to compromise confidentiality, integrity or availability of another application If flaws in kernel, exploits can violate this isolation TCB size should be as small as possible to avoid vulnerabilities → debate over monolithic vs microkernel OS (microkernel is smaller TCB) 2.2.2 Loadable Kernel Modules Usually after modifying the OS kernel you need to reboot, loadable kernel modules make it possible for some operations to modify the OS kernel at runtime Ideal for device drivers (kernel can communicate with hardware without knowing how it works) Loaded at runtime Run in kernel space (ring 0) Modules are stored in /usr/lin/modules/kernel_release_ A kernel module is not an application – do not execute sequentially – do not have automatic cleanup – do not have printf() functions (cannot access user space code) – can be interrupted (can be used by several processes at the same time) 5  – have a higher level of execution privilege – do not have floating-point support Modules loading is handled automatically by udev modules-load.d - Configure kernel modules to load at boot Load module into kernel manually with program insmod (if module not in /usr/lib/modules/kernel_release_) 2.3 File system in Unix Persistent data on background storage is organized in files Files are logical units of information organized by a file system Files have names and additional associated information Date and time of last access Date and time of last modification Access-permission-related information Files are logically organized in a tree hierarchy of directories The file system maps logical information to bits and bytes on the storage device The file system runs in kernel space Abstraction as Virtual file system (Everything is a file) Access to files goes through system calls Everything is a file is a fundamental Unix abstraction Everything gets represented by a file descriptor abstracted over the virtual file system layer in the kernel /dev/FySO - device as a file /proc/123 - process as a file 6  As a consequence: – Same set of Linux tools, utilities and APIs can be used on all input/output resources – User-space processes can operate on files only through syscalls – OS can check for each syscall (kernel-space operation), whether the operation is permitted 2.3.1 File descriptors A file descriptor (or handle) is and index (integer) into a file descriptor table stored by the kernel Mapping is established per process The kernel creates a file descriptor in response to an open call and associates the file descriptor with some resource (hardware device, file system etc) As a result a process’s read or write calls that reference that file descriptor are routed to the correct place place by the kernel Possibility for leaks: When a new process is forked or executed, the child process inherits any open file descriptors → if sensitive descriptors are not closed before invoking a child with less privileges, the child might perform unauthorized I/O operations on those descriptors Special file descriptors: Int Name stdio.h file stream 0 Standard input stdin 1 Standard output stdout 2 Standard error stderr File related syscalls: open() Open a file and return file handler read() Read a number of bytes from a file handle into a buffer write() Write a number of bytes from a buffer to the file handle close() Close the file handle lseek() Change position in the file handle access() Check access rights based on real user ID 2.4 Access Control Access Control (AC) is the selective restriction of access to a place or other resource An access enforcement mechanism authorizes requests from mutliple subjects (e.g users, processes, etc) to perform operations (e.g read, write etc) on objects (e.g files, sockets, etc). An oeprating system provides an access enforcement mechanism. Two fundamental concepts of access control: A protection system that defines the access control specification A reference monitor that is the system’s access enforcement mechanism that enforces this specification Protection System A protection system consists of a protection state, which describes what operations subjects (processes) may perform on objects (files) together with a set of protection state operations that enable modi- fication of the state Mandatory Access Control A system implemetns mandatory access control (MAC) if the protection state can only be modified by trusted administrators via trusted software Discretionary Access Control A system implements discretionary access control (DAC) if the protection state can be modified by untrusted users. The protection of a user’s files is then ”at the discretion of the user” 7 2.4.1 Access Control Matrix File 1 File 2 File 3 File 4 Process 1 read read read, write Process 2 read Process 3 read, write read a way to represent access control policy When a user creates a file, a column is added to the table Adding a column means modifying the protection state The access-matrix model is inherently a DAC system 2.5 Access control lists User/group/all model is not always flexible enough, want to enable arbitrary access permissions → Access Control Lists (ACLs) Grant permissions to arbitrary users and groups Needs support from file system Mount file system with option acl 2.6 Permission model: subjects Every user has: user ID (uid) - login name group ID (gid) - login group groups list - file groups you can access The groups of all users are defined in /etc/group Each user has a primary group defined in /etc/passwd When you are logged in, you can see your groups with the command groups Each process has associated three user IDs Real user ID - the owner of the process Effective user ID - the uid used by the OS to make access control decisions Saved user ID - stores previous uid so it can be restored later Each process also has associated a set of group IDs 2.7 Protection model: objects Each object (file) has: and owner (user) and owner permissions a group and a group permission other permissions Permissions on a file are read (r) write (w) execute (x) 8  Directory permissions read Can see content (files and subdirectories) write Can rename and delete content of the directory and create new content execute can traverse the directory (cd into or across the directory) Typically written in 9 bits: 2.8 Protection model: matching When a process wants to access a file, check the following 1. Does the effective user ID of the process match the file’s owner? If so, use owner’s permission 2. Does one of the group IDs of the process match the group of the file? If so, use the group permissions 3. Otherwise use the ”other” permissions If owner matches, the group permissions do not matter If group matches, the other permissions do not matter Important: A user can have execute access without having read access If a user has read access but not execute access, they can still copy the file, assign execution permissions to it and run it (but not as original owner). The copy: will have a different absolute pathname will be owned by this user, not the origianl program’s owner will not have suid bit set 2.8.1 chmod Change the permissions of files or directories if you are the owner Octal mode: first digit either 4 (set user ID), 2 (set group ID) or 1 (restricted deletion or sticky attributes) Other three digits refer to combinations of rwx Example: In symbolic mode: [ugoa] control which users’ access is changed [+-=] control whether added, removed or set [rwxXs,t] select permissions chmod u-w example.txt removes writing permission from user 2.8.2 chown changes ownership of files and directories Only root can change the owner of a file, the owner cannot transfer ownership unless he is root or uses sudo Owning group of a file can be changed by the file’s owner, if the owner belongs to that group. Root can change it to any group 9 2.9 setuid Sometimes users need to have access to privileged resources Linux solution: addition setuid (suid) bit (short for set user ID upon execution) in file permissions Run program with permission of owner instead of user starting it Set suid bit with chmod u+s or chmod 4755 User IDs of a suid program: Real uid: ID of user starting the program Effective uid: ID of the owner Saved uid: set to effective user ID Most important application: setuid root - the program then executes as if it is owned by root, all access to system resources Setuid root process can drop privileges (effective ID) Can regain root rights as long as saved ID is still 0 Examples of setuid programs su Without argument become root, or the argument is the user it switches to. Authentication uses PAM login uses setuid privilege to change uid to that of the successfully authenticated user passwd needs write access to /etc/shadow ping needs access to raw network sockets and send broadcasts For all, authenticate against PAM before doing anything Propagation of UID fork() creates new process, child inherits three UIDs from parent exec() process executes a program (that completely replaces the process), UIDs do not get changed unless program is setuid 2.10 Privilege escalation Attack that expands attacker’s privileged Two kinds: Horizontal: obtain privileges of another un-privileged user Vertical: obtain privileges of root (or kernel) ”privilege elevation” Typically enabled by bugs in privileged software An exploit that lets an unprivileged (logged in, local) user gain root rights is called local root exploit 3 Memory All access to resources was handled by file-access permissions through syscalls → expensive Cannot do that for reading/writing memory Load/store instructions are frequent in programs Speed of many programs depends largely on speed of memory access OS still needs control over memory access of processes 10 3.1 Virtual memory Processes do not use addresses in physical memory, but virtual addresses Virtual address then gets mapped to physical address Memory gets chopped into pages of fixed size (4KB), Page table establishes mapping (different for each process) Memory Management Unit (MMU) in CPU performs the mapping Mapping gets stored in cache called translation lookaside buffer (TLB) which needs to be flushed upon context switches Advantages Processes use seemingly contiguous memory location, but do not have to be contiguous in physical memory Can assign more memory than physically available Can separate address spaces of different programs OS can ensure that one process cannot read/write another processes’ memory → important for security For shared memory example Parent and child process Attach that shared memory to address space of the process, then can have access to it as if it is part of their own Efficient for inter-process communication (IPC) 3.2 OS Security OS assumes process actions reflect user intentions Mainly two ways why processes may be malicious user accidentally runs malware process uses maliciously crafted input that exploits bugs Problem for all classical operating systems Ideally, OS enforces security, so all software outside TCB can be arbitrarily malicious and OS still enforces that goal (not achieved) Buffer overflow possible, because: In a straight forward attack there are two steps: 11  1. Change the programs controls flow (i.e stack) 2. Inject and execute attacker’s code For 1: Stack canaries (gcc option -fstack-protector) For 2 the OS can help in particular 3.2.1 Data Execution Prevention (W ⊕ X) Problem is von Neumann architecture Code and data share same memory space Mark some areas of memory (stack, heap, data segment) as non-executable Data Execution Prevention (DEP) Ideally implemented in CPU’s MMU with the NX bit (non-executable) Bypassing non-executable-stack Execute code that is already in the program Almost always the C standard library is in memory space Idea Just overwrite the function with onf of a function in libc, pass the correct arguments and have it execute for us (e.g spawn a shell) Return to libc attack 1. Find address of system() 2. Overwrite return address with that found one 3. Give /bin/sh as argument Return oriented Programming Not returning to libc functions but arbitrary addresses Can be chained if each targeted block ends in return Has been shown that Turing-complete gadget is easy to find on most architectures Searching for gadgets (and some extent chaining) can be automated Address Space Layout Randomization (ASLR) By randomizing position of dynamic libraries cannot know addresses of code anymore Also randomizes position of: stack data segment heap to randomize position of executable code segment use gcc -fpie (position independent execution But, relative distances between memory objects still remain Layout of stack and library table also remain → problem if one address of one instruction leaks (e.g format-string attack, side-channel attack etc) On 32-bit machine not enough entropy 12 3.2.2 Race Conditions A race condition bug is where software depends on uncontrollable timing behaviour in an unintended way Time of check to time of use (TOCTTOU Caused by changes in a system between cheking of a condition (such as security credentials) and the use of the result of that check Example: if (access("file", W_OK) != 0) { exit(1); } fd = open("file", O_WRONLY); write(fd, buffer, sizeof(buffer)); If attacker attempts between access() and open() to run symlink("/etc/shadow", "file", the ”file” will point to password database 4 Malware Malicious software or functionality that a user does not intend to run. Typical features: Some way to trick user into running it A damage routine (or payload= performing the actual malicious behavior Often some functionality to hide from malware scanners 4.1 Viruses Infects a host program – Copy itself into the host program – Change entry point to the entry point of the virus – Change the return address from the virus code to the original entry point Characteristic: spreads by infecting other files traditionally need an executable host file Can also infect office files with macros 4.2 Worms Stand-alone malware program which spreads without a host program Two different ways of spreading: 1. With user interaction (e.g email) 2. Without user interaction through software vulnerabilities 4.3 Trojans offer useful functionality and hidden malicious functionality not self-replicating used for a variety of criminal actions can be used for targeted attacks also used by governments to wiretap Internet telephony 13 4.4 Rootkits After compromising a computer, malware/attacker want to hide their traces → rootkit Most powerful ones run in the kernel – Can hide existence of files by modifying file-sytem driver – Can hide existence of process by modifying process management – Can create hidden filesystem to store data – Can temper with malware scanner – Can communicate via covert channels Possible countermeasure: cryptographically sign all kernel modules and drivers kernel rootkit can only be detected and removed when booting another clean OS Malware can compromise the boot of a computer rootkits that modify the bootloader are called bootkits Typically installed in the MBR of the hard drive bootkits can make sure to re-infect a computer at each reboot 4.5 Malware Functionality Different aspects – Harm: how they affect users and systems – Transmission and propagation mechanism – Activation – Stealth: how do they stay undetected Worms and viruses can turn infected computers into botnet zombie hosts primarily to obtain network for DOS attacks Ransomware encrypts data Spyware used to exfiltrate information Targeted malware can have specific damage routines Some malware just destroys data digital vandalism 4.6 Malware detection idea: look at incoming files before they are stored on the hard drive Scan for malware, stop if malware detected Alternative: full scan of all files on hard drive Two ways of detecting malware Signature based detection (look for known patterns in files) Behavior based detection (analyze behavior and make decision) 14 4.6.1 Signature-based malware detection Only detects known malware Essential requirement: update signature database daily Will never detect zero-day malware Signatures can be as simple as cryptographic hash or sequence of system calls Look for certain code sequences (less susceptible to minor changes) powerful against known malware used by all major anti-malware software 4.6.2 Code polymorphism To defeat signature-based detection use autamated engine to generate many versions of a virus All have same functionality but look different in principle there is an infinite number of ways to mutate a program and and keep functionality (insert NOP, permute independent instructions) Metamorphism: self-mutating code Virus that print nutated copies of itself 4.6.3 Packers A piece of software that takes the original malware and compresses it, thus making it unreadable can be simple XOR, bit-flipping or more advanced encryption with AES Can use multiple layers of packing Can unpack blockwise so that never the full malware is in memory Two ways to detect Static detection: try known packers on payload Dynamic detection: run malware (with unpacking) in safe environment (sandbox) 4.6.4 Behavior-based malware detection approach to detect unknow variants of malware: behaviors or heuristics Simple case: use wildcards in signatures Advanced case: run malware in safe environment (VM, sandbox) Behavior analysis relies on experience Good at detecting malware with behavior that has been seen before Typically not good at detecting really new malware, certainly not reliable 15 4.6.5 Antivirus software degrades system’s performance false positives can break system functionality highly trusted/privileged access, but not neccessary trustworthy backdoor Users may feel secure and behave less careful AV software can actively degrade security need to unpack zipped files, those need to sit somewhere in memory or on disk → Zip Bombs 5 MAC A system implements mandatory access control (MAC) if the protection state can only be modified by trusted administrators via trusted software Trusted administrator defines policies (so which process is allowed to access which file) User cannot disable 5.1 Multi-evel security: Bell-LaPadula Control information flow to protect confidentiality All objects are assigned security levels Top secret Secret Confidential Unclassified Users are assigned clearance levels Processes are assigned security levels Rules: – Simple Security property A user is not allowed to read objects above its clearance level → no read-up – The ? Property A subject/process is not allowed to write to an object below its security level no write-down Tranquility: – Strong tranquility: Security level of process never changes – Weak tranquility: (desirable) Security level never changes in a way that it violates the security policy. Typically start low, increase as the process reads higher level information 16 5.2 Biba model Model to protect integrity Complement of secrecy in Bell-LaPadula Assign integrity levels to all objects and users Crucial Very important Important Prevents ”pollution” of information wiht higher integrity level Rules: – Simple integrity: A subject (user/process) is not allowed to read objects below its level → no read-down – The ? Integrity Property: A subject is not able to write to an object above its integrity level → no write-up 5.3 Linux Security Modules Framework that allows kernel to support various security models without favoring any implementation Hooks on modules when accessing security-critical resources Criticism: – Small overhead even if no LSM is loaded – Designed for access control, but can be abused e.g to bypass the kernel’s GPL license – LSM is compiled and enabled in kernel, so its symbols are exported → every rootkit and backdoor writer will have every hook he ever wanted in the kernel – Only for access control – grsecurity and RSBAC need more than that – Stacking multiple security modules is problematic 5.4 Type Enforcement Everything (processes, files, sockets) has a security context/label in the format:user:role:type(:level) Security context is stored in file system, rest in kernel Mainly important: type All access has to be explicitly granted by allow rules of format allow source_type target_type : object_class permissions Example:allow user_t bin_t : file {read execute getattr} Default assignment of security context processes get context of parent files get context of parent directory Various ways to change behavior 17 6 Virtualization 6.1 chroot jail ”Jail” process inside a subdirectory (changes the dedicated vnode of a process, children inherit this) Filesystem content outside of that subdirectory is not visible (the subdirectory is root directory for that process) You need provide ”sane” environment for the process You need to do chdir() first to change the working directory since chroot() does not do that Close all file descriptors before chroot() since they may allow access to files outside of chroot tree Drop root privileges by calling setuid() not seteuid (because with seteuid(0) it could be restored) By design, root can escape (with chrooting to a subdirectory) 6.2 OS-level virtualization OS offers multiple isolated user-space instances (containers, jails, partitions, virtual environments etc) Containers each have their own root file system but share kernel of the host OS Each container can see only part of resources (I/O, CPUs, memory, file system) Advantages Fairly easy to set up Convenient for testing new configurations Essentially no overhead or performance loss (opposed to full virtualization or emulation) since all containers use system’s normal system call interface System-level backups are easy Multiple environments parallel Maximum use of hardware resources privileged containers of LXC map container user root to host’s user root, so unlimited root can escape unprivileged containers map container user root to non-root user outside of container → reduce security to unprivileged users 6.3 Emulation Can emulate a whole computer in software Install unmodified guest OS in emulator All instructions from guest get translated to code that runs in host Can even translate from one architecture to another Different to simulation that is just a model not an actual replication Serious performance penalty 18 6.4 Virtualization Emulators emulate the hardware in software With virtualization we use the hardware directly But then it is limited to OSs that can run on that hardware architecture Recall ring structure: – Introduce a software abstraction layer, Virtual Machine Monitor (VMM) or hypervisor – VMM needs higher privilege than guest OS – run VMM in ring 0, guest OS in ring 1 – Since OS needs direct access to memory and hardware it must be in ring 0 → virtualization seemed impossible for long 6.4.1 Software full virtualization Translate kernel code on the fly replace nonvirtualizable instructions with new sequences of instructions with the intended effect on the virtual hardware Guest OS is not aware that it is in a virtual environment (VMM provides virtual BIOS, virtual devices, virtualized memory management etc) No modification of guest OS, no host OS or hardware assistance 6.4.2 Paravirtualization Guest OS and drivers are modified nonvirtualizable ring 0 instructions get replaced with hypercalls to virtualization layer no support for unmodified OSs Value over full virtualization easy to modify OS lower overhead, but depends on workload hypercalls re-introduce some overhead 19 6.4.3 Hardware full virtualization Disadvantage of software full virtualization: complex VMM Solution: do it in hardware Introduce protection ring -1 for hypervisor 7 Sandbox 7.1 Linux Containers LXC OS-level virtualization runs multiple isolated Linux systems (containers) ony a single control host provides virtual environment with own CPU, memory, block I/O, network etc achieved by namespaces(process isolation) and control groups or cgroups Similar to chroot, but offers much more isolation 20 7.1.1 Namespaces Restricts what a container can see Proivdes process-level isolation of global resources Processes within a namespace have the illusion they are the only process in the system Six different namespaces: Mount mnt – Purpose: different processes have different views of mount point – Isolate the set of file system mount points seen by a group of processes so that processes in different mount namespaces can have different views of the file system hierarchy – shared mount allows creation of an exact replica of a given mount point A shared mount point has any mount within the original mount point reflected in it and vice versa – slave mount allows creation of a limited duplicate of a given mount point A slave mount point has any mount within the original mount point reflected in it, but no mount within a slave mount is reflected in its original – private mount is default type of a mount and does not receive or forward any propagation event 7.1.2 Control groups cgroups namespace proivde per process resource isolation solution cgroups provide resource management solution (handling groups) Set upper bound on resources that can be used Fair sharing of certain groups 7.2 Mobile (Android) Sandboxing 7.2.1 Middleware Layer Android Runtime runs Dalvik Virtual Machine relies on underlying Linux kernel for threading and low-level memory management Android Runtime also contains core libraries which provide most of functionality available in the core libraries of Java and provides core APIs of Java Native libraries are exposed to developers via Android application framework Application framework provides developers API to basic functionalities and services (e.g set alarms, access location information, set up phone call etc) 21 7.2.2 Application Layer Written in Java Each app is executed within its own Dalvik VM instance Include native code via Java Native Interface (JNI) Consist of following components Activities (user interfaces) Services (background processes) Broadcast receivers (application mailboxes) Content providers (SQL-like databases) 7.2.3 Android Security Framework Application Isolation VMs and Sandboxing Apps are written in Java (but native code can be used) Application Access Control Permission framework at middleware layer DAC to file system at Linux kernel level Code integrity System code is signed by Google Applications are signed by developers using developer key Application Distribution Apps go through vetting process before they are uploaded to app market Isolation via Sandboxing Each application is isolated in its own sandbox Apps can access only own resources Access to sensitive resources depends on the applications permissions Sandboxing is enforced by Linux in two different levels Sandboxing at process level – Each app is executed in a dedicated process – Access to sensitive resources depends on permissions – System assigns a unique UID (also called AppID) to each app – UID is generated at install-time – OS runs each app as a separate process with own UID – Apps run within sandbox environment in kernel Sandboxing at filesystem level – Each app has its private data directory – Only the app can access its own data directory – Sandboxing applies to all applications, including native ones Can go wrong with permission escalation 22