[squid-dev] Efficient FD annotations

[Amos Jeffries]

On 8/01/20 3:39 am, Alex Rousskov wrote:
> On 1/7/20 1:39 AM, Amos Jeffries wrote:
>> On 7/01/20 4:28 am, Alex Rousskov wrote:
>>> For the record: The ideas below are superseded by the concept of the
>>> code context introduced in commit ccfbe8f, including the
>>> fde::codeContext field. --Alex
> 
>> If you want to go that way (replace fde:note with fde:codeContext)
> 
> I would not replace fde::note with fde::codeContext. I would keep
> fde::note as a basic indication of the current FD purpose/scope. This
> can be done cheaply using string literals or constant SBufs.
> 

In that case, why is this thread being revived?
AIUI your proposals were alternatives to PR 270 - ways to replace the
fde::note field instead of just updating it to SBuf.


> 
>> we are going to have to do a security audit on the values displayed
>> by the CodeContext objects. That is due to how the fde::note are sent
>> over the public network in clear-text transactions for
>> mgr:filedescriptors report.
> 
> Overall, I doubt such an audit is a good idea -- only the Squid admin
> can correctly decide whether it is OK to expose transaction information
> in cache manager responses[1,2].

see responses below to [1] and [2]. Since you are apparently not seeking
to replace the mgr:filedescriptors report fde::note field with
fde::codeContext display - then please take it as a general security
approach policy for handling that type of change.



> If there is demand for limiting that
> exposure, I would rather add a configuration directive that would allow
> the admin to control whether Squid is allowed to report context in cache
> manager responses, error pages, etc.

We do not have to default such an option to publish everything on the
off chance it is safe. Our objective here is to prevent CVEs occuring.
To achieve that we should be defaulting to elide sensitive details from
public view unless configured to show them.

The details I am thinking of most prominently here are things like
credentials and tokens in the auth processing contexts. URL history and
keys in the SSL-Bump context. Access to Squid internal memory spaces on
the server. There are probably others we will uncover later. Anything
that could be reported as a sensitive information leak and assigned a CVE.


> 
> Alex.
> 
> [1] Some of the transaction context is already exposed in the current
> cache manager responses. We may want to add more details or report fewer
> details, but there is no paradigm shift here.

"some" renders this argument irrelevant. The leak issues will be
cropping up about the *new* data if we let that contain anything sensitive.

The purpose of audit is to retrospectively check the those not-yet
published details are safe for publishing. It will either find
everything is OK as-is, or that we need to add a censoring print
operator for publicly visible displays to use.


> 
> [2] In some deployment environments, cache manager responses are
> delivered over secure channels.
> 

"some" renders this argument irrelevant. The leak issues will be
cropping up where they are *not* secured.


Amos