Re: Spoofing as the postmaster
От | Mark Mielke |
---|---|
Тема | Re: Spoofing as the postmaster |
Дата | |
Msg-id | 476F2E34.2010809@mark.mielke.cc обсуждение исходный текст |
Ответ на | Re: Spoofing as the postmaster (Stephen Frost <sfrost@snowman.net>) |
Ответы |
Re: Spoofing as the postmaster
Re: Spoofing as the postmaster |
Список | pgsql-hackers |
Stephen Frost wrote: <blockquote cite="mid:20071224005932.GH5031@tamriel.snowman.net" type="cite"><pre wrap="">* TrevorTalbot (<a class="moz-txt-link-abbreviated" href="mailto:quension@gmail.com">quension@gmail.com</a>) wrote: </pre><blockquotetype="cite"><pre wrap="">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 default -- especially if you want to run without requiring administrative privileges in the first place. </pre></blockquote><pre wrap="">Agreed. A guarentee that the process listening on a particular port is what you're expecting isn't something that upstream can give. It needs to be done through some situation-specific mechanism. There are a number of options here, of course: SSL, Kerberos, SELinux, even things like the tiger IDS. Reserved ports really aren't all that great a solution in the end anyway, to be honest. </pre></blockquote> UNIX socket kernel credential passing was mentioned in an earlierpost, but I didn't see it raised again. All of the above mechanisms still require a piece of information to validate"trust". SSL requires a copy of the public certificate. UNIX socket credential passing would be much cheaper to validate- all it requires is the userid or username.<br /><br /> I prefer UNIX sockets with kernel credential passing overTCP/IP with username/password or the more expensive SSL. I do not like storing passwords or private certificates in aplace available to the web user, as other web users would then also have access. I do not have evidence, but I am underthe impression that the TCP/IP stack incurs additional overhead on connect(), send(), recv(), and close() than UNIXsockets.<br /><br /> Yes, Java doesn't work with UNIX sockets - but both Perl and PHP do. The only reason Java doesn'tis because Java itself doesn't support UNIX sockets, and the Java JDBC provider is pure-Java.<br /><br /> How expensivewould 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 credentialpassing, it fails. Similarly, identd may be usable in reverse? I've seen many people claim identd is insecure -but it is secure if I am the one running it, is it not?<br /><br /> Cheers,<br /> mark<br /><br /><pre class="moz-signature"cols="72">-- Mark Mielke <a class="moz-txt-link-rfc2396E" href="mailto:mark@mielke.cc"><mark@mielke.cc></a> </pre>
В списке pgsql-hackers по дате отправления: