At Sun, 8 Mar 2020 11:55:06 +0900, Masahiko Sawada <masahiko.saw...@2ndquadrant.com> wrote in > On Thu, 5 Mar 2020 at 18:39, Kyotaro Horiguchi <horikyota....@gmail.com> > wrote: > > > > At Thu, 5 Mar 2020 18:06:26 +0900, Masahiko Sawada > > <masahiko.saw...@2ndquadrant.com> wrote in > > > On Thu, 5 Mar 2020 at 16:36, Kyotaro Horiguchi <horikyota....@gmail.com> > > > wrote: > > > I think normally users don't want to remove built-in functions because > > > they think these functions are trusted and it's hard to restore them > > > when they want later. So I thought user want to search functions that > > > is unnecessary but not a built-in function. > > > > I'm not sure those who wants to introduce PCI-DSS are under a normal > > sitautation, though:p > > > > That seems beside the point. pg_read_file is known to be usable for > > drawing out database files. If you leave the function alone, the > > security officer (designer?) have to consider the possibility that > > someone draws out files in the database system using the function and > > have to plan the action for the threat. In that context, > > built-in-or-not distinction is useless. > > So how do you check if unnecessary, malicious or unauthorized function > exists in database after that, for example when periodical security > check? Functions defined after initdb must be checked under user's > responsibility but since normally there are many built-in functions in > pg_proc the check in pg_proc could be cumbersome. So the idea of this > feature is to make that check easier by marking built-in functions.
I think there's no easy way to accomplish it. If PostgreSQL documentation says that "Yeah, the function tells if using the function or feature complies the request of PCI-DSS 2.2.5!" and it tells safe for all built-in functions, it is an outright lie even if the server is just after initdb'ed. Sparating from PCI-DSS and we document it just as "the function tells if the function is built-in or not", it's true. (But I'm not sure about its usage..) I might be misunderstanding about the operation steps in your mind. > > > > In the first place, if you assume that someone may install malicious > > functions in the server after beginning operation, distinction by OID > > doesn't work at all because who can illegally install a malicious > > function also be able to modify its OID with quite low odds. > > Yes, that's what Fujii-san also pointed out. It's better to find a way > to distinct functions while not relying on OID. And it is out-of-scope of PCI-DSS 2.2.5. It mentions design or system-building time. Apart from PCI-DSS, if you are concerning operation-time threats. If once someone malicious could install a function to the server, I think that kind of feature with any criteria no longer work as a countermeasure for further threats. Maybe something like tripwire would work. That is, maybe a kind of checksum over system catalogs. regards. -- Kyotaro Horiguchi NTT Open Source Software Center