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_spt@mail.mil
