Обсуждение: BUG #3809: SSL "unsafe" private key permissions bug
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.
"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 diff -Nur postgresql-8.2/build-tree/postgresql-8.2beta1/src/backend/libpq/be-secure.c postgresql-8.2.new/build-tree/postgresql-8.2beta1/src/backend/libpq/be-secure.c --- postgresql-8.2beta1/src/backend/libpq/be-secure.c 2006-09-04 16:57:27.000000000 +0200 +++ postgresql-8.2beta1/src/backend/libpq/be-secure.c 2006-09-25 19:24:13.000000000 +0200 @@ -751,13 +751,15 @@ * directory permission check in postmaster.c) */ #if !defined(WIN32) && !defined(__CYGWIN__) - if (!S_ISREG(buf.st_mode) || (buf.st_mode & (S_IRWXG | S_IRWXO)) || - buf.st_uid != geteuid()) + if (!S_ISREG(buf.st_mode) || (buf.st_mode & (S_IWGRP | S_IRWXO)) || + (buf.st_uid != geteuid()) && buf.st_uid != 0) ereport(FATAL, (errcode(ERRCODE_CONFIG_FILE_ERROR), errmsg("unsafe permissions on private key file \"%s\"", SERVER_PRIVATE_KEY_FILE), - errdetail("File must be owned by the database user and must have no permissions for \"group\" or \"other\"."))); + errdetail("File must be owned by the \ +database user or root, must have no write permission for \"group\", and must \ +have no permissions for \"other\"."))); #endif if (!SSL_CTX_use_PrivateKey_file(SSL_context,
Вложения
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. +