On Sat, Dec 22, 2007 at 09:25:05AM -0500, Bruce Momjian wrote:
> So, what solutions exist? We could require the use of port numbers less
> than 1024 which typically require root and then become a non-root user,
> but that requires root to start the server. We could put the unix
I don't know abou
Greg Smith wrote:
On Sat, 29 Dec 2007, Joshua D. Drake wrote:
"they've" has the potential to be "we"... As I recall the individual
made a reasonable effort to introduce the work that he was doing to the
community.
After a bit of hindsight research, I think SE-PostgreSQL suffered from
two tim
Joshua D. Drake wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Sat, 29 Dec 2007 14:40:29 -0500 (EST)
Greg Smith <[EMAIL PROTECTED]> wrote:
On Sat, 29 Dec 2007, Joshua D. Drake wrote:
http://code.google.com/p/sepgsql/
???
Getting that to work required some obtrusive changes to the s
Greg Smith wrote:
On Sat, 29 Dec 2007, Joshua D. Drake wrote:
http://code.google.com/p/sepgsql/
???
Getting that to work required some obtrusive changes to the source code,
which they've only done to 8.2.4. Even that doesn't seem to be
production-quality and it's not clear how that will ma
Tom Lane wrote:
> This is basically the same old mutual authentication problem that SSL
> was designed to solve by using certificates. I don't think we have
> either the need or the expertise to re-invent that wheel.
>
> ISTM we have these action items:
>
> 1. Improve the code so that SSL authen
On Sat, 29 Dec 2007, Joshua D. Drake wrote:
"they've" has the potential to be "we"... As I recall the individual
made a reasonable effort to introduce the work that he was doing to the
community.
After a bit of hindsight research, I think SE-PostgreSQL suffered from two
timing problems combin
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Sat, 29 Dec 2007 14:40:29 -0500 (EST)
Greg Smith <[EMAIL PROTECTED]> wrote:
> On Sat, 29 Dec 2007, Joshua D. Drake wrote:
>
> > http://code.google.com/p/sepgsql/
> > ???
>
> Getting that to work required some obtrusive changes to the source
> cod
On Sat, 29 Dec 2007, Joshua D. Drake wrote:
http://code.google.com/p/sepgsql/
???
Getting that to work required some obtrusive changes to the source code,
which they've only done to 8.2.4. Even that doesn't seem to be
production-quality and it's not clear how that will make its way into
ne
Mark Mielke <[EMAIL PROTECTED]> writes:
> What has come out for me is that this isn't UNIX socket specific at all
> (although there may be UNIX socket specific options available). The
> standard PostgreSQL port is above 1024, and anybody could
> bind()/listen()/accept() on it, assuming it is not
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> It might well be useful for us to look at drafting an SELinux policy,
There already is one. However, I'm not sure that it's ever been
reviewed by anyone who's Postgres-savvy (I certainly haven't looked
at it:-(). It would be useful for that to happen
Andrew Dunstan wrote:
It might well be useful for us to look at drafting an SELinux policy,
even if it's not universal. After all, this situation is precisely the
sort of thing that SELinux is about, ISTM.
http://code.google.com/p/sepgsql/
???
Sincerely,
Joshua D. Drake
-
Mark Mielke wrote:
Andrew Dunstan wrote:
D'Arcy J.M. Cain wrote:
- 1: How does the client assure that the postmaster is legit
- 2: How does the postmaster assure that the client is legit
And neither answers the original problem:
3. How can the sysadmin prevent a malicious local user f
Magnus Hagander wrote:
> Martijn van Oosterhout wrote:
> > On Sat, Dec 29, 2007 at 12:40:24PM +0100, Magnus Hagander wrote:
> >> We already *do* allow the DBA to choose this, no? If you put the root
> >> certificate on the client, it *will* verify the server cert, and it
> >> *will* refuse to conne
Andrew Dunstan wrote:
D'Arcy J.M. Cain wrote:
- 1: How does the client assure that the postmaster is legit
- 2: How does the postmaster assure that the client is legit
And neither answers the original problem:
3. How can the sysadmin prevent a malicious local user from hijacking
the soc
* D'Arcy J.M. Cain ([EMAIL PROTECTED]) wrote:
> > Probably the first answer is not to run postgres on a machine with
> > untrusted users, but that's not always possible. Maybe we can't find a
> > simple cross-platform answer, but that doesn't mean we should not look
> > at platform-specific answ
On Sat, 29 Dec 2007 10:38:13 -0500
Andrew Dunstan <[EMAIL PROTECTED]> wrote:
>
>
> D'Arcy J.M. Cain wrote:
> > - 1: How does the client assure that the postmaster is legit
> > - 2: How does the postmaster assure that the client is legit
>
> And neither answers the original problem:
Which se
D'Arcy J.M. Cain wrote:
- 1: How does the client assure that the postmaster is legit
- 2: How does the postmaster assure that the client is legit
And neither answers the original problem:
3. How can the sysadmin prevent a malicious local user from hijacking
the sockets if the postm
Magnus Hagander wrote:
Mark Mielke wrote:
Why are you even using a password in this case, and not just key-based
auth? Wouldn't that be even easier and more secure?
Users of this product don't have keys - they have passwords. The
username/password is for per-user authentication. The u
On Sat, 29 Dec 2007 12:45:26 +0100
Magnus Hagander <[EMAIL PROTECTED]> wrote:
> That is exactly my point. The server can never know if the client has
> actually verified anything. It can provide the client with the *means*
> to verify things, but it can't enforce it.
I know this is probably obviou
Mark Mielke wrote:
> Magnus Hagander wrote:
>> Mark Mielke wrote:
>>
>>>
>>> I have done this for my own application before. Although the client and
>>> server use standard TLS 1.0 to speak to each other with a required
>>> authentication of RSA 1024-bit and a required encryption of AES 128-bit,
Martijn van Oosterhout wrote:
> On Sat, Dec 29, 2007 at 12:40:24PM +0100, Magnus Hagander wrote:
>> We already *do* allow the DBA to choose this, no? If you put the root
>> certificate on the client, it *will* verify the server cert, and it
>> *will* refuse to connect to a server that can't present
On Sat, Dec 29, 2007 at 12:40:24PM +0100, Magnus Hagander wrote:
> We already *do* allow the DBA to choose this, no? If you put the root
> certificate on the client, it *will* verify the server cert, and it
> *will* refuse to connect to a server that can't present a trusted root cert.
I think Tom'
Mark Mielke wrote:
> Tom Lane wrote:
>> Bruce Momjian <[EMAIL PROTECTED]> writes:
>>
>>> Agreed. Requiring client root certificate checking is heavy-handed.
>>>
>> There seems to be some confusion here. I didn't think anyone was
>> proposing that we force every installation to require cli
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
>> Agreed. Requiring client root certificate checking is heavy-handed.
>
> There seems to be some confusion here. I didn't think anyone was
> proposing that we force every installation to require client root
> certificate checking. Wha
Bruce Momjian wrote:
OK, updated paragraph:
It is possible to have authentication without encryption overhead by
using NULL-SHA or NULL-MD5 ciphers. However,
a man-in-the-middle could read and pass communications between client
and server. Also, encryption overhead is minimal c
Mark Mielke wrote:
> Bruce Momjian wrote:
> > Good point. I have added the last two sentences to the documentation
> > paragraph to highlight this issue:
> >
> >OpenSSL supports a wide range of ciphers
> >and authentication algorithms, of varying strength. While a list of
> >ciphers c
Tom Lane wrote:
Bruce Momjian <[EMAIL PROTECTED]> writes:
Agreed. Requiring client root certificate checking is heavy-handed.
There seems to be some confusion here. I didn't think anyone was
proposing that we force every installation to require client root
certificate checking. What
Bruce Momjian wrote:
Good point. I have added the last two sentences to the documentation
paragraph to highlight this issue:
OpenSSL supports a wide range of ciphers
and authentication algorithms, of varying strength. While a list of
ciphers can be specified in the OpenSSL
configur
Tomasz Ostrowski wrote:
> On Sun, 23 Dec 2007, Tom Lane wrote:
>
> > ISTM we have these action items:
> > 1. Improve the code so that SSL authentication can be used across a
> > Unix-socket connection (we can disable encryption though).
>
> I've just realised that there's a problem with SSL with
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Agreed. Requiring client root certificate checking is heavy-handed.
>
> There seems to be some confusion here. I didn't think anyone was
> proposing that we force every installation to require client root
> certificate checking. Wh
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Agreed. Requiring client root certificate checking is heavy-handed.
There seems to be some confusion here. I didn't think anyone was
proposing that we force every installation to require client root
certificate checking. What was under discussion (I t
Magnus Hagander wrote:
> We could make it so that we *require* the root certificate to be present
> on the client and make the check, and simply refuse to connect without
> it. But my guess is that it'll just increase the bar for SSL adoption at
> all, whilst most people will find some insecure way
Magnus Hagander wrote:
Mark Mielke wrote:
I have done this for my own application before. Although the client and
server use standard TLS 1.0 to speak to each other with a required
authentication of RSA 1024-bit and a required encryption of AES 128-bit,
it still requires that passwords sent
Mark Mielke wrote:
> Andrew Sullivan wrote:
>> On Fri, Dec 28, 2007 at 07:48:22AM -0800, Trevor Talbot wrote:
>>
>>> I don't follow. What are banks doing on the web now to force clients
>>> to authenticate them, and how is it any different from the model of
>>> training users to check the SSL ce
Andrew Sullivan wrote:
> On Fri, Dec 28, 2007 at 07:48:22AM -0800, Trevor Talbot wrote:
>> I don't follow. What are banks doing on the web now to force clients
>> to authenticate them, and how is it any different from the model of
>> training users to check the SSL certificate?
>
> Some banks (mos
Andrew Sullivan wrote:
On Fri, Dec 28, 2007 at 07:48:22AM -0800, Trevor Talbot wrote:
I don't follow. What are banks doing on the web now to force clients
to authenticate them, and how is it any different from the model of
training users to check the SSL certificate?
Some banks (mostly
On Fri, Dec 28, 2007 at 07:48:22AM -0800, Trevor Talbot wrote:
> I don't follow. What are banks doing on the web now to force clients
> to authenticate them, and how is it any different from the model of
> training users to check the SSL certificate?
Some banks (mostly Swiss and German, from what
On 12/28/07, Tom Lane <[EMAIL PROTECTED]> wrote:
> "Trevor Talbot" <[EMAIL PROTECTED]> writes:
> > There's a fundamental problem that you can't make someone else do
> > authentication if they don't want to, and that's exactly the situation
> > clients are in. I don't see how this can possibly be f
"Trevor Talbot" <[EMAIL PROTECTED]> writes:
> There's a fundamental problem that you can't make someone else do
> authentication if they don't want to, and that's exactly the situation
> clients are in. I don't see how this can possibly be fixed anywhere
> other than the client.
The point of requi
On 12/28/07, Andrew Sullivan <[EMAIL PROTECTED]> wrote:
> On Sat, Dec 29, 2007 at 02:09:23AM +1100, Naz Gassiep wrote:
> > In the web world, it is the client's responsibility to ensure that they
> > check the SSL cert and don't do their banking at
> > www.bankofamerica.hax0r.ru and there is nothin
On Sat, Dec 29, 2007 at 02:09:23AM +1100, Naz Gassiep wrote:
> In the web world, it is the client's responsibility to ensure that they
> check the SSL cert and don't do their banking at
> www.bankofamerica.hax0r.ru and there is nothing that the real banking
> site can do to stop them using their
The problem with forcing authentication is that an auth-unaware client
connecting to a legitimate postmaster would have its connections
refused. That same client would have its connections accepted by an
impostor postmaster. Thus, there is no way to stop impostor postmasters
from carrying out t
On Thu, 27 Dec 2007, Stephen Frost wrote:
Debian also has SELinux, if one wishes to configure it. I suspect other
Debian-derived distributions also have it as a result. It can certainly
be a pain to configure but it's far from impossible
That's a good summary. As of Debian Etch (April of t
Stephen Frost wrote:
> It'd be really nice to be able to have client-side certificates used for
> authentication by having a way to associate a certificate (or maybe at
> least the DN, but you can have dups) to a user. That's a seperate
> conversation tho, really.
Absolutely, but as you say a com
* Tom Lane ([EMAIL PROTECTED]) wrote:
> Most Linux distros don't have SELinux, AFAIK, so this is probably not a
> very useful suggestion. Not that I have a problem with Red-Hat-specific
> solutions ;-)
Debian also has SELinux, if one wishes to configure it. I suspect other
Debian-derived distrib
Tom Lane wrote:
> Andrew Dunstan <[EMAIL PROTECTED]> writes:
>> I have no problem with that. But it does seem to me that we are going
>> about this all wrong. The OP proposed a "solution" which was intended to
>> ensure at the server end that an untrusted user could not spoof the
>> postmaster i
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> I have no problem with that. But it does seem to me that we are going
> about this all wrong. The OP proposed a "solution" which was intended to
> ensure at the server end that an untrusted user could not spoof the
> postmaster if the postmaster were
Tom Lane wrote:
Magnus Hagander <[EMAIL PROTECTED]> writes:
Sure. But we *do* provide a way to work around it *if you have to*: use
SSL with trusted certificates. In the large number of cases where you
*don't* need to worry about it, there's no need to add any extra overhead.
And
Magnus Hagander <[EMAIL PROTECTED]> writes:
> Sure. But we *do* provide a way to work around it *if you have to*: use
> SSL with trusted certificates. In the large number of cases where you
> *don't* need to worry about it, there's no need to add any extra overhead.
> And if you're going with SSL
Magnus Hagander wrote:
> > How expensive would it be to implement a "server_user" db open parameter
> > that would perform reverse credential passing to validate? "dbname=XXX
> > port=5432 server_user=postgres". If the server can't prove it is
> > postgres through UNIX socket credential passing, it
Tomasz Ostrowski wrote:
> On Sun, 23 Dec 2007, Tom Lane wrote:
>> 3. Massive confusion and breakage as various people transition to the
>> new standard at different times.
>
> As with any major version.
No, it would introduce a client/server incompatibility. Generally, older
clients (libpq) will
Mark Mielke wrote:
> I prefer UNIX sockets with kernel credential passing over TCP/IP with
> username/password or the more expensive SSL. I do not like storing
> passwords or private certificates in a place available to the web user,
> as other web users would then also have access. I do not have e
Andrew Sullivan wrote:
> On Sun, Dec 23, 2007 at 09:52:14PM +0100, Magnus Hagander wrote:
>> My point is that all these other server products have the exact same
>> issue. And that they deal with it the exact same we do - pretty much
>> leave it up to the guy who configure the server to realize tha
On Sun, Dec 23, 2007 at 01:45:14AM -0500, Tom Lane wrote:
>
> The primary reason things work like that is that there are boatloads of
> machines that are marginally misconfigured. For instance, userland
> thinks there is IPv6 support when the kernel thinks not (or vice versa).
Not only "marginal
On Mon, Dec 24, 2007 at 12:04:16AM +0100, Tomasz Ostrowski wrote:
>
> Not at all, as it won't run as root, it'll just start as root and
> then give up all root privileges. The only thing it would have after
> being root is just an open socket.
If you think that is complete protection against priv
On Sun, Dec 23, 2007 at 09:52:14PM +0100, Magnus Hagander wrote:
> My point is that all these other server products have the exact same
> issue. And that they deal with it the exact same we do - pretty much
> leave it up to the guy who configure the server to realize that's just
> how things work.
On Sun, 23 Dec 2007, Tom Lane wrote:
> ISTM we have these action items:
> 1. Improve the code so that SSL authentication can be used across a
> Unix-socket connection (we can disable encryption though).
I've just realised that there's a problem with SSL with disabled
encryption on a unix socket /
Bruce Momjian wrote:
> Tom Lane wrote:
> > 2. Improve our documentation about how to set up mutual authentication
> > under SSL (it's a bit scattered now).
> >
> > 3. Recommend using mutual auth even for local connections, if a server
> > containing sensitive data is to be run on a machine that al
Tom Lane wrote:
> 2. Improve our documentation about how to set up mutual authentication
> under SSL (it's a bit scattered now).
>
> 3. Recommend using mutual auth even for local connections, if a server
> containing sensitive data is to be run on a machine that also hosts
> untrusted users.
>
>
Bruce Momjian wrote:
Mark Mielke wrote:
I agree - I forgot there were different flavours. I think any of these
are just as good as SSL with public key authentication, and perhaps a
lot cheaper in terms of performance. The only piece of information
missing is the uid to compare against, wh
Mark Mielke wrote:
> Gregory Stark wrote:
> > "Mark Mielke" <[EMAIL PROTECTED]> writes:
> >
> >> UNIX socket kernel credential passing was mentioned in an earlier post,
> >> but I
> >> didn't see it raised again.
> >>
> >
> > I mentioned getsockopt(SO_PEERCRED) which isn't the same as cre
Tomasz Ostrowski wrote:
> > Fundamentally these are man-in-the-middle attacks, and the only real
> > solution is mutual authentication.
>
> The problem is not many people expect man-in-the-middle attack on
> secure lan, localhost or local socket connection, so they'll not try
> to prevent it.
Agr
Mike Rylander wrote:
> On Dec 22, 2007 1:04 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
> > Peter Eisentraut <[EMAIL PROTECTED]> writes:
> > > Wouldn't SSL work over Unix-domain sockets as well? The API only deals
> > > with
> > > file descriptors.
> >
> > Hmm ... we've always thought of SSL as being
Gregory Stark wrote:
"Mark Mielke" <[EMAIL PROTECTED]> writes:
UNIX socket kernel credential passing was mentioned in an earlier post, but I
didn't see it raised again.
I mentioned getsockopt(SO_PEERCRED) which isn't the same as credential
passing. It just tells you what uid is on the
"Mark Mielke" <[EMAIL PROTECTED]> writes:
> UNIX socket kernel credential passing was mentioned in an earlier post, but I
> didn't see it raised again.
I mentioned getsockopt(SO_PEERCRED) which isn't the same as credential
passing. It just tells you what uid is on the other end of your unix doma
Stephen Frost wrote:
* Trevor Talbot ([EMAIL PROTECTED]) wrote:
There are various platform-specific security features that might be
useful, like reserved port ranges and file permissions, but they are
so specific to the scenario they're designed for that it's hard to
create a generic solution
* Trevor Talbot ([EMAIL PROTECTED]) wrote:
> There are various platform-specific security features that might be
> useful, like reserved port ranges and file permissions, but they are
> so specific to the scenario they're designed for that it's hard to
> create a generic solution that works well by
On Sun, 23 Dec 2007, Tom Lane wrote:
> IIRC, you started out your argument by also saying that we had to move
> the TCP socket to the reserved range, so as to prevent the equivalent
> problem in the TCP case.
>
> 1. Postmaster must be started as root, thereby introducing security
> risks of its o
On 12/23/07, Tomasz Ostrowski <[EMAIL PROTECTED]> wrote:
> On Sun, 23 Dec 2007, Magnus Hagander wrote:
> > I'm just surprised that people are actually surprised by this. To me,
> > it's just a natural fact that happens to pretty much all systems. And a
> > good reason not to let arbitrary users ru
Martijn van Oosterhout <[EMAIL PROTECTED]> writes:
> On Sun, Dec 23, 2007 at 04:43:54PM -0500, Tom Lane wrote:
>> use of
>> postmasters running under different userids for another.
> This is specifically allowed and I mentioned it in the email you
> responded to, so I don't understand why you thi
Tom Lane wrote:
> Tomasz Ostrowski <[EMAIL PROTECTED]> writes:
>> So I'm not very fond of this "insecure by default, it's your problem
>> to make it secure" attitude. I'm the one who reported this.
>
> IIRC, you started out your argument by also saying that we had to move
> the TCP socket to the r
On Sun, Dec 23, 2007 at 04:43:54PM -0500, Tom Lane wrote:
> use of
> postmasters running under different userids for another.
This is specifically allowed and I mentioned it in the email you
responded to, so I don't understand why you think it's not possible.
Usage: /usr/bin/pg_createcluster [op
Tomasz Ostrowski <[EMAIL PROTECTED]> writes:
> So I'm not very fond of this "insecure by default, it's your problem
> to make it secure" attitude. I'm the one who reported this.
IIRC, you started out your argument by also saying that we had to move
the TCP socket to the reserved range, so as to pr
Martijn van Oosterhout <[EMAIL PROTECTED]> writes:
> On Sun, Dec 23, 2007 at 02:52:28PM -0500, Tom Lane wrote:
>> "Problem"? What we mustn't lose sight of is that that's not a bug but
>> a feature. It would be completely inappropriate for us as upstream to
>> destroy that property, and my fundame
On Sun, 23 Dec 2007, Magnus Hagander wrote:
> I'm just surprised that people are actually surprised by this. To me,
> it's just a natural fact that happens to pretty much all systems. And a
> good reason not to let arbitrary users run processes that can bind to
> something on your server.
Not eve
Kurt Roeckx <[EMAIL PROTECTED]> writes:
> On Sun, Dec 23, 2007 at 02:52:28PM -0500, Tom Lane wrote:
>> a feature. It would be completely inappropriate for us as upstream to
>> destroy that property, and my fundamental objection to what Debian
>> has done is that they've destroyed that property at
On Sun, Dec 23, 2007 at 02:52:28PM -0500, Tom Lane wrote:
> "Problem"? What we mustn't lose sight of is that that's not a bug but
> a feature. It would be completely inappropriate for us as upstream to
> destroy that property, and my fundamental objection to what Debian
> has done is that they've
On Sun, Dec 23, 2007 at 02:52:28PM -0500, Tom Lane wrote:
> Gregory Stark <[EMAIL PROTECTED]> writes:
> > Bruce summarized the problem pretty well when he said that if Postgres
> > is being run as a non-root user then one non-root user's "postgres" is
> > as good as any other non-root user's "postg
Tom Lane wrote:
> Magnus Hagander <[EMAIL PROTECTED]> writes:
>> Am I missing something here, or did you just post
>> a piece of configure that *agreed* with what I said? ;-)
>
> Maybe I misread what you said. I thought you were claiming that mysql
> do this more securely than we do; which they d
Magnus Hagander <[EMAIL PROTECTED]> writes:
> Am I missing something here, or did you just post
> a piece of configure that *agreed* with what I said? ;-)
Maybe I misread what you said. I thought you were claiming that mysql
do this more securely than we do; which they don't. But looking back,
Gregory Stark <[EMAIL PROTECTED]> writes:
> Bruce summarized the problem pretty well when he said that if Postgres
> is being run as a non-root user then one non-root user's "postgres" is
> as good as any other non-root user's "postgres".
"Problem"? What we mustn't lose sight of is that that's no
Tom Lane wrote:
> Magnus Hagander <[EMAIL PROTECTED]> writes:
>> Peter Eisentraut wrote:
>>> These services either use a protected port or a protected directory, or they
>>> support SSL or something similar (SSH), or they are deprecated, as many
>>> traditional Unix services are. If you find a se
Magnus Hagander <[EMAIL PROTECTED]> writes:
> Peter Eisentraut wrote:
>> These services either use a protected port or a protected directory, or they
>> support SSL or something similar (SSH), or they are deprecated, as many
>> traditional Unix services are. If you find a service that is not cove
On Sun, 23 Dec 2007 07:57:07 +
Gregory Stark <[EMAIL PROTECTED]> wrote:
> "D'Arcy J.M. Cain" <[EMAIL PROTECTED]> writes:
> > It's generally a bad idea to put your database on a public server
> > anyway but if you do you should definitely disable unix domain sockets
> > and connect over TCP to l
Bruce Momjian wrote:
"I can't start with the configuration you've given me, so I won't
start at all" is fairly normal behaviour for a server process, no?
Yes, we have talked about this in the past and there were concerns that
that the server might have some network problem that would pre
Martijn van Oosterhout wrote:
> On Sat, Dec 22, 2007 at 02:21:42PM -0500, Tom Lane wrote:
>> No, we shouldn't, and if I had any authority over them I would make
>> Debian stop doing that. It amounts to a unilateral distro-specific
>> change in the protocol, and I think it makes things *less* secur
Peter Eisentraut wrote:
> Magnus Hagander wrote:
>>> Most kinds of server processes where you'd send sensitive information do
>>> support SSL. Most of these server processes don't run over Unix-domain
>>> sockets, though.
>> Well, the question is not about sensitive information, is it? It's about
On Sat, Dec 22, 2007 at 02:21:42PM -0500, Tom Lane wrote:
> No, we shouldn't, and if I had any authority over them I would make
> Debian stop doing that. It amounts to a unilateral distro-specific
> change in the protocol, and I think it makes things *less* secure,
> because any clients who are ex
Magnus Hagander wrote:
> > Most kinds of server processes where you'd send sensitive information do
> > support SSL. Most of these server processes don't run over Unix-domain
> > sockets, though.
>
> Well, the question is not about sensitive information, is it? It's about
> password disclosure du
Magnus Hagander wrote:
> Well, the question is not about sensitive information, is it? It's about
> password disclosure due to spoofing. Which would affect *all* services
> that accept passwords over any kind of local connections - both unix
> sockets and TCP localhost.
>
> I'm just saying that p
Magnus Hagander wrote:
> The server doesn't need a root.crt certificate really - but it does need
> the *server* certificate (server.key/server.crt). root.crt is only used
> to verify *client* certificates, which is a different thing from what
> you're outlining here.
Updated:
http://momj
Peter Eisentraut wrote:
> Bruce Momjian wrote:
> > Bruce Momjian wrote:
> > > I think at a minimum we need to add documentation that states if you
> > > don't trust the local users on the postmaster server you should:
> > >
> > > o create unix domain socket files in a non-world-writable
> > >
Peter Eisentraut wrote:
> Magnus Hagander wrote:
>> Out of curiosity, does any of the other databases out there "solve" this
>> somehow? Or any non-databases too, really. To me this seems like a
>> general problem for *any* kind of server processes
>
> Most kinds of server processes where you'd se
Magnus Hagander wrote:
> Out of curiosity, does any of the other databases out there "solve" this
> somehow? Or any non-databases too, really. To me this seems like a
> general problem for *any* kind of server processes
Most kinds of server processes where you'd send sensitive information do
supp
Bruce Momjian wrote:
> Brendan Jurd wrote:
>> On Dec 23, 2007 1:25 PM, Bruce Momjian <[EMAIL PROTECTED]> wrote:
>>> I have written documentation for this item:
>>>
>>> http://momjian.us/tmp/pgsql/server-shutdown.html#SERVER-SPOOFING
>>>
>>> Comments?
>> I thought the content made sense, but
Bruce Momjian wrote:
> Bruce Momjian wrote:
> > I think at a minimum we need to add documentation that states if you
> > don't trust the local users on the postmaster server you should:
> >
> > o create unix domain socket files in a non-world-writable
> >directory
> > o require SS
"D'Arcy J.M. Cain" <[EMAIL PROTECTED]> writes:
> On Sat, 22 Dec 2007 09:25:05 -0500 (EST)
> Bruce Momjian <[EMAIL PROTECTED]> wrote:
>> I think at a minimum we need to add documentation that states if you
>> don't trust the local users on the postmaster server you should:
>>
>> o create uni
"Tom Lane" <[EMAIL PROTECTED]> writes:
> "Marko Kreen" <[EMAIL PROTECTED]> writes:
>> (FYI - Debian already puts unix socket to directory writable
>> only to postgres user, so they dont have the problem. Maybe
>> we should encourage distros to move away from /tmp?)
>
> No, we shouldn't, and if I
Mark Mielke <[EMAIL PROTECTED]> writes:
> Brendan Jurd wrote:
>> It doesn't solve the spoofing attack problem, but isn't Gurjeet's idea
>> a good one in any case?
>>
> What makes it good? It solves no problems. It prevents the server from
> coming up when it otherwise might still be able to.
The
Brendan Jurd wrote:
It doesn't solve the spoofing attack problem, but isn't Gurjeet's idea
a good one in any case?
What makes it good? It solves no problems. It prevents the server from
coming up when it otherwise might still be able to.
If the postmaster can't bind on one of the specified
1 - 100 of 118 matches
Mail list logo
