Re: proposal: hide application_name from other users
От | Harold Giménez |
---|---|
Тема | Re: proposal: hide application_name from other users |
Дата | |
Msg-id | CACZOJr8rYBS9_JLR_6SRAqBKo+AoCM81BxgkE3yNDHWscVedEQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: proposal: hide application_name from other users (Bruce Momjian <bruce@momjian.us>) |
Ответы |
Re: proposal: hide application_name from other users
|
Список | pgsql-hackers |
On Tue, Jan 21, 2014 at 4:19 PM, Bruce Momjian <bruce@momjian.us> wrote: > On Tue, Jan 21, 2014 at 04:06:46PM -0800, Harold Giménez wrote: >> I don't know of a client where it can't be overridden. The friction >> occurs when by default it sets it to something useful to a developer >> (useful eg: to find what process is holding a lock), but is not >> possible to conceal from other users on the same cluster. If this were >> an in-premise or private cluster the point is moot. >> >> Furthermore consider when even using application_name for it's >> original intended use. On a shared environment as I'm describing here, >> that makes it possible for an attacker to identify what apps connect >> to a given server, or on the other hand is a way to find out where a >> given application stores its data, which can be used for a more >> targeted attack. > > So security through obscurity? Why wouldn't the attacker just try all > the app methods at once and not even bother looking at the application > name? A malicious attacker may want to attack or harm `app1`. They write a script that provisions databases and check in pg_stat_activity until they find an application_name of `app1`. Having found the database holding app1's data, they then use a targeted attack on postgres, say a privilege escalation attack or any other vulnerability we don't know exists yet. Without application_name, the attacker would be unable to find the target database host to attack. -Harold
В списке pgsql-hackers по дате отправления: