Received: from malur.postgresql.org ([2a02:16a8:dc51::56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1fq2Ac-0003i0-RC for pgsql-admin@arkaria.postgresql.org; Wed, 15 Aug 2018 20:13:30 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1fq2Aa-0004Uw-1F for pgsql-admin@arkaria.postgresql.org; Wed, 15 Aug 2018 20:13:28 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1fq2AZ-0004Up-Px for pgsql-admin@lists.postgresql.org; Wed, 15 Aug 2018 20:13:27 +0000 Received: from asil.comp.uvic.ca ([142.104.177.225]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1fq2AP-0002b3-25 for pgsql-admin@lists.postgresql.org; Wed, 15 Aug 2018 20:13:24 +0000 Received: from strike.comp.uvic.ca (strike.comp.uvic.ca [142.104.191.240]) by asil.comp.uvic.ca (8.14.4/8.14.3) with ESMTP id w7FKDAF2008537 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 15 Aug 2018 13:13:10 -0700 Subject: Re: How to revoke privileged from PostgreSQL's superuser To: Bruce Momjian Cc: pgsql-admin@lists.postgresql.org References: <913907.28546.qm@web103014.mail.kks.yahoo.co.jp> <20180810194105.GD7840@momjian.us> <20180814195919.GA29140@momjian.us> <20180815145912.GA11573@momjian.us> <10cde505-db4b-bbeb-7d8a-7c4e145c6042@uvic.ca> <20180815192838.GA5005@momjian.us> From: Evan Rempel Message-ID: Date: Wed, 15 Aug 2018 13:13:10 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <20180815192838.GA5005@momjian.us> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-MW X-UVic-Virus-Scanned: OK - Passed virus scan by ClamAV (clamd) on asil X-UVic-Virus-Scanned: OK - Passed virus scan by Sophos (sophie) on asil X-UVic-Scan: asil.comp.uvic.ca filter_version 3.7.9 X-Scanned-By: MIMEDefang 2.78 List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk On 08/15/2018 12:28 PM, Bruce Momjian wrote: > On Wed, Aug 15, 2018 at 09:05:51AM -0700, Evan Rempel wrote: >> At the end of the day someone has full access and control and can do anything without auditing database statements. >> >> For instance, as the root user on the server, I can do: >> >> - shutdown the server database >> - copy the entire DB filespace to my workstation >> - change the workstation config for no logging/auditing >> - start the workstation Database >> - make all the changes I want at the workstation. >> - stop the workstation database >> - copy all of the files back to the server >> - start the server Database. >> >> no logging of any kind and all of the data would be suspect. > Well, that is an intersting attack, and I don't think it requires root > --- all it requires is access to the Postgres data directory. Frankly, > I don't know if there is a way to prevent the Postgres superuser from > silently disabling logging because the _data_ is fully under the control > of the Postgres superuser. Which highlights a small design flaw. For security purposes many applications have moved the configuration files out of the data folder. PHP and MySQL are two that come to mind. The postgresql.conf and the pg_hba.conf should NOT be stored in the database data directory. These files should NOT be owned or editable by the postgres user (OS user that postmaster is running as). The result is that security options and configuration options (such as logging) could NOT be changed by the postgres OS account, and thus NOT be cvhanged by the postgres superuser database account. Ideally the audit logging and statement logging should NOT be permitted to be controlled via session commands (i.e. the client) Just my $0.02 -- Evan