At Sun, 8 Mar 2020 11:55:06 +0900, Masahiko Sawada <masahiko.sawada@2ndquadrant.com> wrote in
> On Thu, 5 Mar 2020 at 18:39, Kyotaro Horiguchi <horikyota.ntt@gmail.com> wrote:
> >
> > At Thu, 5 Mar 2020 18:06:26 +0900, Masahiko Sawada <masahiko.sawada@2ndquadrant.com> wrote in
> > > On Thu, 5 Mar 2020 at 16:36, Kyotaro Horiguchi <horikyota.ntt@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
