On 11/11/2020 18:31, Chris Siebenmann via Exim-users wrote:
> Jeremy Harris:
>>> Semi-radical: provide an ACL, router, and transport modifier that
>>> checks some variable or content for dangerous contents
>> We have that. All data provided by an untrusted source, described
>> as "tainted" for a shorthand.
> Tainted variables contain potentially dangerous contents, not actually
> dangerous contents. Most of the time, the contents of tainted variables
> are not dangerous, but sometimes they are. I think that it would be
> useful for Exim to provide assistance in telling the two apart.
>
> I say this because I strongly believe that people are going to
> write Exim configuration code that de-taints variables in brute
> force ways (and the more that Exim doesn't provide mechanisms to
> do relatively arbitrary 'safe' de-tainting, the more that people
> are going to do so). I think it's relatively important to let
> people guard these de-taintings with safety checks, such as 'is
> there dangerous content here'.
>
> Also, even with relatively safe de-tainting, sometimes I would rather
> reject funny content immediately. This is actually a relatively popular
> thing to do today in ad-hoc ways; for example, the Debian 'split' Exim
> configuration has for years shipped with a set of checks for dangerous
> characters in local parts. Sysadmins can maybe write these checks
> in Exim configurations themselves, but in ad-hoc ways and sysadmins
> probably don't know as much about what things are dangerous (or valid)
> in various conditions as other people do.
>
> - cks
>
I have read all of the contributions to this discussion with interest
and there are clearly contradictions between:
* implementing good security
* not breaking existing existing installations
* simplicity for users and maintainers
* avoiding giving people guns for them to shoot themselves in the foot
* ending up with cargo-cult answers on Stack Exchange
We also know that inertia in the community often means that deployment
and distros are 12-18 months or more behind the 'head' version.
We don't know how many installations of Exim are out there - perhaps
hundreds of thousands or more. An abrupt change could be highly
problematic and also cause reputational damage.
Here's a proposal for a compromise in an attempt to satisfy these,
competing, requirements with a phased approach:
1. Publish a roadmap for Exim - likely things to arrive in 4.95, 4.96,
4.97 ... and that there will be an Exim 5.0 out in roughly XX months.
This doesn't have to be stuck to - its forward looking not a 'promise'
but can include item (5) below.
2. Keep the tainted data model as it is now
3. Don't give the user's new untaint methods that fix one thing and
potentially break another, e.g. internationalisation
4. Document tainted data more fully:
* what tainted data is
* what can go wrong if you trust it when you shouldn't
* why you need to change
* examples of configurations and recommendations
Ensure the documentation includes the road-signs to the right way
to do things to avoid cargo-cult
5. Add a new config variable:
taint_mode = warn | enforce
which is initially defaults to 'warn' and which bleaches to
mainlog/paniclog or even stdout on start warning:
a) of the perils of tainted data;
b) tells the user this this feature is going to be removed in a
future release
c) points to the documentation (3)
Eg:
Exim: Configuration uses tainted data which is currently allowed
may be dangerous. This will be removed in a future release. For info see
https://exim.org/tainted_data.html
At some later release (4.96, 4.97 ?) switch from the default of
'warn' to the default of 'enforce', effectively allowing the user to
swim against the tide by switching back to 'warn' if they must.
Implement the taint_mode with a sun-set, i.e planned removal at
Exim 5.0.
6. Implement Jeremy's relatively light weight:
${if tainted{my_suspect_expansion} {expand_this} {expand_that}}
Which he said would be simple to code and test and allow some
workarounds to be implemented for some use cases.
7. Publicity.
Mike
