Ohm2013 'defeating trojans' slides

Embed Size (px)

DESCRIPTION

The slides of my 'defeating trojans' talk at the OHM2013 festifal in Geesterambacht. The talk is about how applying encapsulation, decomposition, attenuation and, most important of all, delegation to multiple granularity levels can lead to tighter, more user friendly and more flexible security. How applying these general concepts can help reduce the size of the trusted code-base and why this is essential if we want to defeat Trojans and mitigate the impact of software vulnerabilities. After laying down some general guidelines for achieving this, the talk goes into how the AppArmor/MinorFS/E stack and to a lesser extend the AppArmor/MinorFS/C++ stack allowed these concept to be applied for building custom high integrity systems by 'taming' the system's persistent mutable state. The talk is than concluded with an outline of how the upcoming MinorFS2, with the help from AppArmor, will try to retrofit this taming of mutable state to programs not explicitly written to use MinorFS, while at the same time providing convenient APIs for interpreters and programs with special needs, thus creating an essential building-block for defeating Trojans and mitigating the effects of software vulnerabilities.

Citation preview

  • 1. Defeating Trojans Retrofitting shared mutable state for file-systems Rob Meijer ( [email protected] )

2. Lets get some facts straight 3. Lets get some facts straight The user is NOT the weakest link ! 4. Lets get some facts straight The user is NOT the weakest link ! Sharing security tokens is NOT stupid ! 5. Lets get some facts straight The user is NOT the weakest link ! Sharing security tokens is NOT stupid ! Security and usability are NOT mutually exclusive. 6. Lets get some facts straight The user is NOT the weakest link ! Sharing security tokens is NOT stupid ! Security and usability are NOT mutually exclusive. MOST software vulnerabilities are irrelevant. 7. Delegation Users are 'programmed' to handle delegation. Delegation != Abdication Delegate 'authority' NOT 'identity' Authority must be decomposable. Authority should be attenuable. Authority could be revocable. 8. Weak links The user 9. Weak links The user Disregard for socio-genetic security-awareness 10. Conditioning 11. Conditioning 12. Passwords suck Identity Delegatable Non decomposable Non attenuable Authority: Delegatable Non-decomposable Non-attenuable 13. Passwords suck We could do with better user authentication. But ... 14. Passwords suck Identity is massively overused ! 15. Passwords suck We need better authorization more desperately than we need better authentication. > 16. Weak links The user Disregard for socio-genetic security-awareness 17. Weak links The user Disregard for socio-genetic security-awareness Identity centric security models 18. Weak links The user Disregard for socio-genetic security-awareness Identity centric security models Single-granularity abstractions 19. Mutable state Public vs private 20. Public/global mutable state Makes composite systems hard to analyze or review. Makes composite systems hard to test. High potential for violating the Principle of Least Authority. Giant hurdle for reducing trusted code-base size. 21. The file-system as global mutable state 22. The file-system as global mutable state 23. The file-system as global mutable state Why does Sokoban need access to $HOME? 24. The file-system as global mutable state Why does Sokoban need access to $HOME? 25. The file-system as global mutable state Why does Sokoban need access to $HOME? Why does Bitcoin need to store sensitive data in $HOME? 26. The file-system as global mutable state Why does Sokoban need access to $HOME? Why does Bitcoin need to store sensitive data in $HOME? Why is Sokoban part of Bitcoin's trusted code-base? 27. The file-system as global mutable state Why does Sokoban need access to $HOME? Why does Bitcoin need to store sensitive data in $HOME? Why is Sokoban part of Bitcoin's trusted code-base? Programs need privacy too! 28. Weak links The user Disregard for socio-genetic security-awareness Identity centric security models Single-granularity abstractions 29. Weak links The user Disregard for socio-genetic security-awareness Identity centric security models Single-granularity abstractions Public/global mutable state 30. Weak links The user Disregard for socio-genetic security-awareness Identity centric security models Single-granularity abstractions Public/global mutable state Massive size of trusted code-base 31. Weakest link? The user Disregard for socio-genetic security-awareness Identity centric security models Single-granularity abstractions Public/global mutable state Massive size of trusted code-base 32. Weakest link? The user Disregard for socio-genetic security-awareness Identity centric security models Single-granularity abstractions Public/global mutable state Massive size of trusted code-base 33. Basic guidelines Use homo-sapiens friendly security abstractions Use cross-granular abstractions Don't overuse identity Limit public/global mutable state Share authority tokens Decompose and/or attenuate authority Use the Principle Of Least Authority. Minimize the trusted code-base 34. Capabilities Authority-only security tokens (no identity) Capabilities both designate and authorize In fact: designation IS authorization Cap patterns Social patterns = significant Dynamic least authority. 35. Sparse capabilities Capability 'as data'. Basically a strong password without an identity Some well known examples Rumpelstiltskin https://docs.google.com/file/d/0B_sqxoHXGz5ZcEhCOMJWRzRjbmM/edit CapFS: /minorfs/cap/rw-5BA7FFDP4HM1L887BZAK7G857GKJHAUEAK992HCH5DGH59GHWB1S Non human-memorable 'authority' token 36. Object capabilities More secure than sparse capabilities Basically object-reference as capability Ambient-authority and static-mutable-state free subset of Object Oriented Design principles. 37. Process-Persistence Transparent serialization for conceptually persistent processes. Delegated authority survives reboots. E-Language Combines Persistent VATs with object capabilities. Ken Crash-restart resilience for distributed applications. Where do we securely store process serialization? 38. Security Policy 39. MAC & (extreme) DAC Classic UNIX DAC and MAC are a bad fit. SELinux MAC and sparse-cap DAC are a bad fit. AppArmor: Permissive-privileges MAC model. AppArmor MAC and sparse-cap DAC are complementary. 40. AppArmor Security module (MAC) for Linux kernel. No MSc required for profile management. Simple permissive-privileges Restricting 'possibly vulnerable' software. 41. Global mutable state / r, /bin/ r, /bin/** mixr, /usr/ r, /usr/bin r, /usr/bin/* mixr, /usr/local/ r, /usr/local/* r, /usr/local/bin/* mixr, /usr/local/*/bin/* mixr, /usr/** r, /etc/ r, /etc/** r, /lib/ r, /lib/** r, @{HOME}/ r, @{HOME}/** rw, 42. AppArmor Bridging the gap Capabilities MinorFs $HOME 43. Disable global mutable state / r, /bin/ r, /bin/** mixr, /usr/ r, /usr/bin r, /usr/bin/* mixr, /usr/local/ r, /usr/local/* r, /usr/local/bin/* mixr, /usr/local/*/bin/* mixr, /usr/** r, /etc/ r, /etc/** r, /lib/ r, /lib/** r, @{HOME} r, @{HOME}/** r, 44. Public to private / r, /bin/ r, /bin/** mixr, /usr/ r, /usr/bin r, /usr/bin/* mixr, /usr/local/ r, /usr/local/* r, /usr/local/bin/* mixr, /usr/local/*/bin/* mixr, /usr/** r, /etc/ r, /etc/** r, /lib/ r, /lib/** r, @{HOME} r, @{HOME}/** r, /minorfs/** r, /minorfs/cap rw, 45. MinorFS & E MinorFS+AppArmor: Pseudo-persistent-process private $HOME Reduces trusted code-base for private persistent mutable state. E-Language: Uses protected private process serialization Further reduces the trusted code-base 46. MinorFS and native code C++ No memory safety No trusted-code-base reduction Reduced memory integrity Native Easy PP-PID calculation for MinorFS RAII Non-memory resource management integrity Templates Generics as code-base reduction tool. Multi-process programs Use processes as overweight object Delegate attenuated sub-trees between processes 47. '..' considered evil Special '..' directory normally designates parent Capabilities: designation implies authorization The '..' brakes delegation of sub-trees. 48. CapFs and '..' /minorfs/cap/ Dead-end stub '..' for any CapFS node Listing returns an empty directory. 49. MinorFS (1) shortcommings Poor fit for desktop/console applications. Poor fit for most retrofitting purposes. No read-only attenuation Poor scalability and performance Tricky installation dependencies 50. MinorFS2: goals and use-cases Defeating Trojans: retrofitting tamed mutable state Standard dependencies (Ubuntu/Suse) Confidentiality on shared network storage Scalability and performance Read-only attenuation Convenient GranFS/CapFS APIs NodeKen like server platforms Multi-process browsers Bitcoin like systems 51. MinorFS2: performance & scalability AES256 encrypted overlay Yet : sparse == sparse Sqlite based lookups digest-only lookups Client side attenuation. Perl C++ 52. CapFS2: Rumpelstiltskin tree-graph HMAC/SHA256 operation based Client or server side read-only attenuation: ROcap = H(#ro,RWcap) Server side decomposition: childRWcap = H(childname + H(#ro,parentRWcap), secret) ChildROcap = H(#ro,H(childname + parentROcap, secret)) ROcap doubles as file encryption key: FEK = ROcap Path on underlying file-system derived from FEK: Path = H(#store,FEK) 53. MinorFs-2: retrofitting Other programs need privacy too: Non privsep Non ocap Non MinorFs-aware Cross-platform 54. The '.program' convention Convention to create a '.program' file or directory in the users $HOME directory. Base assumption: '.' prefixed content in $HOME assumed user+program private Other $HOME content assumed user-global. HomeFS2: /minorfs/home shows merge-transform of multiple granularity levels Default use of the '.' prefix split Config may define different mappings. 55. MinorFs2: layered design CapFs2: Encrypting sparse-friendly sparse-capability file-system. TmpFs2: Delegates process-lifetime CapFs dir to non-persistent process. GranFs: Multi-level process property registration. Delegates different persistent CapFs dirs using process properties. HomeFs2 Creates home like view with links to GranFs delegations and $HOME 56. LibMinorFs2 (C/C++) Allowing simpler MinorFs awareness. Stub implementations non AppArmor systems. Query available privacy process property sets. Multi-level process-property registration. Process property set CapFs object. Directory traversal/decomposition/attenuation abstractions. 57. Roadmap Complete MinorFs 2.0 before the spring 2014 AppArmor feature-freeze Any help here is extremely welcome ! Get MinorFs 2.0 accepted in AppArmor Complete MinorFS 2.1: More process properties for GranFS LibMinorFS Get projects to include LibMinorFs usage: The Dr-SES stack BitCoin Chrome/chromium 58. Embrace delegation http://ohm2013.capibara.com/ [email protected]