diff options
author | 2020-11-18 19:55:02 +0530 | |
---|---|---|
committer | 2020-11-18 16:51:07 +0000 | |
commit | 9cc56459419f1225f5e9851825ad305424b3d6fb (patch) | |
tree | 6b761ad38074084217472fd47f23fd8c61eb3de1 /docs/2_Architecture_Guides/2.2_Security_Blueprint/5_Platform/1.2.5.7_Users.md | |
parent | c04ab11b946684902e3e39aef475a2d16c09e1c4 (diff) |
Revision of Architecture Guides
v1:
Introduction : Skeleton file of Build Process [WIP].
Security Blueprint : Multiple markdowns appended into single markdown.
v2:
Security Blueprint :
4_Kernel.md - Fixed Internal Link.
Annexes.md - Uniform markdown Title.
Bug-AGL: [SPEC-3633]
Signed-off-by: Shankho Boron Ghosh <shankhoghosh123@gmail.com>
Change-Id: I1ab478348a05464612d67f0e8a4570bda309022d
Reviewed-on: https://gerrit.automotivelinux.org/gerrit/c/AGL/documentation/+/25586
Reviewed-by: Jan-Simon Moeller <jsmoeller@linuxfoundation.org>
Tested-by: Jan-Simon Moeller <jsmoeller@linuxfoundation.org>
Diffstat (limited to 'docs/2_Architecture_Guides/2.2_Security_Blueprint/5_Platform/1.2.5.7_Users.md')
-rw-r--r-- | docs/2_Architecture_Guides/2.2_Security_Blueprint/5_Platform/1.2.5.7_Users.md | 82 |
1 files changed, 0 insertions, 82 deletions
diff --git a/docs/2_Architecture_Guides/2.2_Security_Blueprint/5_Platform/1.2.5.7_Users.md b/docs/2_Architecture_Guides/2.2_Security_Blueprint/5_Platform/1.2.5.7_Users.md deleted file mode 100644 index c1a8506..0000000 --- a/docs/2_Architecture_Guides/2.2_Security_Blueprint/5_Platform/1.2.5.7_Users.md +++ /dev/null @@ -1,82 +0,0 @@ ---- -title: Users ---- - -# 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. - -<!-- section-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. - -<!-- end-section-config --> - -Root access should not be allowed for the following utilities: - -<!-- section-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_ - -<!-- end-section-config --> - -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 - -<!-- section-todo --> - -Domain | Improvement ------------------------------ | ------------------------ -Platform-Users-Capabilities-1 | Kernel or Platform-user? -Platform-Users-Capabilities-2 | Add config note. - -<!-- end-section-todo --> - -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. |