Re: [HACKERS] Relaxing SSL key permission checks

Committed with the discussed adjustment and documentation update. On 3/18/16 2:26 PM, Christoph Berg wrote: > Re: Peter Eisentraut 2016-03-16 <56e8c221.1050...@gmx.net> * it failed to check for S_IXUSR, so permissions 0700 were okay, in contradiction with what the error message

Re: [HACKERS] Relaxing SSL key permission checks

Committed with the discussed adjustment and documentation update. On 3/18/16 2:26 PM, Christoph Berg wrote: > Re: Peter Eisentraut 2016-03-16 <56e8c221.1050...@gmx.net> * it failed to check for S_IXUSR, so permissions 0700 were okay, in contradiction with what the error message

Re: [HACKERS] Relaxing SSL key permission checks

Peter Eisentraut wrote: > On 3/10/16 9:20 PM, Peter Eisentraut wrote: > > On 3/4/16 3:55 PM, Alvaro Herrera wrote: > >> * it failed to check for S_IXUSR, so permissions 0700 were okay, in > >> contradiction with what the error message indicates. This is a > >> preexisting bug actually. Do we

Re: [HACKERS] Relaxing SSL key permission checks

Re: Peter Eisentraut 2016-03-16 <56e8c221.1050...@gmx.net> > >> * it failed to check for S_IXUSR, so permissions 0700 were okay, in > >> contradiction with what the error message indicates. This is a > >> preexisting bug actually. Do we want to fix it by preventing a > >> user-executable file

Re: [HACKERS] Relaxing SSL key permission checks

On 3/10/16 9:20 PM, Peter Eisentraut wrote: > On 3/4/16 3:55 PM, Alvaro Herrera wrote: >> * it failed to check for S_IXUSR, so permissions 0700 were okay, in >> contradiction with what the error message indicates. This is a >> preexisting bug actually. Do we want to fix it by preventing a >>

Re: [HACKERS] Relaxing SSL key permission checks

On 3/4/16 3:55 PM, Alvaro Herrera wrote: > * it failed to check for S_IXUSR, so permissions 0700 were okay, in > contradiction with what the error message indicates. This is a > preexisting bug actually. Do we want to fix it by preventing a > user-executable file (possibly breaking compability

Re: [HACKERS] Relaxing SSL key permission checks

Re: Alvaro Herrera 2016-03-04 <20160304205521.GA735336@alvherre.pgsql> > For the sake of cleanliness, I propose splitting out the checks for > regular file and for owned-by-root-or-us from the actual chmod-level > checks at the same time. That way we can provide more specific error > messages for

Re: [HACKERS] Relaxing SSL key permission checks

Christoph Berg wrote: > Re: To Tom Lane 2016-02-19 <20160219115334.gb26...@msg.df7cb.de> > > Updated patch attached. > > *Blush* I though I had compile-tested the patch, but without > --enable-openssl it wasn't built :(. > > The attached patch has successfully been included in the 9.6 Debian >

Re: [HACKERS] Relaxing SSL key permission checks

Re: Tom Lane 2016-02-22 <21507.1456099...@sss.pgh.pa.us> > Stephen Frost writes: > > Just to be clear, I'm not really against this patch as-is, but it > > shouldn't be a precedent or limit us from supporting more permissive > > permissions in other areas (or even here) if

Re: [HACKERS] Relaxing SSL key permission checks

Stephen Frost writes: > Just to be clear, I'm not really against this patch as-is, but it > shouldn't be a precedent or limit us from supporting more permissive > permissions in other areas (or even here) if there are sensible > use-cases for more permissive permissions. OK,

Re: [HACKERS] Relaxing SSL key permission checks

* Tom Lane (t...@sss.pgh.pa.us) wrote: > Christoph Berg writes: > > The attached patch has successfully been included in the 9.6 Debian > > package, passed the regression tests there, and I've also done some > > chmod/chown tests on the filesystem to verify it indeed catches the

Re: [HACKERS] Relaxing SSL key permission checks

Christoph Berg writes: > The attached patch has successfully been included in the 9.6 Debian > package, passed the regression tests there, and I've also done some > chmod/chown tests on the filesystem to verify it indeed catches the > cases laid out by Tom. Please add this to

Re: [HACKERS] Relaxing SSL key permission checks

Re: To Tom Lane 2016-02-19 <20160219115334.gb26...@msg.df7cb.de> > Updated patch attached. *Blush* I though I had compile-tested the patch, but without --enable-openssl it wasn't built :(. The attached patch has successfully been included in the 9.6 Debian package, passed the regression tests

Re: [HACKERS] Relaxing SSL key permission checks

Tom, * Tom Lane (t...@sss.pgh.pa.us) wrote: > Now, I have heard it argued that the OpenSSH/L authors are a bunch of > idiots who know nothing about security. But it's not like insisting > on restrictive permissions on key files is something we invented out > of the blue. It's pretty standard

Re: [HACKERS] Relaxing SSL key permission checks

Re: Tom Lane 2016-02-18 <27423.1455809...@sss.pgh.pa.us> > I did have a thought though: could we allow two distinct permissions > configurations? That is, allow either: > > * file is owned by us, mode 0600 or less > > * file is owned by root, mode 0640 or less > > The first case is what we

Re: [HACKERS] Relaxing SSL key permission checks

On 02/18/2016 08:22 PM, Tom Lane wrote: Now, I have heard it argued that the OpenSSH/L authors are a bunch of idiots who know nothing about security. But it's not like insisting on restrictive permissions on key files is something we invented out of the blue. It's pretty standard practice,

Re: [HACKERS] Relaxing SSL key permission checks

Stephen Frost writes: > * Tom Lane (t...@sss.pgh.pa.us) wrote: >> I completely disagree that those file-permissions checks are useless. > If that's something you're concerned with then the right answer is to > monitor the file permissions- and there are tools which do exactly

Re: [HACKERS] Relaxing SSL key permission checks

On 2/18/16 10:17 AM, Tom Lane wrote: > Christoph Berg writes: >> Currently the server insists on ssl_key_file's permissions to be 0600 >> or less, and be owned by the database user. Debian has been patching >> be-secure.c since forever (the git history goes back to 8.2beta1) to

Re: [HACKERS] Relaxing SSL key permission checks

Tom, * Tom Lane (t...@sss.pgh.pa.us) wrote: > Stephen Frost writes: > > Further, the notion that *this* is the footgun is completely off the > > reservation- if the files have been changed to allow untrusted users to > > have access to them, there isn't diddly we can do about

Re: [HACKERS] Relaxing SSL key permission checks

Stephen Frost writes: > Further, the notion that *this* is the footgun is completely off the > reservation- if the files have been changed to allow untrusted users to > have access to them, there isn't diddly we can do about it. I completely disagree that those

Re: [HACKERS] Relaxing SSL key permission checks

* Tom Lane (t...@sss.pgh.pa.us) wrote: > Andres Freund writes: > > ... We don't prevent the user from making the > > configuration file world-writable either, > > Maybe we should. It wasn't an issue originally, because the config files > were necessarily inside $PGDATA which

Re: [HACKERS] Relaxing SSL key permission checks

Andres Freund writes: > ... We don't prevent the user from making the > configuration file world-writable either, Maybe we should. It wasn't an issue originally, because the config files were necessarily inside $PGDATA which we restrict permissions on. But these days you

Re: [HACKERS] Relaxing SSL key permission checks

On 2016-02-18 10:17:49 -0500, Tom Lane wrote: > Christoph Berg writes: > > Currently the server insists on ssl_key_file's permissions to be 0600 > > or less, and be owned by the database user. Debian has been patching > > be-secure.c since forever (the git history goes back to

Re: [HACKERS] Relaxing SSL key permission checks

Bruce Momjian writes: > On Thu, Feb 18, 2016 at 10:17:49AM -0500, Tom Lane wrote: >> We could allow group-readable if we had some way to know whether to >> trust the specific group, but I don't think there's any practical >> way to do that. System conventions vary too much. >

Re: [HACKERS] Relaxing SSL key permission checks

On Thu, Feb 18, 2016 at 10:17:49AM -0500, Tom Lane wrote: > Christoph Berg writes: > > Currently the server insists on ssl_key_file's permissions to be 0600 > > or less, and be owned by the database user. Debian has been patching > > be-secure.c since forever (the git history

Re: [HACKERS] Relaxing SSL key permission checks

Christoph Berg writes: > Currently the server insists on ssl_key_file's permissions to be 0600 > or less, and be owned by the database user. Debian has been patching > be-secure.c since forever (the git history goes back to 8.2beta1) to > relax that to 0640 or less, and owned by