Re: [HACKERS] Query cancel and OOB data (fwd)

> > Bruce Momjian <maillist(at)candle(dot)pha(dot)pa(dot)us> writes:
> > >> However, if they are already snooping, how much harder
> > >> is it for them to insert their own query into the tcp stream?
> >
> > > Can someone answer this for me?
> >
> > Well, that depends entirely on what your threat model is --- for
> > example, someone with read access on /dev/kmem on a relay machine
> > might be able to watch packets going by, yet not be able to inject
> > more. On the other hand, someone with root privileges on another
> > machine on your local LAN could likely do both.
> >
> > My guess is that most of the plausible cases that allow one also
> > allow the other. But it's only a guess.
>
> Ok, I agree. If someone sees the cancel secret going over the wire,
> they almost just as easily can send their own query on the wire.
> Remember, the cancel is going directly to the postmaster as a separate
> connection, so it is a little easier than spoofing a packet.
>
> So, with that decided, the only issue is how the postmaster should
> generate the random key. Currently, to get the password salt, which
> does not have to be un-guessable, RandomSalt() seeds the random number
> generator with the current time, and then just continues to call random.

Just do time and pid. But get the time from gettimeofday so it will be
down to the millisecond or so. Anything more is overkill for this application.

> If we continue that practice, someone can guess the first cancel
> password by finding out when the first postgres backend needed a random
> number, and use that time in seconds to figure out the new random
> number. We could load/save the seed on postmaster start/exit, and
> somehow seed that value during install or initdb. Perhaps the
> completion time of initdb can be used. Maybe a:
>
> 'date +%s' >/pgsql/data/pg_random
>
> and have the postmaster load it on startup, and write it on exit.
> Because initdb takes some time to run, we could put it in between two of
> the initdb commands that take some time to run. Their timestamp of
> activity is burried in pgsql/data and only postgres read-able.
>
> Comments?

See Mr Dodds excellent post. This is getting too elaborate.

One possibility, make it configurable to allow cancels at all. Then if
someone really had a spurious cancel problem they could work around it by
turning cancels off.

But hey, I think we should just use TCP only and then we could count on OOB.

Btw, on my P166 at work, lmbench says Linux 2.1.101 can do round trip tcp
in 125 microseconds. That is pretty quick.

-dg

David Gould dg(at)illustra(dot)com 510.628.3783 or 510.305.9468
Informix Software 300 Lakeside Drive Oakland, CA 94612
- A child of five could understand this! Fetch me a child of five.