tpa-rfc-7-root.md



title: TPA-RFC-7: root access


Summary: who should get administrator privileges, where, how and when?
How do those get revoked?

Background
Administrator privileges on TPO servers is reserved to a small group,
currently the "members of TPA", a loose group of sysadmins with no
clearly defined admission or exit rules.
There are multiple possible access levels, often conflated:


root on servers: user has access to the root user on some or
all UNIX servers, either because they know the password, or have
their SSH keys authorized to the root user (through Puppet, in the
profile::admins::keys Hiera field)

sudo to root: user has access to the root user through sudo,
using their sudoPassword defined in LDAP. Puppet access: by
virtue of being able to push to the Puppet git repository, an
admin necessarily gets root access everywhere, because Puppet
runs as root everywhere
LDAP admin: a user member of the adm group in LDAP also gets
access everywhere through sudo, but also through being able to
impersonate or modify other users in LDAP (although that requires
shell access to the LDAP server, which normally requires root)
password manager access: a user's OpenPGP encryption key is added
to the tor-passwords.git repository, which grants access to
various administrative sites, root passwords and cryptographic
keys

This approach is currently all-or-nothing: either a user has access to
all of the above, or nothing. That list might not be exhaustive. It
certainly does not include the service admin access level.
The current list of known administrators is:

anarcat
arma (not in root's authorized keys)
hiro
linus
qbi (not in root's authorized keys)
weasel

Unless otherwise mentioned, those users have all the access mentioned
above.
Another issue that currently happens is the problems service admins
(which do not have root access) have in managing some services. In
particular, Schleuder and GitLab service admins have had trouble
debugging problems with their service because they do not have the
necessary access levels to restart their service, edit configuration
file or install packages.

Proposal
This proposal aims at clarifying the current policy, but also
introduces an exception for service admins to be able to become root
on the servers they manage (and only those). It also tries to define a
security policy for access tokens, as well as admission and revocation
policies.
In general, the spirit of the proposal is to bring more flexibility
with what changes we allow on servers to the TPA team. We want to help
teams host their servers with us but that also comes with the
understanding that we need the capacity (in terms of staff and
hardware resources) to do so as well.

Scope
This policy complements the Tor Core Membership policy but
concerns only membership to the TPA team and access to servers.

Access levels
Members of TPA SHOULD have all access levels defined above.
Service admins MAY have some access to some servers. In general, they
MUST have sudo access to a role account to manage their own
service. They MAY be granted LIMITED root access (through sudo)
only on the server(s) which host their service, but this should be
granted only if there are no other technical way to implement the
service.
In general, service admins SHOULD use their root access in
"read-only" mode for debugging, as much as possible. Any "write"
changes MUST be documented, either in a ticket or in an email to the
TPA team (if the ticket system is down). Common problems and their
resolutions SHOULD be documented in the service documentation
page.
Service admins are responsible for any breakage they cause to systems
while they use elevated privileges.

Token security
Extreme care should be taken with private keys: authentication keys
(like SSH keys or OpenPGP encryption keys) MUST be password-protected
and ideally SHOULD reside on hardware tokens, or at least SHOULD be
stored offline.

Admission and revocation
Service admins and system administrators are granted access through a
vetting process by which an existing administrator requests access for
the new administrator. This is currently done by opening a ticket in
the issue tracker with an OpenPGP-signed message, but that is
considered an implementation detail as far as this procedure is
concerned.
A service admin or system administrator MUST be part of the "Core
team" as defined by the Tor Core Membership policy to keep their
privileges.
Access revocation should follow the termination procedures in the Tor
Core Membership policy, which, at the time of writing, establish
three methods for ending the membership:

voluntary: members can resign by sending an email to the team
inactivity: members accesses can be revoked after 6 months of
inactivity, after consent from the member or a decision of the
community team
involuntary: a member can be expelled following a decision of the
community team and membership status can be temporarily revoked in
the case of a serious problem while the community team makes a
decision


Examples

ahf should have root access on the GitLab server, which would have
helped diagnosing the problem following the 13.5 upgrade

the onionperf services were setup outside of TPA because they
required custom iptables rules, which wasn't allowed before but
would be allowed under this policy: TPA would deploy the requested
rule or, if they were dynamic, allow write access to the
configuration somehow


Counter examples

service admins MUST NOT be granted root access on all servers
dgoulet should have root access on the Schleuder server but cannot
have it right now because Schleuder is on a server that also hosts
the main email and mailing lists services
service admins do not need root access to the monitoring server to
have their services monitored: they can ask TPA to setup a scrape
or we can configure a server which would allow collaboration on the
monitoring configuration (issue 40089)


Deadline
This proposal will be adopted on December 7th 2020, unless there are
objections.

Status
This proposal is currently in the draft state.