mirror of
https://github.com/ovh/the-bastion.git
synced 2024-11-11 01:34:04 +08:00
41 lines
2 KiB
Markdown
41 lines
2 KiB
Markdown
|
# The Bastion design choices
|
||
|
|
|
||
|
|
This document aims to summarize a few design choices that have been made
|
||
|
|
on this project, that dictate how features are implemented.
|
||
|
|
|
||
|
|
## Use the well trusted and existing UNIX building blocks, don't recode them
|
||
|
|
|
||
|
|
The Bastion heavily relies on well known and trusted system blocks to work.
|
||
|
|
All the SSH part is completely handled by OpenSSH server and client programs.
|
||
|
|
The MFA mechanism also heavily relies on PAM.
|
||
|
|
|
||
|
|
## The OS as a safety net for buggy or exploitable code
|
||
|
|
|
||
|
|
A bastion functional user is always mapped to an actual operating system user.
|
||
|
|
Same goes for bastion groups: they're mapped to actual OS groups.
|
||
|
|
This is also true for group roles: gatekeeper, owner and aclkeeper roles are
|
||
|
|
mapped to system groups.
|
||
|
|
|
||
|
|
Private keys of an account are only readable by the corresponding operating
|
||
|
|
system user, and same goes for the group private keys. This way, even if the
|
||
|
|
code is tricked to allow access when it shouldn't have (flawed logic or bug),
|
||
|
|
then the OS will still deny reading the key file.
|
||
|
|
|
||
|
|
This concept has been explained in the ([https://www.ovh.com/blog/the-bastion-part-3-security-at-the-core/](Blog Post #3 - Security at the Core))
|
||
|
|
|
||
|
|
## Zero trust between portions of code running at different permission levels
|
||
|
|
|
||
|
|
Most of The Bastion code is running under the unprivileged system user
|
||
|
|
corresponding to the actual user of the bastion. When some code needs to
|
||
|
|
run with privileges, for example to be able to create an account, a first
|
||
|
|
portion of the code checks for the validity of the request first, under the
|
||
|
|
same privileges than the user, this is called `a plugin`.
|
||
|
|
To actually create the system user, `sudo` is used to run just a specific
|
||
|
|
portion of the code. Such portions of code are named `helpers`, and always
|
||
|
|
run under perl tainted mode.
|
||
|
|
|
||
|
|
Helpers communicate back their result using JSON, which is then read from
|
||
|
|
the plugin (the unprivileged portion of code), and parsed.
|
||
|
|
|
||
|
|
This concept has been explained in the ([https://www.ovh.com/blog/the-bastion-part-3-security-at-the-core/](Blog Post #3 - Security at the Core))
|