Re: Hiding a GUC from SQL

Поиск
Список
Период
Сортировка
Искать
От
raf
Тема
Re: Hiding a GUC from SQL
Дата
Msg-id
20200622052055.zv5zq2tr6iqyc3tv@raf.org
Ответ на
Список
Дерево обсуждения
Hiding a GUC from SQL Michel Pelletier <pelletier.michel@gmail.com>
Re: Hiding a GUC from SQL Tom Lane <tgl@sss.pgh.pa.us>
Re: Hiding a GUC from SQL Michel Pelletier <pelletier.michel@gmail.com>
Re: Hiding a GUC from SQL Laurenz Albe <laurenz.albe@cybertec.at>
Re: Hiding a GUC from SQL raf <raf@raf.org>
Re: Hiding a GUC from SQL Laurenz Albe <laurenz.albe@cybertec.at>
Re: Hiding a GUC from SQL raf <raf@raf.org>
Re: Hiding a GUC from SQL Michel Pelletier <pelletier.michel@gmail.com>
Re: Hiding a GUC from SQL Michel Pelletier <pelletier.michel@gmail.com>
Laurenz Albe wrote:

> On Mon, 2020-06-22 at 09:44 +1000, raf wrote:
> > A superuser can access files and start programs on the server machine.
> > > A dedicated superuser may for example attach to PostgreSQL with a debugger
> > > and read the value of the variable.
> > > 
> > > And if that doesn't work, there may be other things to try.
> > > 
> > > It is mostly useless to try to keep a superuser from doing anything that
> > > the "postgres" operating system user can do.
> > 
> > But only mostly useless. :-) There are ways to limit the power of the
> > superuser. On Linux, for instance, "sysctl kernel.yama.ptrace_scope=3"
> > prevents tracing, debugging, and reading another process's memory, even
> > by the superuser, and the only way to turn it off is via a (hopefully
> > noticeable) reboot.
> 
> Interesting.  Will this block a user from debugging his own processes?

Yes.

> Perhaps you can plug that hole that way, but that was just the first thing
> that popped in my head.  Don't underestimate the creativity of attackers.
> I for one would not trust my ability to anticipate all possible attacks,
> and I think that would be a bad security practice.

Yes, but that's no reason not to perform as much risk
assessment and mitigation as you can afford/justify.
Not being able to prevent all attacks is no reason not
to prevent those that you can. :-) Nobody said anything
about underestimating anyone or trusting anyone.

> Yours,
> Laurenz Albe

cheers,
raf



В списке pgsql-general по дате отправления
От: Sankar P
Дата:
От: Paul Förster
Дата:
Сообщение: Re: Netapp SnapCenter
FAQ