On Sun, Jan 13, 2013 at 07:01:07PM -0500, Noah Misch wrote: > On Sun, Jan 13, 2013 at 05:46:12PM -0500, Tom Lane wrote: > > Marko Kreen <mark...@gmail.com> writes: > > > On Fri, Dec 21, 2012 at 10:27 PM, Noah Misch <n...@leadboat.com> wrote: > > >> How about instead calling RAND_cleanup() after each backend fork? > > > > > Attached is a patch that adds RAND_cleanup() to fork_process(). > > > > I remain unconvinced that this is the best solution. Anybody else have > > an opinion? > > I'd describe it as the clearly-secure solution. The biggest hazard I see is > the drain on system entropy. A system having only a blocking /dev/random > could suddenly find itself entropy-exhausted after installing the minor > upgrade. Backends could block waiting for system entropy to accumulate. > That's not directly a problem on Linux. However, if other programs on the > system read from /dev/random, the pressure from PostgreSQL's /dev/urandom > usage may make those programs wait longer for entropy. > > I'm also comfortable with the security of Marko's original proposal, modulo it > happening in each backend shortly after fork, not merely in pgcrypto. > OpenSSL's ssl module uses a similar method, and one of the papers I cited > describes it. (If anything, OpenSSL is less cautious. It uses time(), not > gettimeofday().) The performance characteristics of this approach are easier > to guess: one system call if we use MyProcPid + gettimeofday(), zero if we use > MyProcPid + MyStartTime. > > You proposed mixing gettimeofday() into the postmaster's entropy pool after > each fork. I wouldn't be too concerned if we did it that way, but my quick > literature review did not turn up any similar ideas. Given that this is > strictly more expensive than the previous method, I don't recommend it. > > Overall, I'd recommend mixing in MyProcPid and MyStartTime after each fork.
I neglected to ping this for the last back-branch releases. May we adopt one of the above fixes and issue a CVE with the next releases? Though I've stated my preference, all three proposals would be major improvements over the present, quietly-vulnerable state. Thanks, nm -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
