Re: [exim] tainted data issues

Page principale
Supprimer ce message
Répondre à ce message
Auteur: Chris Siebenmann
Date:  
À: Sebastian Nielsen
CC: Mailing List
Sujet: Re: [exim] tainted data issues
> Yes, but its a positive match only - meaning you have to explicitly
> specify allowed characters.The function should NOT be able to
> specify forbidden characters - as then it would ve easy to miss bad
> characters.If an sysadmin then writes a filter which is too broad -
> its his own fault.


History has vividly demonstrated that providing a toolkit and asking
people to build their own secure implementation from it does not create
effective security (although it does let you blame a different set of
people for the resulting insecurity). Many people will either make
mistakes or not know all of the surprises and traps that are lurking,
and so won't know to counter them.

Effective security is almost always created by a few people who know
the area very well spending a bunch of time to thoroughly explore all
of the dark corners, then building something with as few options as
possible (ideally none).

Or to put it another way: I feel that people should not need to be
experts in knowing what are safe and dangerous characters and character
sequences in order to create safe Exim configurations. If they have
to be such experts, there will be a lot of unsafe Exim configurations
created.

I think it's potentially sensible to provide an escape hatch, but
I don't think that it should be the only way to do it; I think it
should only be something that you resort to if you have highly unusual
needs. And I share Jeremy Harris's worry that it will be cargo-culted
and copied widely, even then.

(Possibly unlike Jeremy Harris, I feel that if Exim provides no such
safe-ish general un-tainting, people will still find ways to do it and
then cargo-cult it. People are going to cargo-cult answers for this; the
only question is whether Exim can help make that as safe as possible.)

    - cks