Part 5 - Platform


This part focuses on the AGL platform including all tools and techniques used to upgrade the security and downgrade the danger. It must be possible to apply the two fundamental principles written at the very beginning of the document. First of all, security management must remain simple. You must also prohibit everything by default, and then define a set of authorization rules. As cases to deal with, we must:

  • Implement a MAC for processes and files.
  • Limit communication between applications (SystemBus and SystemD part).
  • Prohibit all tools used during development mode (Utilities and Services part).
  • Manage user capabilities (Users part).
  • Manage application permissions and policies (AGLFw part).

The tools and concepts used to meet these needs are only examples. Any other tool that meets the need can be used.

In AGL, as in many other embedded systems, different security mechanisms settle in the core layers to ensure isolation and data privacy. While the Mandatory Access Control layer (SMACK) provides global security and isolation, other mechanisms like Cynara are required to check application’s permissions at runtime. Applicative permissions (also called “privileges”) may vary depending on the user and the application being run: an application should have access to a given service only if it is run by the proper user and if the appropriate permissions are granted.

Acronyms and Abbreviations

The following table lists the terms utilized within this part of the document.

Acronyms or Abbreviations Description
ACL Access Control Lists
alsa Advanced Linux Sound Architecture
API Application Programming Interface
AppFw Application Framework
Cap Capabilities
DAC Discretionary Access Control
DDOS Distributed Denial Of Service
DOS Denial Of Service
IPC Inter-Process Communication
MAC Mandatory Access Control
PAM Pluggable Authentication Modules
SMACK Simplified Mandatory Access Control Kernel