Revision 1 as of 2011-12-31 17:42:36
|Deletions are marked like this.||Additions are marked like this.|
|Line 46:||Line 46:|
|* Flushing uploads created by `sync-source` (mostly replaced by `Archive.copyPackage`; needs [[https://answers.launchpad.net/launchpad/+question/183109|~katie user unsuspending]] so that `mass-sync` client can use it, needs `mass-sync client` finishing, and possibly [[https://bugs.launchpad.net/launchpad/+bugs?field.tag=derivation|other odds and ends of API syncs]])||* Flushing uploads created by `sync-source` (mostly replaced by `Archive.copyPackage`; needs [[https://answers.launchpad.net/launchpad/+question/183109|~katie user unsuspending]] so that `mass-sync` client can use it, needs `mass-sync` client finishing, and possibly [[https://bugs.launchpad.net/launchpad/+bugs?field.tag=derivation|other odds and ends of API syncs]])|
Launchpad Entry: foundations-q-replace-archive-admin-shell-access
Packages affected: ubuntu-archive-tools
The Ubuntu archive administration team has always required direct privileged shell access to the ftpmaster system in order to perform many of its routine tasks. This is a security problem, it prevents us from opening some tasks up to those who are not Canonical employees, and it makes it hard for us to improve our own tools. Improve the Launchpad API to handle all our requirements and write suitable API clients.
We will know we have succeeded when archive admins no longer require shell access to do their jobs.
This is not a user-facing feature.
Fixing this has been a long-term goal for many years. Specific problems caused by the current mechanism include:
- The archive administration account has a horrendous amount of privilege. While we have not spent much time coming up with specific attack vectors, an Ubuntu archive administrator could almost certainly inject malicious code into Ubuntu bypassing any of the usual auditing mechanisms, could probably forge uploads by other developers, and so on; and they have direct access to the archive signing key (though not the master key used for rollovers). While all our archive admins are highly trustworthy individuals, this means that we are constrained in how we can expand the team because their integrity has to be absolutely unquestionable, and it means that a compromise of an archive admin's local machine could have disastrous consequences if the attacker realised what they'd stumbled on. This is much more privilege than we in fact need.
- Some archive administration tasks cannot be delegated beyond Canonical staff. There are community members who would happily take some of this on if we'd let them, and who could be trusted to do so.
- It is difficult for the archive team to improve their own tools, because they are part of the Launchpad source code. While the basic database operations clearly must be in Launchpad, we could be more efficient if we could more easily build our own user interfaces. The ftpmaster tools have particularly weak UI by comparison with the rest of Launchpad because the Launchpad developers rarely if ever use them outside the test suite.
The direction for improvement is in large part obvious: the Launchpad API should be extended so that all operations currently performed by archive admins using shell access to ftpmaster have been replaced by API clients. At that point our shell access can be removed.
In fact, a substantial part of this work has been done over the years, and particularly recently as part of the derived distributions project, along with some rsync modules that allowed us to move several reporting jobs to another machine. However, there is still a good deal to do, and it seems likely that it will only ever get done if we make a specific coordinated effort to do it. This will require substantial although shallow work on Launchpad, and continued work by the Ubuntu archive admins to migrate our scripts elsewhere.
This is broken down by user. Completing everything in either of the first two categories would allow incremental reductions in archive admin privilege before the entire project is complete.
This user owns the published archive itself. Removing our access to this user and its associated group would remove our direct access to the archive signing key and much of our ability to untraceably modify the archive.
- Copying custom uploads to -updates
more-extra.* symlinks when creating new series
More NewReleaseCycleProcess stuff? (Probably mostly webops-able these days)
This user is responsible for processing incoming uploads. Removing our access to this user would remove our ability to forge uploads by other developers.
Flushing uploads created by sync-source (mostly replaced by Archive.copyPackage; needs ~katie user unsuspending so that mass-sync client can use it, needs mass-sync client finishing, and possibly other odds and ends of API syncs)
Flushing uploads created by backport-source (use backportpackage instead?)
- Write up webops procedures for upload queue inspection/reprocessing
- point-release-snapshot (could be done on a mirror, especially if we only snapshotted dists/)
- sync blacklist (should move to blacklist entries in LP proper)
- new-source (fairly easy to do on top of mass-sync client once implemented)
- override helpers: new-binary-debian-universe, new-remove-duplicates, kernel-overrides, firefox-overrides, security-kernel-overrides
- copy-report (easy to do on top of copy-package API client, though should be done in a cron job on lillypilly using a bot LP account in the ubuntu-archive team)
- publish-queue (easy to do on top of queue API client)
BoF agenda and discussion
Use this section to take notes during the BoF; if you keep it in the approved spec, use it for summarising what was discussed and note any options that were rejected.