Building Secure Systems

1. GENERALLY ACCESSIBLE Building Secure Systems Plattform Security – Isolation, Privileges and Server Security Walter Kriha, Computer Science and Media Faculty August 2, 2006

2. Overview: Plattform-level Methods for Secure Systems • Different privilege levels • Isolation of components (virtual memory, micro kernels) • Interception with Wrappers • Virtual Machines • Inversion of Control, Dependency Injection Architectures • Capabilities • Name Spaces, Services and Components • Trusted Computing Bases • Sandboxes • Jails • Funnels • Code Verification

3. Current Problems and Approaches

4. Distributed, after-the-fact security for home computers Security Specialists security tools SMS based code control Directory update PC with tracking SW Analysis report MS-Data Center Admins PC with tracking SW home office

5. All resources the user has a right to access (ACL) The Sandbox (Access Domain) Program started by user object object User A Sandbox object Z CODE service Y service Sandbox Policy: Program X is allowed to use service Y and Object Z User rights: May do everything! Reference Monitor service A Sandbox restricts a users rights! It needs a description containing the rules for a specific domain (constrained program). A reference monitor reads those rules. Every access by the code is intercepted by the monitor and the rules are applied. If the rules do not match the intended access it is blocked. No matter how powerful the users rights are, the code cannot escape the sandbox as long as the reference monitor is not bypassed.

6. Main(string FileName = „foo“) Process Mapping string to resource Open(fileName) All Files File named „foo“ User has rights for all those files. Process needs the same rights as it does not know which one the user would like to process

7. Main(FileDescriptor) for open file „foo“ Process No mapping from string to resource! Read(FileDescriptor) „foo“ file User has rights for all those files. Process needs NO rights to open user files. Gets open stream as a capability

8. Server Rechte Benötigte Rechte für Aufgabe User F Rechte Ambient Authority Sandbox

9. System Architecture and Security Consequences

10. Immutable Laws of Security? • 1. If the data hasn’t crossed a trust boundary, you don’t really care about it. • 2. If the threat requires that the attacker is ALREADY running code on the client at your privilege level, you don’t really care about it. • 3. If your code runs with any elevated privileges (even if your code runs in a restricted svchost instance) you need to be concerned. • 4. If your code invalidates assumptions made by other entities, you need to be concerned. • 5. If your code listens on the network, you need to be concerned. • 6. If your code retrieves information from the internet, you need to be concerned. • 7. If your code deals with data that came from a file, you need to be concerned (these last two are the inverses of rule #1). • 8. If your code is marked as safe for scripting or safe for initialization, you need to be REALLY concerned.

11. OS-Architecture and Security Mechanisms

12. CPU Protection Levels State of protected mode bit: 1 = protected/kernel mode 0 = application/user mode 0/1 Sensing operations (I/O) Control operations (halt, memory mgmt.) Regular compute operations (add, mul) Most CPUs offer a simple protetion scheme. Dangerous operations (sensing, control) are only allowed when the CPU has been put in kernel mode (protection bit is set). Applications can NOT change the state of the CPU arbitrarily. They MUST use certain controlled gates (software interrupts) to change the mode. From then on, operating system code runs!

13. Switching to Kernel Mode Application Application stack used User Mode, CPU doing harmless things C Language Library System Call Library Software Interrupt – Kernel Trap (CPU instruction) Kernel Mode, CPU doing critical things Operating System Kernel stack used Hardware (CPU, I/O) Only in kernel mode will the CPU allow critical instructions. The application will be terminated if it tries to execute critical instructions without changing through kernel traps into protected mode.

14. Security Properties of Privilege Modes Rights/Authority Trick code into extending callers privileges code code code Attack code on same level code code code code code code Turn off privileged mode code

15. Security Properties of Privilege Modes • Rights organized as privilege levels typically lead to ambient authority for code pieces because no sectors are possible within the levels. Most code pieces would need a different segmentation of rights. • On the same level each piece of code is a threat to all others (same privileges, no sep.) • Every mode change needs to be undone later. Software needs to make sure that on the way back the privilege mode gets reversed to the old value. There cannot be a bypass of this piece of code • The mode change needs to be authorized • The privileged code needs to interpret arguments carefully to avoid extending the callers privileges in an unwanted way (confused deputy)

16. Address Isolation CPU 000000000000000000000000000000 256 MB Random Access Memory (physical) Application 2: all addresses in same range as every other app. Memory Management Unit (MMU) Same! Virtual Address 32 bit address register Application 1: all addresses in same range as app 1. page table Process A page table Process B Physical Address Process A Physical Address Process B

17. Monolithic Kernels runtime loadable Application 1 device driver firewall module audio driver User Mode compiletime Kernel Functions Data memory managment Kernel Mode file management process management device drivers Fast access to functions and shared kernel data

18. Microkernels Application 1 process management server Device Driver file management server security management server memory managment server Device Driver User Mode Interprocess comm. basic memory management Kernel Mode Context switching Interrupt handling basic security Clock driver Fast access to functions and shared kernel data Interprocess Communication or system calls

19. From: G.Heiser, Virtualization of Embedded Systems

20. Armored Monolithic Kernels User Mode Wrapper gurantees transactional updates compiletime Data memory managment Kernel Mode audio driver file management Kernel functions device drivers process management Data Intercepted and controlled calls to and from kernel Temporary Copy of kernel data Modified page table to restrict driver to certain kernel addresses

21. VM Armored Micro Kernels Data memory managment device drivers file management Kernel functions User Mode process management Inter Kernel Communication Inter Kernel Communication VM VM Microkernel (e.g. L4) Kernel Mode

22. The Secure Extension Problem

23. Device Driver Kernel Driver Controller driverControl() Extern ProcTab tab; Extern int criticalFunc() Init() Read() Write() IOCtrl() HandleInt() Gobal: ProcTab criticalFunc() Resolved at runtime or linktime

24. Device Driver Kernel Dependency injection Driver Controller driverControl() private ProcTab tab; private int criticalFunc() Init(ProctTab, crit.Function) Read() Write() IOCtrl() HandleInt() Gobal: ProcTab criticalFunc() criticalFunc() criticalFunc()

25. Der Driver kann ausschließlich über die Argumente und deren Methoden auf Kernel-Daten oder Funktionen zugreifen. Es gibt keine andere Möglichkeit, auch nicht durch die Navigation von globalen Verzeichnissen oder durch sog. Composite Objects (Design Pattern), die über ihre Tree-Navigation Zugriffe auf viele andere Objekte gestatten. • Der Treiber macht eigene Abhängigkeiten und Bedürfnisse im Interface der init-Methode sichtbar: Dort steht, was der Treiber vom Kernel benötigt, um zu funktionieren. • Der Kernel ist in der Lage, Proxy Objekte oder speziell für den Treiber zugeschnittene Closures (das sind initialisierte higher-order Functions oder deren objektorientiertes Äquivalent bzw. deren Simulationen durch Command Patterns) herzustellen und an den Treiber zu übergeben. Damit kontrolliert der Kernel komplett die Ausführungsumgebung des Drivers.

26. Plug-in Framework Inject dependency (DI principle) Declare dependency Init(Node) Read() Write() Initiate Call (IOC principle) Use reference (object capability principle) Node Node Node Node does not allow traversal and so plug-in cannot access parent node. The plug-in declares ist dependencies in ist interface

27. Modes and Privileges

28. Same runtime environment for all applications Cycle stealing applications create a problem for near-realtime multimedia applications A common, navigable filesystem with ambient authority Application Server (privileged) Global Administrator Dangerous accounts, single audit and log features Tons of unsafe but privileged scripts and utilities (setUid) Common Filesystem Lots of unverified system libraries with memory leaks etc. Privileged Utilities >300 complex system calls Huge Libraries Incomplete quota administration System call Interface Countless dynamically loadable modules Attacks on random number generation Module Legacy OS Module Driver Driver Driver Unsafe kernel languages (memory) >100.000 drivers for windows Hardware (CPU etc.) Covered channels (cache, bios, CPU) Huge TCB, 2 modes only Network scans (IP seq.)

29. Driver.c: If (uid = 0) { // do something harmless } // run as root now!

30. Interprocess communication Para-virtualisierung Trusted Computing Base

32. Rules for Virtualization/Guest Operating Systems VMs (die gewöhnlich unter privilegierten Accounts arbeiten) sollen wie andere kompromittierbare Dienste behandelt werden, d.h. am Besten unter Verwendung von Isolationstechniken wie chroot, systrace, ACLs, sowie POLA Regeln. Die Virtuellen Maschinen wie die Gast-Betriebssysteme sollten so schmal wie möglich konfiguriert sein. Ungenutzte Hardware-Treiber oder Services sind auch beim Gast zu entfernen. Die Integrität der Gastsysteme ist genauso zu sichern wie die der Trägermaschinen durch regelmässige Updates, Privilegieneinschränkungen der Gast-Applikationen etc. Systeme die mehrere unterschiedliche Privilegienzonen ermöglichen sind vorteilhaft (XEN). Sicherheitslevel von Plattformen (z.B. Berkeley Security Levels) sind zu nutzen. [Orm] Ressources: Ormandy

33. Software-based Isolation: Singularity

34. Singularity Features Die Kapselung beruht auf leichtgewichtigen Prozessen Kernel, Applikationen, Treiber und System-Server sind allesamt Prozesse Ein Prozess ist ein geschlossener Object-Space, der keine Referenzen in andere Prozesse hinein besitzt IPC ist durch ein Kanalkonzept realisiert, das sich durch streng typisierte Kommunikation, definiert durch State-Machines, auszeichnet Objekte können an andere Prozesse übertragen werden, wechseln dann jedoch den Besitzer, so dass keine cross-process synchronization Probleme oder zentrale Garbage Collection nötig sind. Ein kleiner Teil Code ist unverified und trusted, der große Rest von Microkernel und Applikationen etc. ist verifiably trusted, d.h. er wurde vom sicheren Compiler erzeugt. Es sind keine dynamischen Erweiterungen von Prozessen (Code laden) erlaubt. Jede Erweiterung muss ein eigener Prozess sein. Jede Softwarekomponente ist durch Meta-Daten umfangreich beschrieben und wird ohne eigenen Installer installiert.

35. Small, light-weight processes No cross object space sharing p2 Safe interprocess communication (separation) One virtual address space p1 Individual runtimes (GC, libraries) Trusted, not verifiably safe

36. Eheap Typed channels with state-machines for IPC Application Code Extension Code CLR Lib. CLR Lib. Runtime Runtime No common, shared variables between both object spaces

37. public contract NamespaceContract : ServiceContract { in message Bind(char[] in path, ServiceContract.Exp:Start exp); out message AckBind(); out message NakBind(ServiceContract.Exp:Start exp); in message Notify(char[] in pathSpec, NotifyContract.Imp:Start imp); out message AckNotify(); out message NakNotify(NotifyContract.Imp:Start imp); in message Find(char[] in pathSpec); out message AckFind(FindResponse[] in results); out message NakFind(); out message Success(); override state Start: one { Success! -> Ready; } state Ready: one { Bind? -> ( AckBind! or NakBind! ) -> Ready; Find? -> ( AckFind! or NakFind! ) -> Ready; Notify? -> ( AckNotify! or NakNotify! ) -> Ready; }} Als eingebettete Klassen eines Kanals werden jeweils ein exporter bzw. importer definiert, die die entsprechenden Messages des Kontrakts zugeordnet bekommen. Will ein Prozess einen Kanal eröffnen, dann erzeugt er Instanzen von exporter und importer und schickt die exporter-Instanz über einen existierenden Kanal an den Empfänger. Danach können beide miteinander kommunizieren.

38. <manifest> <application identity="S3Trio64" /> <assemblies> <assembly filename="S3Trio64.exe" /> <assembly filename="Namespace.Contracts.dll" version="1.0.0.2299„ /> <assembly filename="Io.Contracts.dll" version="1.0.0.2299" /> ….. <assembly filename="ILHelpers.dll" version="1.0.0.2299" /> <assembly filename="Singularity.V1.ill" version="1.0.0.2299" /> </assemblies> <driverCategory> <device signature="/pci/03/00/5333/8811" /> <ioMemoryRange baseAddress="0xb8000" rangeLength="0x8000„ fixed="True" /> <ioPortRange baseAddress="0x4ae8" rangeLength="0x2" fixed="True" /> …. <extension startStateId="3" contractName="Microsoft.Singularity-.Extending.ExtensionContract" endpointEnd="Exp„ assembly="Namespace.Contracts" /> <serviceProvider startStateId="3" contractName="Microsoft-.Singularity.Io.VideoDeviceContract" endpointEnd="Exp„ assembly="Io.Contracts" /> </driverCategory> </manifest> A manifest file describes the physical structure of an application and its installation needs. Control is never passed to the application for installation purposes (no setup.exe)

39. /bin/sshd @ /users/ted (+ {/grp/pathrole})* + /bin/ms/office/word Compound Principal

41. Tracked data structures with ownership transfer When creating a TRef<T>, the constructor requires an object of type T as an argument. The caller must have ownership of the object at the construction site. After the construction, ownership has been passed to the newly allocated TRef. The Acquire method is used to obtain the contents of a TRef. If the TRef is full, it returns its contents and transfers ownership to the caller of Acquire. Afterwards, the TRef is said to be empty. Release transfers ownership of a T object from the caller to the TRef. Afterwards, the TRef is full. TRefs are thread-safe and Acquire operations block until the TRef is full.

42. Privilege Reduction vs. Capabilities

43. Privilege Restriction and Separation with Rights Reduction vs Capabilities additive Model (default is deny) Subtractive Model Root Directory capability Change runtime environment to jail Change owner User change identity to user User Hand directory capability to unprivileged user process. Without capabilities user process cannot access resources Jails strips off other rights

44. Classic *-properties Vista Integrity Levels L2 L2 Write-down Write-down Write-up Write-up Read-down Read-down Read-up Read-up L1 L1 L1 Vista: Lower level unprotected against upper level attacks. Upper level open to luring attacks and data exposure. Ambient authority through queries and messages

45. Systrace in OpenBSD wrapper (etc/systrace) Application System Call: open(/tmp/foo, mode); /etc/systrace (policies) Operating System Systrace Interceptor policy_for_application: native_read filename match „/tmp/*“ then permit Systrace intercepts system calls and evaluates them according to specified policies. By wrapping user shells, applications and daemons most code can be easily sandboxed.

46. Privilege Restriction and Separation with Identities or ACLs MakeMeAdmin DecreaseMyRights User User Rights Admin Rights Extend Roles etc. start Reduce Roles etc. start Privilege Starter Prog. Program Rights Admin Rights vector start Program Admin Rights vector

47. Polaris The file is edited in the context of a powerless dummy user and then copied back. The application gets the file via the so called „powerbox“ – a GUI component that distributes capabilities upon user request.

48. „Sandbox“ Polaris Secure Desktop Running mail program Running Excel program open attachment Execute with macros enabled Copy over Excel file With macros Excel file With macros Copy back Dummy user session with restricted rights Real user session Windows Operating System

49. Secure Server Design and Reduction of Exposure by Software-Architecture

50. Sicherheitsprinzipien beim Server-Design • Isolierung der Server-Prozesse durch chroot oder jails • Server-Prozesse laufen als unprivilegierte User • Der Zugriff auf die Datenbank sollte minimale Rechte besitzen • Verschiedene Funktionalitäten sollten auf verschiedene Prozesse verteilt werden • Nach: Maxwell Krohn, Building Secure High-Performance Web Services with OKWS