server authentication over Unix-domain sockets
in [PgSql]
|
From: Magnus Hagander on 11 Jun 2010 07:55 On Sun, May 30, 2010 at 13:00, Peter Eisentraut <peter_e(a)gmx.net> wrote: > It has been discussed several times in the past that there is no way for > a client to authenticate a server over Unix-domain sockets. �So > depending on circumstances, a local user could easily insert his own > server and collect passwords and data. �Suggestions for possible > remedies included: > > You can put the socket file in a sufficiently write-protected directory. > But that would strongly deviate from the default setup, and anyway the > client still cannot readily verify that the server is the right one. > > You can also run SSL over Unix-domain sockets. �This is currently > disabled in the code, but it would work just fine. �But it's obviously > kind of awkward, and the connection overhead was noticeable in tests. > > Then it was suggested to use the local "ident" mechanism in reverse, so > the client could verify what user the server runs under. �I have > implemented a prototype of this. �You can put, e.g., > > requirepeer=postgres > > into the connection parameters, and the connection will be rejected > unless the process at the other end of the socket is running as > postgres. > > The patch needs some portability work and possible refactoring because > of that, but before I embark on that, comments on the concept? I like it. ISTM like something that would be very useful - an easy way to get a fair amount of extra security in the case of local connections, at almost zero cost. Just an "export PGREQUIREPEER=postgres" in .profile goes a long way :-) -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/ -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Magnus Hagander on 11 Jun 2010 07:53 On Sun, May 30, 2010 at 13:00, Peter Eisentraut <peter_e(a)gmx.net> wrote: > It has been discussed several times in the past that there is no way for > a client to authenticate a server over Unix-domain sockets. �So > depending on circumstances, a local user could easily insert his own > server and collect passwords and data. �Suggestions for possible > remedies included: > > You can put the socket file in a sufficiently write-protected directory. > But that would strongly deviate from the default setup, and anyway the > client still cannot readily verify that the server is the right one. > > You can also run SSL over Unix-domain sockets. �This is currently > disabled in the code, but it would work just fine. �But it's obviously > kind of awkward, and the connection overhead was noticeable in tests. > > Then it was suggested to use the local "ident" mechanism in reverse, so > the client could verify what user the server runs under. �I have > implemented a prototype of this. �You can put, e.g., > > requirepeer=postgres > > into the connection parameters, and the connection will be rejected > unless the process at the other end of the socket is running as > postgres. > > The patch needs some portability work and possible refactoring because > of that, but before I embark on that, comments on the concept? > > > > -- > Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-hackers > > -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/ -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Stephen Frost on 11 Jun 2010 08:07 * Peter Eisentraut (peter_e(a)gmx.net) wrote: > The patch needs some portability work and possible refactoring because > of that, but before I embark on that, comments on the concept? I definitely like the idea but I dislike requiring the user to do something to implement it. Thinking about how packagers might want to use it, could we make it possible to build it defaulted to a specific value (eg: 'postgres' on Debian) and allow users a way to override and/or unset it? Having the option wouldn't do much unless users know of it and use it and it strikes that will very often not be the case. I'm impartial towards whatever PG wants to do with the default, just so long as packagers can override it and set it to something specific. Also, to that end, it's got to be name-based. Exim in Debian did something similar and actually tried to force a particular UID.. that was horrid. :) On Debian, at least, the user is almost always 'postgres', but the UID will vary depending on exactly when the packages were installed (before or after other system-user-creating packages). Thanks, Stephen
From: Magnus Hagander on 11 Jun 2010 08:08 On Fri, Jun 11, 2010 at 14:07, Stephen Frost <sfrost(a)snowman.net> wrote: > * Peter Eisentraut (peter_e(a)gmx.net) wrote: >> The patch needs some portability work and possible refactoring because >> of that, but before I embark on that, comments on the concept? > > I definitely like the idea but I dislike requiring the user to do > something to implement it. �Thinking about how packagers might want to > use it, could we make it possible to build it defaulted to a specific > value (eg: 'postgres' on Debian) and allow users a way to override > and/or unset it? Well, even if we don't put that in, the packager could export a global PGREQUIREPEER environment variable. > Having the option wouldn't do much unless users know of it and use it > and it strikes that will very often not be the case. > > I'm impartial towards whatever PG wants to do with the default, just so > long as packagers can override it and set it to something specific. > Also, to that end, it's got to be name-based. �Exim in Debian did > something similar and actually tried to force a particular UID.. �that > was horrid. :) �On Debian, at least, the user is almost always > 'postgres', but the UID will vary depending on exactly when the packages > were installed (before or after other system-user-creating packages). Oh yes, absolutely name-based. -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/ -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Stephen Frost on 11 Jun 2010 08:11
* Magnus Hagander (magnus(a)hagander.net) wrote: > On Fri, Jun 11, 2010 at 14:07, Stephen Frost <sfrost(a)snowman.net> wrote: > > I definitely like the idea but I dislike requiring the user to do > > something to implement it. Thinking about how packagers might want to > > use it, could we make it possible to build it defaulted to a specific > > value (eg: 'postgres' on Debian) and allow users a way to override > > and/or unset it? > > Well, even if we don't put that in, the packager could export a global > PGREQUIREPEER environment variable. Yeahhhh, no, that's a crappy solution, sorry. :) I've been down that road with people trying to monkey with /etc/bashrc; oh wait, not everyone uses bash, and having every package screw with that stuff is equally horrible. Admittedly, in this specific case, Debian could implement what you're talking about in it's wrapper system, maybe, but I still don't like it and if people don't use the wrapper (I can imagine cases why that might happen, tho I havn't ever had to myself), they wouldn't get the benefit.. Thanks, Stephen |