Document security practices for multi-user systems

[pnorman]

The normal osm2pgsql instructions (createdb && psql -c 'create extension postgis; && osm2pgsql) are designed for a single-user accessing a database and everyone who has access to that user is trusted. In multi-user environments and production, it's a good idea to restrict access to the minimum necessary.

The doc should cover

• search_path, schemas, and protecting against CVE-2018-1058-like attacks
• Creating a user with the permissions needed to import OSM data
• Creating a user with the permissions needed to use OSM data (e.g. rendering)

[pnorman]

I've been evaluating osm2pgsql for CVE-2018-1058-like search_path privilege escalation attacks. It's doing the following function call without a schema qualification

• PostGIS calls This is an attack vector, except that the PostGIS functions have to have been created by a superuser. An owner of the DB could create a function in it with higher precedence than the PostGIS function, so osm2pgsql should never be run as superuser on a multi-user system.

• %1%_osm2pgsql_valid trigger This is a potential attack vector, but I believe because we just created the function the same transaction it's fine.

• calls to COUNT(*) throughout the tests I think these should be pg_catalog.COUNT, and the tests need to be run as a superuser. On the other hand, osm2pgsql itself creates the databases, so I don't believe there is an attack vector.

For an attack to work you need

• an attacker who can create functions in the DB (required for the search_path attacks to work). This requires CREATE on the schema osm2pgsql is using

• osm2pgsql running with permissions higher than the attacker (required for the attack to escalate privileges)

The only scenarios I can see are

• osm2pgsql is run as a superuser
• osm2pgsql has CREATE on the db and the attacker has CREATE on the schema osm2pgsql will use, but not the db

In practice, in every scenario I've seen, osm2pgsql imports run with the highest non-superuser level of access, because they have to DROP and CREATE tables.

[mmd-osm]

The official Postgresql wiki page describes a number of safeguarding measures to protect a PostgreSQL installation from CVE-2018-1058.

Did you also evaluate if those recommendations are safe to apply in the context of osm2pgsql, or whether they would cause some issues? Would you recommend applying those recommendations?

[pnorman]

Did you also evaluate if those recommendations are safe to apply in the context of osm2pgsql, or whether they would cause some issues?

It's often assumed that osm2pgsql will be run on the public schema, and that that's where PostGIS will be. Any of the techniques will work, but REVOKE CREATE ON SCHEMA public FROM PUBLIC; would be my preference, but then you also need to adjust the search_path to put the osm2pgsql tables somewhere else. PostGIS could remain in public.

From a practical consideration, people running osm2pgsql and their renderer as superusers is a far bigger security hole than the search_path privilege escalation attacks. I see the former done all the time, and once you have superuser access, there's no more escalation to be done with database permissions.

[joto]

I have written up a chapter security considerations in the new manual. I believe this is enough for us here and I can't really give much more information there without writing a "postgresql security handbook" or confusing users more than helping.