docs/1_Architecture_Guides/1.2_Security_Blueprint/5_Platform/1.2.5.7_Users.md

   1 ---
   2 edit_link: ''
   3 title: Users
   4 origin_url: >-
   5   https://raw.githubusercontent.com/automotive-grade-linux/docs-sources/master/docs/security-blueprint/part-5/7-Users.md
   6 ---
   7
   8 <!-- WARNING: This file is generated by fetch_docs.js using /home/boron/Documents/AGL/docs-webtemplate/site/_data/tocs/architecture/master/security_blueprint-security-blueprint-book.yml -->
   9
  10 # Users
  11
  12 The user policy can group users by function within the car. For example, we can
  13 consider a driver and his passengers. Each user is assigned to a single group to
  14 simplify the management of space security.
  15
  16 ## Root Access
  17
  18 The main applications, those that provide the principal functionality of the
  19 embedded device, should not execute with root identity or any capability.
  20
  21 If the main application is allowed to execute at any capability, then the entire
  22 system is at the mercy of the said application's good behaviour. Problems arise
  23 when an application is compromised and able to execute commands which could
  24 consistently and persistently compromise the system by implanting rogue
  25 applications.
  26
  27 It is suggested that the middleware and the UI should run in a context on a user
  28 with no capability and all persistent resources should be maintained without any
  29 capability.
  30
  31 One way to ensure this is by implementing a server-client paradigm. Services
  32 provided by the system's drivers can be shared this way. The other advantage of
  33 this approach is that multiple applications can share the same resources at the
  34 same time.
  35
  36 <!-- section-config -->
  37
  38 Domain                | Object           | Recommendations
  39 --------------------- | ---------------- | -----------------------------------------------------
  40 Platform-Users-root-1 | Main application | Should not execute as root.
  41 Platform-Users-root-2 | UI               | Should run in a context on a user with no capability.
  42
  43 <!-- end-section-config -->
  44
  45 Root access should not be allowed for the following utilities:
  46
  47 <!-- section-config -->
  48
  49 Domain                | `Utility` name | _State_
  50 --------------------- | -------------- | -------------
  51 Platform-Users-root-3 | `login`        | _Not allowed_
  52 Platform-Users-root-4 | `su`           | _Not allowed_
  53 Platform-Users-root-5 | `ssh`          | _Not allowed_
  54 Platform-Users-root-6 | `scp`          | _Not allowed_
  55 Platform-Users-root-7 | `sftp`         | _Not allowed_
  56
  57 <!-- end-section-config -->
  58
  59 Root access should not be allowed for the console device. The development
  60 environment should allow users to login with pre-created user accounts.
  61
  62 Switching to elevated privileges shall be allowed in the development environment
  63 via `sudo`.
  64
  65 --------------------------------------------------------------------------------
  66
  67 <!-- pagebreak -->
  68
  69 ## Capabilities
  70
  71 <!-- section-todo -->
  72
  73 Domain                        | Improvement
  74 ----------------------------- | ------------------------
  75 Platform-Users-Capabilities-1 | Kernel or Platform-user?
  76 Platform-Users-Capabilities-2 | Add config note.
  77
  78 <!-- end-section-todo -->
  79
  80 The goal is to restrict functionality that will not be useful in **AGL**. They
  81 are integrated into the **LSM**. Each privileged transaction is associated with
  82 a capability. These capabilities are divided into three groups:
  83
  84 - e: Effective: This means the capability is “activated”.
  85 - p: Permitted: This means the capability can be used/is allowed.
  86 - i: Inherited: The capability is kept by child/subprocesses upon execve() for example.