(2010/10/13 22:43), Tom Lane wrote:
> Robert Haas<robertmhaas@gmail.com> writes:
>> With the possible exception of Tom,
>> everyone seems to agree that it would be a good step forward to
>> provide a way of plugging these holes, even if it didn't cover subtler
>> information leaks such as by reading the EXPLAIN output or timing
>> query execution.
>
>> 1. Does anyone wish to argue (or continue arguing) that plugging these
>> more overt information leaks is not worthwhile?
>
> Yeah, I will. Plugging an "overt" information leak without plugging
> other channels in the same area isn't a security improvement. It's
> merely PR, and rather lame PR at that. An attacker is not bound to
> use only the attack methods you'd like him to.
>
It seems to me an extreme opinion, and different from the standard
point of security view.
It is a quotation from the classic of security evaluation criteria.
Trusted Computer System Evaluation Criteria (TCSEC, DoD) says in
the chapter of "A GUIDELINE ON COVERT CHANNELS" as follows:
http://csrc.nist.gov/publications/history/dod85.pdf
| From a security perspective, covert channels with low bandwidths represent a
| lower threat than those with high bandwidths. However, for many types of
| covert channels, techniques used to reduce the bandwidth below a certain rate
| (which depends on the specific channel mechanism and the system architecture)
| also have the effect of degrading the performance provided to legitimate
| system users. Hence, a trade-off between system performance and covert
| channel bandwidth must be made
The "overt" channels has a capability to leak massive invisible information,
so we need to consider them as a serious threat to be fixed up in higher
priority.
However, it is doubtful whether the rest of channels provides enough
bandwidth as actual threat. It also means degree of the threat is
relatively small than the "overt" channels.
Previous security researcher pointed out security is trading-off,
not all-or-nothing. If we can plug most part of the threat with
reasonable performance degrading, it is worthwhile to fix up.
Thanks,
--
KaiGai Kohei <kaigai@kaigai.gr.jp>