Developers of Sympa

[IKEDA Soji <address@concealed>]

On Mon, 28 Jul 2014 16:38:28 +0200
Guillaume Rousse <address@concealed> wrote:

> Le 22/07/2014 09:59, IKEDA Soji a écrit :
> > Guillaume,
> >
> > On Tue, 22 Jul 2014 09:28:02 +0200
> > Guillaume Rousse <address@concealed> wrote:
> >
> >> Le 22/07/2014 03:58, IKEDA Soji a écrit :
> >>> Hi,
> >>>
> >>> I prefer to on-memory processing.  I suppose secure information such
> >>> as private keys would not be unneccessarily written into storage if
> >>> at all possible --- even if they are removed soon, random blocks of
> >>> disk will keep information --- let alone passphrases.
> >> If you're able to access the content of a file owned by Sympa uid, with
> >> owner-only read permission, you may as well read sympa configuration
> >> file directly, where this password is also available. So why bother with
> >> a FIFO here ?
> >
> > For example, imagine a user replaced her Sympa server and want to
> > dispose older machine including disks.
> >
> > Passphrases are stored into specific volume as config parameters.
> > So this volume should be paid special attention.  However, if
> > passphrase had repeatedly been saved into other volumes, they should
> > be treated as carefully as former should be.
> That's an hypotetical scenario.
> 
> What's not hypotetical, hovewer, is that using FIFOs instead of plain 
> old files makes the code slightly more complex (see attached patch, 
> restoring old behaviour). And even worse, when computing temporary file 
> name before creating them, you're also facing a whole set of security 
> issues, generally refered as 'time-to-check-vs-time-to-use' (see various 
> warnings in File::Temp manual). The usual way to avoid those problems is 
> to use atomic operations (create file name and open file handle at 
> once), which is unfortunatly not possible with FIFOs.
> 
> Basically, trading disk writes for race conditions doesn't constitute a 
> proven security improvement, just a change between two different 
> situations impossible to compare. All things equal, I prefer the 
> simplest implementation. Especially for such kind of corner cases as 
> password-protected secrets requiring to store password in clear-text 
> somewhere else...

# The phrase "I cannot answer a hypothetical question" is usual
# play of bureaucratic people.  Could you please stop such a
# offensive reply?

Besides, I just presented _an example_ for a contrapositive of
Kerckhoffs's principle: Private key must not fall into enemy hands.

For more example, it may not be our pleasure that a company refrain
from adopting Sympa based on code audit by them, isn't it?

> > FIFO (I don't stick to this method, though) does not store
> > passed information to any perpetual storages.  I suppose that is why
> > openssl supports FIFO.
> openssl doesn't make any difference between a regular file and a fifo 
> for this matter, but this doesn't change much here.

BTW I rethought on this issue and decided to use Crypt::SMIME.

Regards,

--- Soji

-- 
株式会社 コンバージョン  セキュリティ&OSSソリューション部   池田荘児
〒231-0004　神奈川県横浜市中区元浜町3-21-2 ヘリオス関内ビル7F
e-mail address@concealed  TEL 045-640-3550
http://www.conversion.co.jp/