BUG #3809: SSL "unsafe" private key permissions bug

"Simon Arlott" <postgresql.simon@arlott.org> writes:

FATAL: unsafe permissions on private key file "server.key"
DETAIL: File must be owned by the database user and must have no
permissions for "group" or "other".

It should be possible to disable this check in the configuration, so those
of us capable of deciding what's unsafe can do so.

You haven't given any reason to think that you are smarter than this
check.

regards, tom lane

On 08/12/07 15:31, Tom Lane wrote:

"Simon Arlott" <postgresql.simon@arlott.org> writes:

FATAL: unsafe permissions on private key file "server.key"
DETAIL: File must be owned by the database user and must have no
permissions for "group" or "other".

It should be possible to disable this check in the configuration, so those
of us capable of deciding what's unsafe can do so.

You haven't given any reason to think that you are smarter than this
check.

The directory containing the SSL keys has appropriate permissions, I
shouldn't have to make a separate copy of them for every application.

regards, tom lane

--
Simon Arlott

"Simon Arlott" <simon@arlott.org> writes:

On 08/12/07 15:31, Tom Lane wrote:

"Simon Arlott" <postgresql.simon@arlott.org> writes:

FATAL: unsafe permissions on private key file "server.key"
DETAIL: File must be owned by the database user and must have no
permissions for "group" or "other".

It should be possible to disable this check in the configuration, so those
of us capable of deciding what's unsafe can do so.

You haven't given any reason to think that you are smarter than this
check.

The directory containing the SSL keys has appropriate permissions, I
shouldn't have to make a separate copy of them for every application.

Another case where it's important to be able to disable this check is when
you're using a file system which doesn't use the unix bits for permission
checks either at all or in the traditional way.

So for example if the key directory lay on an FAT filesystem which doesn't
have unix bit per file the only way to satisfy the check would be to mount the
filesystem with the option to make every file in the filesystem have those
bits. Storing your keys on a usb stick (which usually use fat filesystems)
isn't really such a crazy idea either.

--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
Ask me about EnterpriseDB's PostGIS support!

Gregory Stark wrote:

So for example if the key directory lay on an FAT filesystem which doesn't
have unix bit per file the only way to satisfy the check would be to mount the
filesystem with the option to make every file in the filesystem have those
bits. Storing your keys on a usb stick (which usually use fat filesystems)
isn't really such a crazy idea either.

Storing a server SSL key on a USB stick is not crazy? I don't follow.
What use case do you have for that?

--
Alvaro Herrera http://www.amazon.com/gp/registry/CTMLCN8V17R4
"La persona que no quer�a pecar / estaba obligada a sentarse
en duras y empinadas sillas / desprovistas, por cierto
de blandos atenuantes" (Patricio Vogel)

Alvaro Herrera <alvherre@alvh.no-ip.org> writes:

Gregory Stark wrote:

Storing your keys on a usb stick (which usually use fat filesystems)
isn't really such a crazy idea either.

Storing a server SSL key on a USB stick is not crazy? I don't follow.
What use case do you have for that?

It's worth pointing out also that we require server.key to be directly
in the $PGDATA directory, which means that any filesystem limitations on
its permissions info are going to apply to the $PGDATA directory itself.

Curiously enough, the access-permission checks on both $PGDATA and
$PGDATA/server.key are diked out in WIN32 builds, but I consider that
a bug we should fix, not a feature to be extended.

regards, tom lane

"Tom Lane" <tgl@sss.pgh.pa.us> writes:

Alvaro Herrera <alvherre@alvh.no-ip.org> writes:

Gregory Stark wrote:

Storing your keys on a usb stick (which usually use fat filesystems)
isn't really such a crazy idea either.

Storing a server SSL key on a USB stick is not crazy? I don't follow.
What use case do you have for that?

Sure, private keys are often more sensitive than the data they protect. You
might want them not to be included in backups or to ever live on spinning
disks that you'll have to wipe in case of a disk crash. A stick can be moved
to a backup server when failing over. Once upon a time people used to use
floppies for this purpose (which also use fat filesystems incidentally).

It's worth pointing out also that we require server.key to be directly
in the $PGDATA directory, which means that any filesystem limitations on
its permissions info are going to apply to the $PGDATA directory itself.

Curiously enough, the access-permission checks on both $PGDATA and
$PGDATA/server.key are diked out in WIN32 builds, but I consider that
a bug we should fix, not a feature to be extended.

Another filesystem where people get bit by tools which assume they can look
directly at unix permission bits instead of using access() and impose fascist
rules on what they expect to see there is AFS. The unix bits are mostly
meaningless on AFS. So you get users complaining that they're following the
instructions on setting permission and the occasional tool is still
complaining about problems.

I think looking at the unix permission bits and imposing policy is usually a
bad idea but in those few cases where it makes any sense there should always
be a switch to disable it.

--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
Get trained by Bruce Momjian - ask me about EnterpriseDB's PostgreSQL training!

Hi,

Simon Arlott [2007-12-08 12:24 +0000]:

Bug reference: 3809
Logged by: Simon Arlott
Email address: postgresql.simon@arlott.org
PostgreSQL version: 8.2.4
Operating system: Linux 2.6.23
Description: SSL "unsafe" private key permissions bug
Details:

FATAL: unsafe permissions on private key file "server.key"
DETAIL: File must be owned by the database user and must have no
permissions for "group" or "other".

It should be possible to disable this check in the configuration, so those
of us capable of deciding what's unsafe can do so.

For the same reason Debian/Ubuntu have modified this check ages ago,
to also allow for keys which are owned by root and readable by a
particular group. A lot of our users want to share a common SSL
cert/key between all servers, and the upstream check makes this
impossible. (Ubuntu sets up all server packages in a way that they all
share a common SSL key called "snakeoil" which is generated on system
installation. By merely replacing this with a real one, your box
becomes sanely configured without fiddling with any configuration
files.)

I already proposed this patch two times, but it has been rejected so
far unfortunately. But maybe it's useful for you.

Martin

--
Martin Pitt http://www.piware.de
Ubuntu Developer http://www.ubuntu.com
Debian Developer http://www.debian.org

Agreed. Let's look this over again in 8.4. I am feeling our
restrictions are making things _less_ secure sometimes.

This has been saved for the 8.4 release:

http://momjian.postgresql.org/cgi-bin/pgpatches_hold

---------------------------------------------------------------------------

Martin Pitt wrote:
-- Start of PGP signed section.

Hi,

Simon Arlott [2007-12-08 12:24 +0000]:

Bug reference: 3809
Logged by: Simon Arlott
Email address: postgresql.simon@arlott.org
PostgreSQL version: 8.2.4
Operating system: Linux 2.6.23
Description: SSL "unsafe" private key permissions bug
Details:

FATAL: unsafe permissions on private key file "server.key"
DETAIL: File must be owned by the database user and must have no
permissions for "group" or "other".

It should be possible to disable this check in the configuration, so those
of us capable of deciding what's unsafe can do so.

For the same reason Debian/Ubuntu have modified this check ages ago,
to also allow for keys which are owned by root and readable by a
particular group. A lot of our users want to share a common SSL
cert/key between all servers, and the upstream check makes this
impossible. (Ubuntu sets up all server packages in a way that they all
share a common SSL key called "snakeoil" which is generated on system
installation. By merely replacing this with a real one, your box
becomes sanely configured without fiddling with any configuration
files.)

I already proposed this patch two times, but it has been rejected so
far unfortunately. But maybe it's useful for you.

Martin

--
Martin Pitt http://www.piware.de
Ubuntu Developer http://www.ubuntu.com
Debian Developer http://www.debian.org

-- End of PGP section, PGP failed!

--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://postgres.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

Added to TODO:

* Allow SSL key file permission checks to be optionally disabled when
sharing SSL keys with other applications

http://archives.postgresql.org/pgsql-bugs/2007-12/msg00069.php

---------------------------------------------------------------------------

Simon Arlott wrote:

The following bug has been logged online:

Bug reference: 3809
Logged by: Simon Arlott
Email address: postgresql.simon@arlott.org
PostgreSQL version: 8.2.4
Operating system: Linux 2.6.23
Description: SSL "unsafe" private key permissions bug
Details:

FATAL: unsafe permissions on private key file "server.key"
DETAIL: File must be owned by the database user and must have no
permissions for "group" or "other".

It should be possible to disable this check in the configuration, so those
of us capable of deciding what's unsafe can do so.

---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match

--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://postgres.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +