Add proposal for new security blueprint

8 files changed, 547 insertions, 0 deletions

diff --git a/security-blueprint/part-5/0_Abstract.md b/security-blueprint/part-5/0_Abstract.md
new file mode 100644
index 0000000..4cbd17a
--- /dev/null
+++ b/security-blueprint/part-5/0_Abstract.md
@@ -0,0 +1,55 @@
+# Part 5 - Platform
+
+## Abstract
+
+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).
+
+<!-- note -->
+
+The tools and concepts used to meet these needs are only examples. Any other
+tool that meets the need can be used.
+
+<!-- endnote -->
+
+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.
+
+--------------------------------------------------------------------------------
+
+<!-- pagebreak -->
+
+## Acronyms and Abbreviations
+
+The following table lists the terms utilized within this part of the document.
+
+Acronyms or Abbreviations | Description
+------------------------- | --------------------------------------------------------------
+_ACL_                     | **A**ccess **C**ontrol **L**ists
+_alsa_                    | **A**dvanced **L**inux **S**ound **A**rchitecture
+_API_                     | **A**pplication **P**rogramming **I**nterface
+_AppFw_                   | **App**lication **F**rame**w**ork
+_Cap_                     | **Cap**abilities
+_DAC_                     | **D**iscretionary **A**ccess **C**ontrol
+_DDOS_                    | **D**istributed **D**enial **O**f **S**ervice
+_DOS_                     | **D**enial **O**f **S**ervice
+_IPC_                     | **I**nter-**P**rocess **C**ommunication
+_MAC_                     | **M**andatory **A**ccess **C**ontrol
+_PAM_                     | **P**luggable **A**uthentication **M**odules
+_SMACK_                   | **S**implified **M**andatory **A**ccess **C**ontrol **K**ernel
diff --git a/security-blueprint/part-5/1-MAC.md b/security-blueprint/part-5/1-MAC.md
new file mode 100644
index 0000000..9cfc150
--- /dev/null
+++ b/security-blueprint/part-5/1-MAC.md
@@ -0,0 +1,136 @@
+# Mandatory Access Control
+
+<!-- note -->
+
+We decided to put the **MAC** protection on the platform part despite the fact
+that it applies to the kernel too, since its use will be mainly at the platform
+level (except floor part).
+
+<!-- endnote -->
+
+**M**andatory **A**ccess **C**ontrol (**MAC**) is a protection provided by the
+Linux kernel that requires a **L**inux **S**ecurity **M**odule (**LSM**). AGL
+uses an **LSM** called **S**implified **M**andatory **A**ccess **C**ontrol
+**K**ernel (**SMACK**). This protection involves the creation of **SMACK**
+labels as part of the extended attributes **SMACK** labels to the file extended
+attributes. And a policy is also created to define the behaviour of each label.
+
+The kernel access controls is based on these labels and this policy. If there
+is no rule, no access will be granted and as a consequence, what is not
+explicitly authorized is forbidden.
+
+There are two types of **SMACK** labels:
+
+- **Execution SMACK** (Attached to the process): Defines how files are
+  _accessed_ and _created_ by that process.
+- **File Access SMACK** (Written to the extended attribute of the file): Defines
+  _which_ process can access the file.
+
+By default a process executes with its File Access **SMACK** label unless an
+Execution **SMACK** label is defined.
+
+AGL's **SMACK** scheme is based on the _Tizen 3 Q2/2015_. It divides the System
+into the following domains:
+
+- Floor.
+- System.
+- Applications, Services and User.
+
+See [AGL security framework review](http://iot.bzh/download/public/2017/AMMQ1Tokyo/AGL-security-framework-review.pdf) and [Smack White Paper](http://schaufler-ca.com/yahoo_site_admin/assets/docs/SmackWhitePaper.257153003.pdf)
+for more information.
+
+--------------------------------------------------------------------------------
+
+<!-- pagebreak -->
+
+## Floor
+
+The _floor_ domain includes the base system services and any associated data and
+libraries. This data remains unchanged at runtime. Writing to floor files or
+directories is allowed only in development mode or during software installation
+or upgrade.
+
+The following table details the _floor_ domain:
+
+Label | Name  | Execution **SMACK** | File Access **SMACK**
+----- | ----- | ------------------- | ---------------------------------------
+`-`   | Floor | `r-x` for all       | Only kernel and internal kernel thread.
+`^`   | Hat   | `---` for all       | `rx` on all domains.
+`*`   | Star  | `rwx` for all       | None
+
+<!-- note -->
+
+- The Hat label is Only for privileged system services (currently only
+  systemd-journal). Useful for backup or virus scans. No file with this label
+  should exist except in the debug log.
+
+- The Star label is used for device files or `/tmp` Access restriction managed
+  via **DAC**. Individual files remain protected by their **SMACK** label.
+
+<!-- endnote --> <!-- config -->
+
+Domain             | `Label` name | Recommendations
+------------------ | ------------ | -----------------------------------------------------------
+Kernel-MAC-Floor-1 | `^`          | Only for privileged system services.
+Kernel-MAC-Floor-2 | `*`          | Used for device files or `/tmp` Access restriction via DAC.
+
+<!-- endconfig -->
+
+--------------------------------------------------------------------------------
+
+<!-- pagebreak -->
+
+## System
+
+The _system_ domain includes a reduced set of core system services of the OS and
+any associated data. This data may change at runtime.
+
+The following table details the _system_ domain:
+
+Label            | Name      | Execution **SMACK**                             | File Access **SMACK**
+---------------- | --------- | ----------------------------------------------- | ---------------------
+`System`         | System    | None                                            | Privileged processes
+`System::Run`    | Run       | `rwxatl` for User and System label              | None
+`System::Shared` | Shared    | `rwxatl` for system domain `r-x` for User label | None
+`System::Log`    | Log       | `rwa` for System label `xa` for user label      | None
+`System::Sub`    | SubSystem | Subsystem Config files                          | SubSystem only
+
+<!-- config -->
+
+Domain              | `Label` name     | Recommendations
+------------------- | ---------------- | -------------------------------------------------------------------------------------------------------------
+Kernel-MAC-System-1 | `System`         | Process should write only to file with transmute attribute.
+Kernel-MAC-System-2 | `System::run`    | Files are created with the directory label from user and system domain (transmute) Lock is implicit with `w`.
+Kernel-MAC-System-3 | `System::Shared` | Files are created with the directory label from system domain (transmute) User domain has locked privilege.
+Kernel-MAC-System-4 | `System::Log`    | Some limitation may impose to add `w` to enable append.
+Kernel-MAC-System-5 | `System::Sub`    | Isolation of risky Subsystem.
+
+<!-- endconfig -->
+
+--------------------------------------------------------------------------------
+
+<!-- pagebreak -->
+
+## Applications, Services and User
+
+The _application_, _services_ and _user_ domain includes code that provides
+services to the system and user, as well as any associated data. All code
+running on this domain is under _Cynara_ control.
+
+The following table details the _application_, _services_ and _user_ domain:
+
+Label               | Name   | Execution **SMACK**                                                         | File Access **SMACK**
+------------------- | ------ | --------------------------------------------------------------------------- | ---------------------------
+`User::Pkg::$AppID` | AppID  | `rwx` (for files created by the App). `rx` for files installed by **AppFw** | $App runtime executing $App
+`User::Home`        | Home   | `rwx-t` from System label `r-x-l` from App                                  | None
+`User::App-Shared`  | Shared | `rwxat` from System and User domains label of $User                         | None
+
+<!-- config -->
+
+Domain              | `Label` name        | Recommendations
+------------------- | ------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------
+Kernel-MAC-System-1 | `User::Pkg::$AppID` | Only one Label is allowed per App. A data directory is created by the AppFw in `rwx` mode.
+Kernel-MAC-System-2 | `User::Home`        | AppFw needs to create a directory in `/home/$USER/App-Shared` at first launch if not present with label app-data access is `User::App-Shared` without transmute.
+Kernel-MAC-System-3 | `User::App-Shared`  | Shared space between all App running for a given user.
+
+<!-- endconfig -->
diff --git a/security-blueprint/part-5/2-SystemD.md b/security-blueprint/part-5/2-SystemD.md
new file mode 100644
index 0000000..903df11
--- /dev/null
+++ b/security-blueprint/part-5/2-SystemD.md
@@ -0,0 +1,60 @@
+# SystemD
+
+`afm-system-daemon` is used to:
+
+- Manage users and user sessions.
+- Setup applications and services (_CGroups_, _namespaces_, autostart, permissions).
+- Use of `libsystemd` for its programs (event management, **D-Bus** interface).
+
+<!-- config -->
+
+Domain             | Object         | Recommendations
+------------------ | -------------- | ------------------------------------
+Platform-SystemD-1 | Security model | Use Namespaces for containerization.
+Platform-SystemD-2 | Security model | Use CGroups to organise processes.
+
+<!-- endconfig -->
+
+See [systemd integration and user management](http://iot.bzh/download/public/2017/AMM-Dresden/AGL-systemd.pdf) for more information.
+
+## Benefits
+
+- Removal of one privileged process: **afm-user-daemon**
+- Access and use of high level features:
+
+  - Socket activation.
+  - Management of users and integration of **PAM**.
+  - Dependency resolution to services.
+  - `Cgroups` and resource control.
+  - `Namespaces` containerization.
+  - Autostart of required API.
+  - Permissions and security settings.
+  - Network management.
+
+<!-- pagebreak -->
+
+## CGroups
+
+Control Groups offer a lot of features, with the most useful ones you can
+control: Memory usage, how much CPU time is allocated, how much device I/O is
+allowed or which devices can be accessed. **SystemD** uses _CGroups_ to organise
+processes (each service is a _CGroups_, and all processes started by that
+service use that _CGroups_). By default, **SystemD** automatically creates a
+hierarchy of slice, scope and service units to provide a unified structure for
+the _CGroups_ tree. With the `systemctl` command, you can further modify this
+structure by creating custom slices. Currently, in AGL, there are 2 slices
+(**user.slice** and **system.slice**).
+
+## Namespaces
+
+### User side
+
+There are several ways of authenticating users (Key Radio Frequency, Phone,
+Gesture, ...). Each authentication provides dynamic allocation of **uids** to
+authenticated users. **Uids** is used to ensure privacy of users and **SMACK**
+for applications privacy.
+
+First, the user initiates authentication with **PAM** activation. **PAM**
+Standard offers highly configurable authentication with modular design like
+face recognition, Voice identification or with a password. Then users should
+access identity services with services and applications.
diff --git a/security-blueprint/part-5/3-SystemBus.md b/security-blueprint/part-5/3-SystemBus.md
new file mode 100644
index 0000000..2a98124
--- /dev/null
+++ b/security-blueprint/part-5/3-SystemBus.md
@@ -0,0 +1,24 @@
+# D-Bus
+
+D-Bus is a well-known **IPC** (Inter-Process Communication) protocol (and
+daemon) that helps applications to talk to each other. The use of D-Bus is great
+because it allows to implement discovery and signaling.
+
+The D-Bus session is by default addressed by environment variable
+`DBUS_SESSION_BUS_ADDRESS`. Using **systemd** variable `DBUS_SESSION_BUS_ADDRESS`
+is automatically set for user sessions. D-Bus usage is linked to permissions.
+
+D-Bus has already had several [security issues](https://www.cvedetails.com/vulnerability-list/vendor_id-13442/D-bus-Project.html)
+(mostly **DoS** issues), to allow applications to keep talking to each other.
+It is important to protect against this type of attack to keep the system more
+stable.
+
+
+<!-- config -->
+
+Domain          | Object         | Recommendations
+--------------- | -------------- | ------------------------------------
+Platform-DBus-1 | Security model | Use D-Bus as IPC.
+Platform-DBus-2 | Security model | Apply D-BUS security patches: [D-Bus CVE](https://www.cvedetails.com/vulnerability-list/vendor_id-13442/D-bus-Project.html)
+
+<!-- endconfig -->
\ No newline at end of file
diff --git a/security-blueprint/part-5/4-Services.md b/security-blueprint/part-5/4-Services.md
new file mode 100644
index 0000000..18f56ec
--- /dev/null
+++ b/security-blueprint/part-5/4-Services.md
@@ -0,0 +1,37 @@
+# System services and daemons
+
+<!-- todo -->
+
+Domain              | Improvement
+------------------- | -----------
+Platform-Services-1 | SystemD ?
+Platform-Services-2 | Secure daemon ?
+
+<!-- endtodo -->
+
+## Tools
+
+- **connman**: An internet connection manager designed to be slim and to use as
+  few resources as possible. It is a fully modular system that can be extended,
+  through plug-ins, to support all kinds of wired or wireless technologies.
+- **bluez** is a Bluetooth stack. Its goal is to program an implementation of
+  the Bluetooth wireless standards specifications. In addition to the basic stack,
+  the `bluez-utils` and `bluez-firmware` packages contain low level utilities such
+  as `dfutool` which can interrogate the Bluetooth adapter chipset in order to
+  determine whether its firmware can be upgraded.
+- **gstreamer** is a pipeline-based multimedia framework. It can be used to build
+  a system that reads files in one format, processes them, and exports them in
+  another format.
+- **alsa** is a software framework and part of the Linux kernel that provides an
+  **API** for sound card device drivers.
+
+<!-- config -->
+
+Domain               | `Tool` name | _State_
+-------------------- | ----------- | -------
+Platform-Utilities-1 | `connman`   | _Used_ as a connection manager.
+Platform-Utilities-2 | `bluez`     | _Used_ as a Bluetooth manager.
+Platform-Utilities-3 | `gstreamer` | _Used_ to manage multimedia file format.
+Platform-Utilities-4 | `alsa`      | _Used_ to provides an API for sound card device drivers.
+
+<!-- endconfig -->
diff --git a/security-blueprint/part-5/5-AppFw.md b/security-blueprint/part-5/5-AppFw.md
new file mode 100644
index 0000000..9f67b16
--- /dev/null
+++ b/security-blueprint/part-5/5-AppFw.md
@@ -0,0 +1,80 @@
+# Application framework/model (**AppFw**)
+
+The application framework manages:
+
+- The applications and services management: Installing, Uninstalling, Listing, ...
+- The life cycle of applications: Start -> (Pause, Resume) -> Stop.
+- Events and signals propagation.
+- Privileges granting and checking.
+- API for interaction with applications.
+
+<!-- note -->
+
+- The **security model** refers to the security model used to ensure security
+  and to the tools that are provided for implementing that model. It's an
+  implementation detail that should not impact the layers above the application
+  framework.
+
+- The **security model** refers to how **DAC** (Discretionary Access Control),
+  **MAC** (Mandatory Access Control) and Capabilities are used by the system to
+  ensure security and privacy. It also includes features of reporting using
+  audit features and by managing logs and alerts.
+
+<!-- endnote -->
+
+The **AppFw** uses the security model to ensure the security and the privacy of
+the applications that it manages. It must be compliant with the underlying
+security model. But it should hide it to the applications.
+
+<!-- config -->
+
+Domain                 | Object         | Recommendations
+---------------------- | -------------- | --------------------------------
+Platform-AGLFw-AppFw-1 | Security model | Use the AppFw as Security model.
+
+<!-- endconfig -->
+
+See [AGL AppFw Privileges Management](http://docs.automotivelinux.org/docs/devguides/en/dev/reference/iotbzh2016/appfw/03-AGL-AppFW-Privileges-Management.pdf) and [AGL - Application Framework Documentation](http://iot.bzh/download/public/2017/SDK/AppFw-Documentation-v3.1.pdf) for more
+information.
+
+<!-- pagebreak -->
+
+## Cynara
+
+There's a need for another mechanism responsible for checking applicative
+permissions: Currently in AGL, this task depends on a policy-checker service
+(**Cynara**).
+
+- Stores complex policies in databases.
+- "Soft" security (access is checked by the framework).
+
+Cynara interact with **D-Bus** in order to deliver this information.
+
+<!-- config -->
+
+Domain                  | Object      | Recommendations
+----------------------- | ----------- | -------------------------------------
+Platform-AGLFw-Cynara-1 | Permissions | Use Cynara as policy-checker service.
+
+<!-- endconfig -->
+
+### Policies
+
+- Policy rules:
+
+  - Are simple - for pair [application context, privilege] there is straight
+    answer (single Policy Type): [ALLOW / DENY / ...].
+  - No code is executed (no script).
+  - Can be easily cached and managed.
+
+- Application context (describes id of the user and the application credentials)
+  It is build of:
+
+  - UID of the user that runs the application.
+  - **SMACK** label of application.
+
+## Holding policies
+
+Policies are kept in buckets. Buckets are set of policies which have additional
+a property of default answer, the default answer is yielded if no policy matches
+searched key. Buckets have names which might be used in policies (for directions).
diff --git a/security-blueprint/part-5/6-Utilities.md b/security-blueprint/part-5/6-Utilities.md
new file mode 100644
index 0000000..d723c10
--- /dev/null
+++ b/security-blueprint/part-5/6-Utilities.md
@@ -0,0 +1,78 @@
+# Utilities
+
+- **busybox**: Software that provides several stripped-down Unix tools in a
+  single executable file. Of course, it will be necessary to use a "production"
+  version of **busybox** in order to avoid all the tools useful only in
+  development mode.
+
+<!-- config -->
+
+Domain               | `Tool` name | _State_
+-------------------- | ----------- | ----------------------------------------------------------------------
+Platform-Utilities-1 | `busybox`   | _Used_ to provide a number of tools. Do not compile development tools.
+
+<!-- endconfig -->
+
+## Functionalities to exclude in production mode
+
+In production mode, a number of tools must be disabled to prevent an attacker
+from finding logs for example. This is useful to limit the visible surface and
+thus complicate the fault finding process. The tools used only in development
+mode are marked by an '**agl-devel**' feature. When building in production mode,
+these tools will not be compiled.
+
+<!-- config -->
+
+Domain                | `Utility` name and normal `path`                     | _State_
+--------------------- | ---------------------------------------------------- | ----------
+Platform-Utilities-1  | `chgrp` in `/bin/chgrp`                              | _Disabled_
+Platform-Utilities-2  | `chmod` in `/bin/chmod`                              | _Disabled_
+Platform-Utilities-3  | `chown` in `/bin/chown`                              | _Disabled_
+Platform-Utilities-4  | `dmesg` in `/bin/dmesg`                              | _Disabled_
+Platform-Utilities-5  | `Dnsdomainname` in `/bin/dnsdomainname`              | _Disabled_
+Platform-Utilities-6  | `dropbear`, Remove "dropbear" from `/etc/init.d/rcs` | _Disabled_
+Platform-Utilities-7  | `Editors` in (vi) `/bin/vi`                          | _Disabled_
+Platform-Utilities-8  | `find` in `/bin/find`                                | _Disabled_
+Platform-Utilities-9  | `gdbserver` in `/bin/gdbserver`                      | _Disabled_
+Platform-Utilities-10 | `hexdump` in `/bin/hexdump`                          | _Disabled_
+Platform-Utilities-11 | `hostname` in `/bin/hostname`                        | _Disabled_
+Platform-Utilities-12 | `install` in `/bin/install`                          | _Disabled_
+Platform-Utilities-13 | `iostat` in `/bin/iostat`                            | _Disabled_
+Platform-Utilities-14 | `killall` in `/bin/killall`                          | _Disabled_
+Platform-Utilities-15 | `klogd` in `/sbin/klogd`                             | _Disabled_
+Platform-Utilities-16 | `logger` in `/bin/logger`                            | _Disabled_
+Platform-Utilities-17 | `lsmod` in `/sbin/lsmod`                             | _Disabled_
+Platform-Utilities-18 | `pmap` in `/bin/pmap`                                | _Disabled_
+Platform-Utilities-19 | `ps` in `/bin/ps`                                    | _Disabled_
+Platform-Utilities-20 | `ps` in `/bin/ps`                                    | _Disabled_
+Platform-Utilities-21 | `rpm` in `/bin/rpm`                                  | _Disabled_
+Platform-Utilities-22 | `SSH`                                                | _Disabled_
+Platform-Utilities-23 | `stbhotplug` in `/sbin/stbhotplug`                   | _Disabled_
+Platform-Utilities-24 | `strace` in `/bin/trace`                             | _Disabled_
+Platform-Utilities-25 | `su` in `/bin/su`                                    | _Disabled_
+Platform-Utilities-26 | `syslogd` in (logger) `/bin/logger`                  | _Disabled_
+Platform-Utilities-27 | `top` in `/bin/top`                                  | _Disabled_
+Platform-Utilities-28 | `UART` in `/proc/tty/driver/`                        | _Disabled_
+Platform-Utilities-29 | `which` in `/bin/which`                              | _Disabled_
+Platform-Utilities-30 | `who` and `whoami` in `/bin/whoami`                  | _Disabled_
+Platform-Utilities-31 | `awk` (busybox)                                      | _Enabled_
+Platform-Utilities-32 | `cut` (busybox)                                      | _Enabled_
+Platform-Utilities-33 | `df` (busybox)                                       | _Enabled_
+Platform-Utilities-34 | `echo` (busybox)                                     | _Enabled_
+Platform-Utilities-35 | `fdisk` (busybox)                                    | _Enabled_
+Platform-Utilities-36 | `grep` (busybox)                                     | _Enabled_
+Platform-Utilities-37 | `mkdir` (busybox)                                    | _Enabled_
+Platform-Utilities-38 | `mount` (vfat) (busybox)                             | _Enabled_
+Platform-Utilities-39 | `printf` (busybox)                                   | _Enabled_
+Platform-Utilities-40 | `sed` in `/bin/sed` (busybox)                        | _Enabled_
+Platform-Utilities-41 | `tail` (busybox)                                     | _Enabled_
+Platform-Utilities-42 | `tee` (busybox)                                      | _Enabled_
+Platform-Utilities-43 | `test` (busybox)                                     | _Enabled_
+
+<!-- endconfig --> <!-- note -->
+
+The _Enabled_ Unix/Linux utilities above shall be permitted as they are often
+used in the start-up scripts and for USB logging. If any of these utilities are
+not required by the device then those should be removed.
+
+<!-- endnote -->
diff --git a/security-blueprint/part-5/7-Users.md b/security-blueprint/part-5/7-Users.md
new file mode 100644
index 0000000..9fc7a65
--- /dev/null
+++ b/security-blueprint/part-5/7-Users.md
@@ -0,0 +1,77 @@
+# Users
+
+The user policy can group users by function within the car. For example, we can
+consider a driver and his passengers. Each user is assigned to a single group to
+simplify the management of space security.
+
+## Root Access
+
+The main applications, those that provide the principal functionality of the
+embedded device, should not execute with root identity or any capability.
+
+If the main application is allowed to execute at any capability, then the entire
+system is at the mercy of the said application's good behaviour. Problems arise
+when an application is compromised and able to execute commands which could
+consistently and persistently compromise the system by implanting rogue
+applications.
+
+It is suggested that the middleware and the UI should run in a context on a user
+with no capability and all persistent resources should be maintained without any
+capability.
+
+One way to ensure this is by implementing a server-client paradigm. Services
+provided by the system's drivers can be shared this way. The other advantage of
+this approach is that multiple applications can share the same resources at the
+same time.
+
+<!-- config -->
+
+Domain                | Object           | Recommendations
+--------------------- | ---------------- | -----------------------------------------------------
+Platform-Users-root-1 | Main application | Should not execute as root.
+Platform-Users-root-2 | UI               | Should run in a context on a user with no capability.
+
+<!-- endconfig -->
+
+Root access should not be allowed for the following utilities:
+
+<!-- config -->
+
+Domain                | `Utility` name | _State_
+--------------------- | -------------- | -------------
+Platform-Users-root-3 | `login`        | _Not allowed_
+Platform-Users-root-4 | `su`           | _Not allowed_
+Platform-Users-root-5 | `ssh`          | _Not allowed_
+Platform-Users-root-6 | `scp`          | _Not allowed_
+Platform-Users-root-7 | `sftp`         | _Not allowed_
+
+<!-- endconfig -->
+
+Root access should not be allowed for the console device. The development
+environment should allow users to login with pre-created user accounts.
+
+Switching to elevated privileges shall be allowed in the development environment
+via `sudo`.
+
+--------------------------------------------------------------------------------
+
+<!-- pagebreak -->
+
+## Capabilities
+
+<!-- todo -->
+
+Domain                        | Improvement
+----------------------------- | ------------------------
+Platform-Users-Capabilities-1 | Kernel or Platform-user?
+Platform-Users-Capabilities-2 | Add config note.
+
+<!-- endtodo -->
+
+The goal is to restrict functionality that will not be useful in **AGL**. They
+are integrated into the **LSM**. Each privileged transaction is associated with
+a capability. These capabilities are divided into three groups:
+
+- e: Effective: This means the capability is “activated”.
+- p: Permitted: This means the capability can be used/is allowed.
+- i: Inherited: The capability is kept by child/subprocesses upon execve() for example.