- Release Signoff Checklist
- Summary
- Motivation
- Proposal
- Design Details
- Drawbacks
- Alternatives
- Infrastructure Needed (optional)
- Enhancement issue in release milestone, which links to pull request in [keylime/enhancements]
- Core members have approved the issue with the label
implementable - Design details are appropriately documented
- Test plan is in place
- User-facing documentation has been created in [keylime/keylime-docs]
Currently, Keylime runs as the root user, providing it essentially all control over a host on which Keylime runs. This enhancement suggests changing this to running Keylime (specifically, its different components) under a dedicated user account to limit the level of damage that could happen should a vulnerability in Keylime be exploited.
We will analyse Keylime Verifier, Keylime Registrar and Keylime Agent to decide
which do not need root access to run properly, and then make necessary changes
to run them under their own dedicated user, keylime.
Running everything as root is bad practice: any piece of software may have a vulnerability, and if a bug in a piece of software running as root is exploited, the negative consequences to the host system can be dramatic, essentially allowing the malicious party exploiting the bug to have full control over the system (There are some exceptions to this, which we will not consider specifically here as they are system-dependent, such as running software in TEEs)).
A simple and well-known defense against this is privilege separation, specifically the least privileged model, where each piece of software is given the rights necessary to run properly, but no more. As such, we want to make sure that, in as many cases as possible, Keylime components do not run as the root user but as a specific user, whose rights on a host are more specifically scoped out, minimising the risk of damage should an exploitable vulnerability be found in Keylime.
The goals of the enhancement is to move as many components of Keylime as
possible from running as the root user to running as a dedicated user, called
keylime.
This enhancement does not aim to solve the problem of Keylime dependencies running as root, such as tpm2-tools.
In practice, this enhancement will happen in stages.
First, evaluate the different Keylime components to see which ones are being run as the root user by convenience, and which ones may genuinely need to do so to be able to operate properly.
Once this is done, we will look at the best option to run each of these components under the Keylime user. This may be as simple as modifying the systemd unit file to specify a user under which to run Keylime.
Other files that will need to be modified to take this change into account are
installer.sh, run_tests.sh as well as the Ansible role for Keylime. There
may be some work to do on the SElinux labels too.
Finally, the documentation will have to be updated as well.
As a system administrator in an organisation with strong security rules regarding the software that may be run, and how, i would like to use Keylime for the benefits it provides, but cannot as only a very limited subset of software from a pre-approved list is allowed to run as root on the organisation's hosts, and Keylime is not one of them.
Now that Keylime uses its own dedicated user account, this aligns Keylime with my organisation's policy and i can deploy Keylime.
TBD
TBD
TBD
TBD
TBD
It makes the overall design of Keylime a bit more complicated. However, we believe that benefits provided by improving privilege separation vastly outweigh this drawback.
Privilege separation (and more generally, defense in depth) can be done at
various levels, however at the level we are discussing here (users on a
UNIX-based system) there are no alternatives to my knowledge.
Mandatory Access Control (MAC) systems, such as SElinux, are complementary
rather than alternatives to user privilege separation.
N/A