Maemo Platform Security Fosdem


Published on

Here is a presentation about Maemo 6 Platfrom Security, which was given during FOSDEM 2010 event.

  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Maemo Platform Security Fosdem

  1. 1. Maemo 6 Platform Security Overview Elena Reshetova 1
  2. 2. Outline • What is Platform Security? • Maemo 6 Device modes & Boot process • Access Control • Our criteria • Basic principles & concepts • Aegis Security Policy & SW distribution • Installation and Run-time views • Shared libraries case • Integrity Protection • Aegis Validator • Aegis Protected Storage • IPC Security 2 E.Reshetova FOSDEM 6.02.2010
  3. 3. What is Platform Security? • Set of a mechanisms and techniques, which are used to protect the entire SW platform 3 E.Reshetova FOSDEM 6.02.2010
  4. 4. Device modes • Open source strategy • Bigger developer offering • The same functionality as earlier • Optional copy protection (DRM) • Compile and flash your own kernel • More use cases for a device usage • Made a low-level platform • Games, Commercial applications development • More business models • Ovi Store • Comes with Music 4 E.Reshetova FOSDEM 6.02.2010
  5. 5. Hardware enablers & Boot process • Trusted Execution Environment (TrEE) (for instance ARM Trust Zone) with two main keys: • Root public key Restrict security • Root device specific key functionality * includes: • DRM keys are disabled • Content from the previous mode can’t be decrypted Integrity isn’t OK 5 E.Reshetova FOSDEM 6.02.2010
  6. 6. Access Control 6
  7. 7. Access control in Linux • Classical Unix AC • Based on multiuser model • Discretionary AC • POSIX capabilities aren’t really in use (root has all, others none) • Our criteria: • Process level mandatory access control needed • Minimal changes to the current model (enforcement phase) • Good level of flexibility and granularity, easy to understand concept (KISS) • Existing security extensions, no good match to criteria • FreeBSD AC, MLS, Biba, SELinux, RBAC, AppArmor, TOMOYO Linux, … • Our approach: • Apply, and minimally extend Classical Unix AC to meet set criteria • Re-use multiuser-model for application-level access control • Architecture outlined in the next slides. 7 E.Reshetova FOSDEM 6.02.2010
  8. 8. Access Control – Principles & Concepts • Principle of least privileges • Every application should be able to access only limited set of needed resources • Protected resources • Things like Cellular functionality, Location information and so on • No final list yet – work in progress • Resource token • Abstract name describing a protected resource • Cellular, Location, and etc. • Application must declare resources, it needs • Aegis Manifest File • No security APIs by default  Development is almost unchanged 8 E.Reshetova FOSDEM 6.02.2010
  9. 9. Aegis Manifest File • An optional xml file inside Debian package • Declares needed and provided credentials • Resource tokens • UIDs, GUIs • POSIX capabilities • Should be generated automatically by SDK based on the source code • A D-Bus policy can be generated from Aegis Manifest during installation phase • May contain a package signature • Used for authorized security policy updates • Application Identifier AppID = {SWSourceID, PackageName, AppName} 9 E.Reshetova FOSDEM 6.02.2010
  10. 10. Software Distribution • SW comes inside Debian packages • Each package has SW source (known or unknown) • SW repository (based on the repository signing) • Any virtual entity (based on the package signing) as single developer, web page and etc. • Each known SW source has a asymmetric key pair • Public key is known to a device • Private key is used to sign the packages • Each SW source is assigned a trust level • Update of SW package is possible only from the same SW source or from a SW source with higher trust level • SW source trust is based on the Quality Assurance level of the SW source 10 E.Reshetova FOSDEM 6.02.2010
  11. 11. Aegis Security Policy • Contains mapping between SW sources and allowed credentials • Accessible only to Installer • Allows to create different security levels on the devices • The allowed credential set for each SW source is based on the risk level • Can be updated via authorized policy updates • Special domains: • Unknown • Developer 11 E.Reshetova FOSDEM 6.02.2010
  12. 12. Components Interaction – Installation time Aegis Application 1. Application arrives to the Manifest Aegis Installer together 1. with Aegis Manifest 2. Aegis installer checks the Aegis Aegis Security policy for the D-Bus D-Bus Daemon Security policy Installer information policy D-Bus extensions 3. Aegis installer modifies User mode the Credentials’ possession 3. list according to the “Intersection rule” Kernel mode [4.] Aegis installer possibly modifies D-Bus policy Credentials’ Possession list 12 E.Reshetova FOSDEM 6.02.2010
  13. 13. Intersection rule Example SW source Aegis Manifest credentials set: credentials set: What credentials intersection application can What application get, if it is certified wants to access? by this SW source? Result credentials set: What credentials application has during run-time? 13 E.Reshetova FOSDEM 6.02.2010
  14. 14. Components Interaction – Run-time 1. Process Credentials Assigner gets the Aegis Application allowed credentials set from the Manifest Credentials’ possession list 2. Process Credentials Assigner modifies process’ credentials (process task structure) according to Aegis D-Bus Daemon Security the received credentials D-Bus policy Installer policy D-Bus 3a. File AC extensions • No changes User mode 3b. D-Bus • Additional process credentials are taken into consideration by the d- Kernel mode Process bus daemon File’s AC lists credentials 3c. Application by itself Credentials’ Possession • Application calls libcreds library to list “Linux Kernel get process credentials, and makes a Reference monitor” decision based on its own policy Process Credentials assigner 14 E.Reshetova FOSDEM 6.02.2010
  15. 15. Loading the shared libraries No! Yes Cellular, UserData Application OK Call Library A 15 E.Reshetova FOSDEM 6.02.2010
  16. 16. Integrity Protection 16
  17. 17. Integrity protection – Aegis Validator • Ensures integrity of the executable components (binaries, libraries, ...) Yes • Run-time • Against Offline attacks • Kernel module Storage of • Calculates a cryptographic Aegis reference hash of the file (currently Validator hashes No! SHA-1) • Reference hashes Get the policy • Stored in the Aegis Protected Storage • Come inside of the package or can be computed during installation time 17 E.Reshetova FOSDEM 6.02.2010
  18. 18. Privacy Protection - Aegis Protected Storage • Ensures integrity of data and configuration files after installation Place the files Integrity Check Application into status Protected • Additional features: integrity Storage • Data encryption inside the storage • Private, shared and global or Data file externally signed storages Aegis Protected • Interface to TrEE, which is used Configuration Storage APIs to sign/verify, encrypt/decrypt file the data • Access to a protected storage is defined by an application identifier or application group 18 E.Reshetova FOSDEM 6.02.2010
  19. 19. Secure IPC 19
  20. 20. Secure IPC inside device • Maemo Crypt API • Ensures integrity and confidentially of the transmitted data • Signing • Encryption • No key management from applications • Different levels • Based on application ID • Based on the resource token Check the signature 20 E.Reshetova FOSDEM 6.02.2010
  21. 21. Conclusions & QA • Most of the Security FW will be open sourced • Public project “Maemo 6 Platform Security” • • Your questions, feedback and reports are welcomed! • • • • More details will still follow… Thank you! 21 E.Reshetova FOSDEM 6.02.2010