Ohm2013 'defeating trojans' slides

647 views

Published on

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.

  • Be the first to comment

  • Be the first to like this

Ohm2013 'defeating trojans' slides

  1. 1. Defeating Trojans Retrofitting shared mutable state for file-systems Rob Meijer ( ohm2013@capibara.com )
  2. 2. Lets get some facts straight
  3. 3. Lets get some facts straight ● The user is NOT the weakest link !
  4. 4. Lets get some facts straight ● The user is NOT the weakest link ! ● Sharing security tokens is NOT stupid !
  5. 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. 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. 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. 8. Weak links ● The user
  9. 9. Weak links ● The user ● Disregard for socio-genetic security-awareness
  10. 10. Conditioning
  11. 11. Conditioning
  12. 12. Passwords suck ● Identity – Delegatable – Non decomposable – Non attenuable ● Authority: – Delegatable – Non-decomposable – Non-attenuable
  13. 13. Passwords suck We could do with better user authentication. But ...
  14. 14. Passwords suck Identity is massively overused !
  15. 15. Passwords suck We need better authorization more desperately than we need better authentication. >
  16. 16. Weak links ● The user ● Disregard for socio-genetic security-awareness
  17. 17. Weak links ● The user ● Disregard for socio-genetic security-awareness ● Identity centric security models
  18. 18. Weak links ● The user ● Disregard for socio-genetic security-awareness ● Identity centric security models ● Single-granularity abstractions
  19. 19. Mutable state Public vs private
  20. 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. 21. The file-system as global mutable state
  22. 22. The file-system as global mutable state
  23. 23. The file-system as global mutable state ● Why does Sokoban need access to $HOME?
  24. 24. The file-system as global mutable state ● Why does Sokoban need access to $HOME?
  25. 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. 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. 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. 28. Weak links ● The user ● Disregard for socio-genetic security-awareness ● Identity centric security models ● Single-granularity abstractions
  29. 29. Weak links ● The user ● Disregard for socio-genetic security-awareness ● Identity centric security models ● Single-granularity abstractions ● Public/global mutable state
  30. 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. 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. 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. 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. 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. 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. 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. 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. 38. Security Policy
  39. 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. 40. AppArmor ● Security module (MAC) for Linux kernel. ● No MSc required for profile management. ● Simple permissive-privileges ● Restricting 'possibly vulnerable' software.
  41. 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. 42. AppArmor Bridging the gap Capabilities MinorFs $HOME
  43. 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. 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. 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. 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. 47. '..' considered evil ● Special '..' directory normally designates parent ● Capabilities: designation implies authorization ● The '..' brakes delegation of sub-trees.
  48. 48. CapFs and '..' ● /minorfs/cap/ – Dead-end stub '..' for any CapFS node – Listing returns an empty directory.
  49. 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. 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. 51. MinorFS2: performance & scalability ● AES256 encrypted overlay – Yet : sparse == sparse ● Sqlite based lookups → digest-only lookups ● Client side attenuation. ● Perl → C++
  52. 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. 53. MinorFs-2: retrofitting ● Other programs need privacy too: – Non privsep – Non ocap – Non MinorFs-aware – Cross-platform
  54. 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. 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. 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. 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. 58. Embrace delegation http://ohm2013.capibara.com/ ohm2013@capibara.com

×