Loading policy/tpa-rfc-7-root.md 0 → 100644 +124 −0 Original line number Diff line number Diff line --- 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: 1. `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) 2. `sudo` to root: user has access to the `root` user through `sudo`, using their `sudoPassword` defined in LDAP3. 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 4. 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 5. 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. It's currently not clear how users are granted the above accesses, if that list is exhaustive, or under which condition or authority those accesses are revoked. 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. ## Access levels Members of TPA SHOULD have all access levels defined above. Service admins MAY have access to some accesses. In general, they MUST have `sudo` access to some role account to manage their own service, but they MAY be granted LIMITED `root` access (through `sudo`) only on the server(s) which host the service they are admin for. 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). 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 TODO. Brainstorm: MIA process by which users get removed after X months of inactivity? How do we grant new users access? Document interop with TPI. # Examples Examples: * dgoulet should have root access on the schleuder server (which should probably be moved out of `eugeni` beforehand, because we probably do not want to grant dgoulet root access on the main mail server) * ahf should have root access on the GitLab server, which would have helped diagnosing the [problem following the 13.5 upgrade](https://gitlab.torproject.org/tpo/tpa/team/-/issues/40074) Counter examples: * service admins MUST NOT be granted root access on all servers # Deadline No deadline set yet. # Status This proposal is currently in the `draft` state. # References See [policy/tpa-rfc-1-policy](policy/tpa-rfc-1-policy). Loading
policy/tpa-rfc-7-root.md 0 → 100644 +124 −0 Original line number Diff line number Diff line --- 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: 1. `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) 2. `sudo` to root: user has access to the `root` user through `sudo`, using their `sudoPassword` defined in LDAP3. 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 4. 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 5. 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. It's currently not clear how users are granted the above accesses, if that list is exhaustive, or under which condition or authority those accesses are revoked. 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. ## Access levels Members of TPA SHOULD have all access levels defined above. Service admins MAY have access to some accesses. In general, they MUST have `sudo` access to some role account to manage their own service, but they MAY be granted LIMITED `root` access (through `sudo`) only on the server(s) which host the service they are admin for. 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). 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 TODO. Brainstorm: MIA process by which users get removed after X months of inactivity? How do we grant new users access? Document interop with TPI. # Examples Examples: * dgoulet should have root access on the schleuder server (which should probably be moved out of `eugeni` beforehand, because we probably do not want to grant dgoulet root access on the main mail server) * ahf should have root access on the GitLab server, which would have helped diagnosing the [problem following the 13.5 upgrade](https://gitlab.torproject.org/tpo/tpa/team/-/issues/40074) Counter examples: * service admins MUST NOT be granted root access on all servers # Deadline No deadline set yet. # Status This proposal is currently in the `draft` state. # References See [policy/tpa-rfc-1-policy](policy/tpa-rfc-1-policy).
