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|
|DAC||Discretionary Access Control|
|DDOS||Distributed Denial Of Service|
|DOS||Denial Of Service|
|MAC||Mandatory Access Control|
|PAM||Pluggable Authentication Modules|
|SMACK||Simplified Mandatory Access Control Kernel|