Re: dblink connection security
От | Stephen Frost |
---|---|
Тема | Re: dblink connection security |
Дата | |
Msg-id | 20070709183352.GY4887@tamriel.snowman.net обсуждение исходный текст |
Ответ на | Re: dblink connection security (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-patches |
* Tom Lane (tgl@sss.pgh.pa.us) wrote: > Joe Conway <mail@joeconway.com> writes: > > But if you know of a security risk related to using libpq > > with a password authenticated connection, let's hear it. > > As near as I can tell, the argument is that dblink might be used to send > connection-request packets to random addresses. Now this is only a Yes. > security issue if the attacker could not have reached such an address > directly; otherwise he might as well send the packet himself (and have a No. Being able to come from a different address is valuable even if you can get to that address directly yourself. > lot more control over its content). So I guess the scenario is that > you're running your database on your firewall machine, where it is > accessible from outside your net but also can reach addresses inside. It wouldn't need to be "on your firewall", just behind it, which is extremely common. > And you're letting untrustworthy outside people log into the database. It's not nearly so convoluted. SQL injections happen. > And you put dblink on it for them to use. And even then, the amount of > damage they could do seems pretty limited due to lack of control over > the packet contents. dblink could have been installed for a variety of reasons. Making it openly available on install makes it much less likely any additional restrictions were placed on it. > To me this scenario is too far-fetched to justify sacrificing > convenience and backwards compatibility. It should be sufficient to add > some paragraphs about security considerations to the dblink docs. I feel that requiring a sysadmin to issue a 'grant' if they want that convenience is justified and reasonable. We could include the statement itself in the documentation we're expecting them to read anyway so they can just copy & paste it. Adding paragraphs to the documentation is good but doesn't justify a insecure-by-default approach. Regardless of what core ends up doing, I'm hopeful it'll be disabled by default under Debian. It'd certainly be easier if it was done upstream. Thanks, Stephen
Вложения
В списке pgsql-patches по дате отправления: