Hi hackers, More or less by chance, I stumbled on a Security Technical Implementation Guide (STIG, promulgated by the US Dept. of Defense, Defense Information Systems Agency) for PostgreSQL (specific to PG 9.x, so a bit dated).
There is a rule in the STIG that pertains to PLs, and seems to get backwards the meaning of 'trusted'/'untrusted' for those: However, the use of procedural languages within PostgreSQL, such as pl/R and pl/Python, introduce security risk. Any user on the PostgreSQL who is granted access to pl/R or pl/Python is able to run UDFs to escalate privileges and perform unintended functions. Procedural languages such as pl/Perl and pl/Java have "untrusted" mode of operation, which do not allow a non-privileged PostgreSQL user to escalate privileges or perform actions as a database administrator. Naturally, that should refer to the "trusted" mode of operation as the one with measures to prevent escalation. There doesn't seem to be much substantively wrong with the rule, as long as one reads 'trusted' for 'untrusted'. Not being sure that the doc I had stumbled on was a latest edition, I found four PostgreSQL-related current STIGs published at [0]: [1] Crunchy Data PostgreSQL STIG - Ver 2, Rel 2 [2] EDB Postgres Advanced Server STIG [3] EDB Postgres Advanced Server v11 for Windows STIG - Ver 2, Rel 3 [4] PostgreSQL 9.x STIG - Ver 2, Rel 4 The problem usage of 'untrusted' for 'trusted' is present in both [1] and [4]. There is no corresponding rule in [2] at all, so the issue does not arise there. In [3], interestingly, the corresponding rule has a much more extended discussion that uses 'trusted' / 'untrusted' correctly, includes snippets of SQL to query for routines of interest, and so on. It does seem to have a minor problem of its own, though: it advises querying for roles that might be granted USAGE on an untrusted PL. AFAICS, one isn't even allowed to GRANT USAGE on an untrusted PL, and that's been so all the way back to 7.3. The four STIGs suggest the same email address [5] for comments or proposed revisions. I could send these comments there myself, but I thought it likely that others in the community have already been involved in the development of those documents and might have better connections. Regards, -Chap [0] https://public.cyber.mil/stigs/downloads/ [1] https://dl.dod.cyber.mil/wp-content/uploads/stigs/zip/U_CD_PGSQL_V2R2_STIG.zip [2] https://dl.dod.cyber.mil/wp-content/uploads/stigs/zip/U_EPAS_V1R1_STIG.zip [3] https://dl.dod.cyber.mil/wp-content/uploads/stigs/zip/U_EDB_PGS_Advanced_Server_v11_Windows_V2R3_STIG.zip [4] https://dl.dod.cyber.mil/wp-content/uploads/stigs/zip/U_PGS_SQL_9-x_V2R4_STIG.zip [5] mailto:disa.stig_...@mail.mil
