mirror of
https://github.com/ovh/the-bastion.git
synced 2024-12-29 11:41:27 +08:00
61 lines
3.1 KiB
ReStructuredText
61 lines
3.1 KiB
ReStructuredText
========
|
|
Security
|
|
========
|
|
|
|
Security principles at the core
|
|
===============================
|
|
|
|
Even with the most conservative, precautionous and paranoid coding process, code has bugs,
|
|
so it shouldn't be trusted blindly. Hence the bastion doesn't trust its own code.
|
|
It leverages the operating system security primitives to get additional security, as seen below.
|
|
|
|
- Uses the well-known and trusted UNIX Discretionary Access Control:
|
|
|
|
- Bastion users are mapped to actual system users
|
|
- Bastion groups are mapped to actual system groups
|
|
- All the code is constantly checking rights before allowing any action
|
|
- UNIX DAC is used as a safety belt to prevent an action from succeeding even if the code
|
|
is tricked into allowing it
|
|
|
|
- The bastion main script is declared as the bastion user's system shell:
|
|
|
|
- No user has real (``bash``-like) shell access on the system
|
|
- All code is ran under the unprivileged user's system account rights
|
|
- Even if a user could escape to a real shell, they wouldn't be able to connect to machines they don't have
|
|
access to, because they don't have filesystem-level read access to the SSH keys
|
|
|
|
- The code is modular
|
|
|
|
- The main code mainly checks rights, logs actions, and enable ``ssh`` access to other machines
|
|
- All side commands, called **plugins**, are in modules separated from the main code
|
|
- The modules can either be **open** or **restricted**
|
|
|
|
- Only accounts that have been specifically granted on a need-to-use basis can run a specific restricted plugin
|
|
- This is checked by the code, and also enforced by UNIX DAC (the plugin is only readable and
|
|
executable by the system group specific to the plugin)
|
|
|
|
- All the code needing extended system privileges is separated from the main code, in modules called **helpers**
|
|
|
|
- Helpers are run exclusively under ``sudo``
|
|
- The ``sudoers`` configuration is attached to a system group specific to the command,
|
|
which is granted to accounts on a need-to-use basis
|
|
- The helpers are only readable and executable by the system group specific to the command
|
|
- The helpers path and some of their immutable parameters are hardcoded in the ``sudoers`` configuration
|
|
- Perl tainted mode (``-T``) is used for all code running under ``sudo``, preventing any user-input to
|
|
interfere with the logic, by halting execution immediately
|
|
- Code running under ``sudo`` doesn't trust its caller and re-checks every input
|
|
- Communication between unprivileged and privileged-code are done using JSON
|
|
|
|
Auditability
|
|
============
|
|
|
|
- Bastion administrators must use the bastion's logic to connect to itself to administer it (or better,
|
|
use another bastion to do so), this ensures auditability in all cases
|
|
|
|
- Every access and action (whether allowed or denied) is logged with:
|
|
|
|
- ``syslog``, which should also be sent to a remote syslog server to ensure even
|
|
bastion administrators can't tamper their tracks, and/or
|
|
- local ``sqlite3`` databases for easy searching
|
|
|
|
- This code is used in production in several PCI-DSS, ISO 27001, SOC1 and SOC2 certified environments
|