We need an admin interface & API for provisioning ASes (SPEC-114)

[matrixbot]

(Imported from https://matrix.org/jira/browse/SPEC-114)

(Reported by @ara4n)

[matrixbot]

Jira watchers: @Kegsay @ara4n

[matrixbot]

We could expose some admin functions if the server admin bit is flipped in the database for that user, but I'm wary about making it too easy to provision ASes given they have read access to the entire home server... I would prefer a script or something which would do the insert, rather than allowing remote provisioning.

-- @Kegsay

[matrixbot]

After this, we sprouted a register API... which was then removed after SPEC-130 because it was considered too dangerous for abuse.

However, we've now gone full circle, and it feels pretty clunky to provision ASes - they have to generate chunks of config files which have to be kept in sync with their own config, and the HS has to be restarted to pick up the config changes.

Perhaps a better compromise would be to add AS provisioning explicitly to an admin API, which is locked to localhost and needs an HS-admin-specific password to be provided to do anything. The resulting security model isn't much worse than requiring users to have permission to write to the HS config file and restart the server, but much better suited to automation purposes such as autoprovisioning ASes, and would avoid the mess of having to maintain two separate config files (the AS's config and the HS's registration config).

-- @ara4n

[turt2live]

For other adventurers: SPEC-130 does not appear to be archived anywhere, and was probably closed before the Github migration, and therefore wasn't migrated :(

Presumably it has something to do with the lack of authorization rules, given the context.

[richvdh]

SPEC-130 said:

AS registration should require a human in the loop

+Attack vector+: A compromised Application Service could register a regex for .*, obtaining all the events from the home server. +Impact:+ Unexpected privacy breaches. +Recommendation:+ We still want to support genuine ASes which need a global regex like .\* to do things like searching and logging. The key thing we're trying to fix here is the unexpectedness. We want the home server admin to be aware that the AS can effectively get root on the server. To enforce this, the /register API will be deprecated and removed, and the registration of ASes will be entirely based on homeserver.yaml. We considered adding this to the database instead (similar to how you have to insert the token into the database currently), but deemed that this would be better in the config as the database is really just storing state, of which this is not.

[This was in the context of an API which allowed ASes to register themselves over HTTP]

[non-Jedi]

Isn't this issue effectively closed now then?

[turt2live]

No, it's not been solved yet. The proposal is still in review.

[azmeuk]

For the record MSC4098 suggests the use of SCIM as provisioning protocol.