**SECURITY KERNEL** =================== - Reference monitor model: Audit ^ | | Subject-->Reference monitor--> Objects ^ | | v Access Control Database - Fundamental principles/goal of a security kernel: + COMPLETENESS: it must be impossible toby pass a security kernel. i.e every operation need to be monitor + ISOLATION: security must be tamperproof, i.e. must be able to protect itself + VERIFIABILITY: is it correctly implemented? - Virtualization and sharing: + easy way to control resource access + process accesses resource using a virtual name/address that kernel maps to physical name + kernel control the mapping, hence, can prevent to processes from sharing a portion of resource that should not be shared - Cases when virtualization does not works + resource is statically allocated to a number of processes, and is not dynamically reallocated + resource is allocated by the direct actions of users TRUSTED PATH - users and sysadmin must carry a number of function in any system through direct interaction with the kernel (i.e, without intermediate layers of untrusted software). E.g: + login function, + specification of an access class + administrator functions such as changing security attributes and users and files. - Requirement: + prevent Trojan horse in user's process from being able to mimic the login sequence... + users must be able to determine (from a trusted source), the access class of the process with which they are interacting + administrator: able to verify the output received on the terminal did not come from a Trojan horse. ==> need a mechanism that effectively authenticate kernel to users - hence, *trusted path* (or secure path): provide direct communications link to kernel or to trusted software. Example: + 2 terminals, one for normal work, one hardwired to kernel (costly) + using secure attention, i.e, event that signal the kernel to grab the terminal away from untrusted software. This must be one that cannot be fake, intercepted or masked (in VAX security kernel, we saw some thing similar) + e.g: special area on the screen reserved for kernel communication, or some special button control only by kernel - If user's terminal is an intelligent device or a PC, this is a problem, because trusted path must persist from the user's keyboard, through any software in the terminal or PC, to the kernel in the host) ==> software in the terminal or PC must be verified TRUSTED FUNCTIONS KERNEL SECURITY POLICIES - often enforce by discretionary access control: + allow user to set access rights to an object + enforce those rights on each access to the object BUT: kernel does not restrict the values to which those rights may be set (thereby leaving access controls wide open to a Trojan horse attack) WHY? - a program in the user's process can give away access rights (hence, it is possible that the program accidentally give away access rights to a Trojan horse) Solution (to mitigate ...) 1) it is better if there is trusted path that only the user can set access rights 2) use an integrity policy in which integrity access classes are assigned to subjects and objects based on some measure of reliability (like that in VAX security kernel below) i.e: kernel will prevent high-integrity programs and data being modified by lower-integrity programs. Implication: once you login at a high integrity level, your process will only be able to run high-integrity programs. And you need not worry about accidentally using a low-integrity program that might contain a Trojan horses. Limitation of Integrity Policy: all programs used in a high-integrity process must be of high integrity. This makes the use of normal-integrity tools such as compilers and text editors impossible in conjunction with these high-integrity program. KERNEL IMPLEMENTATION STRATEGIES Depends on the restriction you got 1) Identical operation system: - must support existing OS with minimal change - must support all existing apps with no change (hence no changes to the sys call interface) ==> solution: Virtual machine monitor + kernel idea's of a subject is in fact a virtual machine + kernel cannot perform any finer-grained access controls over processes in a single virtual machine 2) Compatible operation system - can change the OS, but not the API with applications Solution: Emulator, converting API from application into kernel calls But there are some problems with this approach, due to the incompatibilities between the security policy that the kernel must enforce and the characteristics of the interface to be emulated: + some functions of the interface are not secure according to the new policy and cannot be emulate > e.g: if kernel enforce mandatory controls, functions that reveal global dynamic status about the system cannot be emulated (because under such policy, no process can read/write to global object) (this is not a problem with VMM approach, because each machine runs on its own complete OS in its own security domain, can function quite well without being aware of other machines) + some functions are secure, but exceptionally difficult to emulate > e.g: locks is difficult to emulate with mandatory controls policy because that policy does not allow any system wide object to be read, written by any processes. (in a discretionary access control, the lock manager enforce controls on the locks, so that a process may only use a lock when permitted by the process that created the lock. The system-wide object here is the list of process waiting on that lock) 3) New OS: - can change the OS, - can change the apps interface **THANH NOTE's on VMM Security kernel for VAX** =============================================== # ABSTRACT - development of virtual machine monitor (VMM) security kernel for VAX-architect - support multiple concurrent virtual machine, provide isolation and controlled sharing of sensitive data # Introduction Goal: production-quality security kernel 1. meet A1 security requirement 2. run on commercial hw without special modification (to the OS) 3. software compatibility for apps written for both VMS and Ultrix-32 OS (2 and 3 are one of the reasons for choosing VMM approach) 4. acceptable level of performance 5. meet requirement for commercial software product Of these, 1, 2 and 3 are important. # KERNEL OVERVIEW - virtual-machine monitor which create isolated virtual VAX processors. - of course, some change were made to make VAX architecture virtualizable, e.g, change to processor microcode - apply both mandatory and discretionary access controls on virtual machines - each virtual machine is assigned an access class: + secrecy class + integrity class - support ACL on all objects - different from traditional OS: + subjects are virtual machines (in OS, normally it is process) + objects are virtual disks (in OS, it is files, for e.g.) by virtualizing, it is easy for kernel to enforce sharing, because now the kernel control/intercept mapping from virtual to physical # DESIGN APPROACH Why choose VMM approach? ------------------------ + 1) compatibility with existing apps (i.e., don't want to change the sys call interface). But emulator can do the same thing, why not choose emulator? > Cost: emulator was as costly as developing the OS itself and emulator needs to keep tracks of all changes made to the OS > performance: can slow thing (minor reason) > need different simulators for different OS (say want to run UNIX) > besides, some function cannot be emulated, some function are not secure (according to kernel policy) (see above notes) + 2) Keep software development and maintenance costs to a minimum > interface of hw is less complex, and not subject to frequent change Virtualizing the VAX -------------------- This talk about some changes made for the purpose of virtualization - Sensitive instruction and references to sensitive data structure: + because of hardware limit, there are some sensitive but unprivileged instruction + need to made some extensions (like adding a VM bit to the processor status long word) to trap those instruction (when executing with the setting VM bit) - Ring compressions: + normally, for VMM, need at least 3 levels of execution + but VMS operating system (i.e the guest OS) already used all 4 of the protection rings ==> ring compression: i.e compressing from virtual machine access modes to real machine accesses mode. Hence from VMS OS point of view, it still see 4 level of protection rings, but in reality, it only execute on 3 protection rings. (see Figure 2: change memory protection of pages belonging to virtual machines so that their kernel-mode pages become accessible from real executive mode...) ==> Implication: Guest OS lose some of its own security - I/O Emulation (i.e virtualizing IO) + some complex detail, but in general they have to play some trick to make virtualization possible (see section 3.2.3) - Self-virtualization: + ability of a virtual machine monitor to run on one of its own virtual machine and recursively create second-level virtual machines ==> useful for debugging Subjects -------- Two kinds of subjects: *virtual machines* and *users* - Users communicates over the trusted path with a process call *Server* + for operation that need to directly communicate with kernel (like login) + avoid Trojan host risk + (and we will see how to trigger the event that allow user directly establish this trusted path later) + Servers are trusted processes, run only within the kernel + User subjects cannot run user-written code, then who gonna run that code (the virtual machines) + Servers execute only verified code that is part of TCB (Trusted Computing Based?) - Virtual machines: untrusted subjects that run VMOS + user interacts with VMOS in whatever fashion is normal for that OS + can run user-written code + isolation unit from other virtual machine and the kernel + worst, a penetrated virtual machine could only affect other virtual machines with which it shared disk volumes - On login, user issue a CONNECT command to his Server (this is trusted path, to defeat Trojan horse), specifying the name of a VM he want to work with. Once connection is authorized, kernel establish new session between user's terminal line and the requested VM. - Note that for full accountability, one user use one VM Objects ------- i.e. what subjects can access, including: - real device - volumes - security kernel files In this paper, it seems to me that they did not virtualized all disks or all devices. - Some real devices like disk drives, printers, terminals, network lines are shared, hence must be control by TCB - Disk and tape volumes: + each virtual machine may completely control the content of some disk volumes (called exchangeable volumes) + security kernel volumes: access by kernel only, can not be shared > contains VAX security kernel files (like audit log or authorization file) > those files can be use to create virtual disk volumes (for those virtual machines that need only a mini-disks) Access Class ------------ (or security model, read from mike notes) - VAX security kernel enforces mandatory controls (vs. discretionary controls): + i.e. the kernel constraints the ability of a subject to access an object (discretionary: controls on access to an object may be changed by the creator of the object. In case of mandatory, we cannot do this) + implemented by assigning sensitivity label (i.e. access class) to each kernel object and subject - Access class consists of two components: secrecy class and integrity class each has: level and category - Deciding on which subject can perform what type of operation (read/write) on which object is depends on the rule on the access class - Definition of dominates: access class A dominates access class B iff + secrecy level of A >= that of B + secrecy category of A is an improper subset of that of B + integrity level of A <= that of B + integrity category of A is an improper subset of that of B If a virtual machine's access class dominates that of a exchangeable volumes: ==> read-only access to that volumes, Why? + VM cannot write to volumes because it may disclose some information (since VM's secrecy level >= that of volume) + VM can only read from volume because integrity level of VM <= that of B, so it ok for VM to read info that has higher integrity than it standard (see Mike high-level for more) Privileges ---------- - Some operation requires privileges (such as assigning an access class, modify an access class, etc) - User privileges: exercised through only trusted path (those mention above) - Virtual-machine privileges: can exercise by virtual machine (like dismount/mount a volumes) Layering Structure ------------------ Like THE, to reduce complexity (by reduce total number of interactions). Following is level from low to high 1. Hardware Interrupt Handler 2. Low-level scheduler: + create abstraction of level one virtual processors, basic unit for scheduling 3. IO service layer + implement device drivers that control real IO devices 4. VM-Physical Memory layer 5. VM-Virtual Memory layer, couple of interesting thing here (but with every limit functionality) + has shadow page tables, for virtualizing purpose + primary-only strategy: to simplify thing ~ all physical memory that a virtual machine sees be physically resident ~ eliminate demand paging, hence no double paging ~ virtual machines are allocated a fixed amount of physical memory and do their own paging ==> limit the number of virtual machines that can fit into physical memory simultaneously 6. High-level scheduler () 7. Auditing + this is important, a crucial functionality or a security kernel 8. Files-11 File layer (don't know why put here?) 9. Volume layers: implement Vax Security Kernel and exchangeable volumes 10. Virtual Terminal Layer 11. Virtual Printer 12. Kernel interface Layer: implements virtual controllers for various virtual IO device 13. Virtual Vax Layer: emulate sensitive instructions, deliver exceptions and interrupts ... 14. Secure Server Layer: implements trusted path, logs user in and out 15. VM OS: virtual machine operating systems 16. Users Software Engineering Issues --------------------------- experiences from the author - programming language choice: + should choose one most fluent language, and stick to it - Coding strategies: + avoid global pools to minimize possibility of storage channels + preallocated memory at boot time + using padding (no-access guard pages) to detect buffer overflow + initialize just-allocate memory with 1 (to detect uninitialized variables) + sanity check each layers (Down side of layering is less flexible, that is why Hydra don't use it) # HUMAN INTERFACE - There should be trusted path for user to directly communicate with kernel when logging in. Trojan horse must not be able to fake, intercept this trusted path. - Moreover, users must be able to verify that they are communicating with kernel, but not some other program. Administrators must be able to verify the terminal output comes from kernel. - Hence dilemma: usability vs. verifiability. + sophisticated user interface for usability, often complex + but difficult to verify ==> interface built on trusted code cannot match the usability of that built on untrusted code Solution: creating two separate command sets: - Secure server commands: + implemented entirely in trusted code + direct interface to the kernel (guarantee no Trojan horse) + invoked by *Secure Attention Key* (this key cannot intercept by untrusted code) + control terminal connections to virtual machines: Connect, Disconnect, Resume, Show Sessions - SECURE commands + for managing the system + Issued by the guess OS (from guess OS level), calls into kernel + 2 types: ~ VM SECURE: executed in context of the issuing VM ~ User SECURE: submitted to the Secure Server for execution (Hence in context of logged in user, true?) + NOTE: only User SECURE Command can be trusted, because Trojan horse cannot intercept *secure attention key* ~ 1) when a secure command is submitted to secure server ~ 2) VM instruct the user to press *Secure Attention Key* ~ 3) user manually press Secure attention key ==> this prevent a Trojan Horse from completing the execution of User Secure commands What if VM spoof user by passing a different command from what user type? ==> Secure Server displays the action that will be taken by the command and prompt the user to approve or reject the operation. (And since the Secure Server is trusted code, ...) NOTE: the point here is: all activities are monitor, and we defeat Trojan horse - Reclassifying Information + user can change access class of a VAX security kernel files or an exchangeable volumes + source and destination object must lie within the user's access-class range + downgrading the data's secrecy class or upgrading its integrity class requires privileges Why? Because upgrading integrity may let other read its content downgrading a data's secrecy may let other read its content # HOW TO PROVIDE ASSURANCE of SECURITY - review design and code changes (no matter trusted or untrusted code) ==> system-wide effect are considered - intensive testing - use formal method to verify the system: + use specification language to write security model + verify the system meet specification - trusted distribution: + trusted hardware distribution: use security-seal program, evidence is provided if someone tampered with the seal + software trusted distribution: checksum, and message authentication # COMPARE WITH KVM/370 (may need to read more) - faster: VM directly contacts with VMM - more functionality - simpler code (e.g., do not implement demand paging in kernel) **A VMM SECURITY Kernel for the VAX Architecture** ================================================== # Mike high-level: - so we want security, and OS it self with a lot of apps running on it is not secure - Solution: isolation by virtual machine monitor: each OS running on its own private machine, hence does not affect each other. (hence come to also of virtualization techniques) - But now, there is a need to communication between OS, or inside OS itself + inside OS: many channel... + how to make these communication channels secure? + build secure channel at VMM so that can control the information flow - So no we have all sort of object and subject: how to ensure security? + by secure channel, and 2 models: secrecy and security + Secrecy model: read down, write up > at a top-level security, you can read every below you, but you cannot write to low levels, because you may disclose secret info + Integrity model: read up, write down > to prevent/avoid reading tainted data > so you can read up, ok, but you cannot read down, because you may read the tainted data. # 0. Take away - why VMM: + small, hence reduce maintenance costs, and improve security + do not need to modify existing OS (too much) - Challenges: + ring compression What if a OS use all level of ring? --> then it would loose some of it security because of ring compression + io virtualization - Model + Trusted object > Server: trusted process that run inside kernel > VMM kernel + Untrusted > VM + User log into VMM kernel, and is associated with a *Server* + Server runs only verified code + When user wants to connect to a VM > CONNECT command to Server, with VM Id > Session with Server suspended > New session between user and VM established - Objects: + real devices + volumes: > exchangeable volumes (owned by VM) > security kernel volumes: securely access by VMM only Contains *security kernel files* # ABSTRACT - aim: development of a virtual machine-monitor (VMM) security kernel for VAX - How the system's hardware, microcode, software are aimed at meeting A1-level security requirement - but still maintain the standard interfaces - VAX security kernel emphasizes on: performance and system management tools