On Thu, Apr 25, 2013 at 7:05 PM, Daniel Kahn Gillmor <dkg@fifthhorseman.net>wrote:

On 04/25/2013 04:36 PM, Stefan Schlott wrote:

...

On 25.04.2013 00:14, Abhilash Raj wrote:

...

1. When a message is decrypted and then passed on between the queues, it creates a security threat for the cleartext message is being held in memory, even for a small time in between the runners.

The Mailman server holds the key to decrypt _every_ incoming message. So if the server is compromised, a message temporarily held in memory is the least of your problems :-)

abhilash might have meant that there is a concern that a decrypted message could be stored *on disk* in one of the queues, not just in memory. This could be a problem if an adversary gets access to the disk and can get access to the backing storage, even after the files have been unlinked from the filesystem (since unlinking files doesn't guarantee removal of all traces from the backing storage).

Of course, if the secret key for the list is kept without a passphrase on the same filesystem or on a separate filesystem on the same backing storage, then your risk is elevated to begin with.

Abhilash, i don't see any mention in your proposal of how you plan to deal with the secret key material. will there be a way for mailman to use a secret key that is stored in a password-protected form? If so, how?

Well I am not quite proficient in cryptography but I tried to answer how could it be done and have updated on the same link1. Here is a copy of only that part:

One of the biggest issues of any cryptographic procedure is to secure and manage the keys. Firstly for the lists, when the list is created by the owner the keypair is generated by mailman in some time(because when i was trying to create one using gnupg, it asked me to wait for sometime and keep doing some work to get threshold entropy. Although in reality I don't have much idea about how the keys are created, but I am guessing that it somewhere uses the random bits from the memory of the host where key is created and thus required a threshold entropy for the proper randomization of the key. On virtualised Linux systems, this can often be achieved by installing the rng-tools package.) and is stored in the database against the name of the list. It will then be available for download to the subscribers. [python-gnupg][2] also allows one to encrypt/decrypt using the keys that are protected by a paraphrase. Such paraphrase though would then be stored in cleartext format in database. Though this poses a security thread but even if you encrypt and store the paraphrase, you can only slow the process of decryption once the server is compromised since the private-paraphrase-encryption key will also be needed to be stored somewhere on the local disk.

The pub-keys added by the users will be stored in different table(having many to one relationship with users) and will be used whenever there is a need to encrypt or verify_signature.

    --dkg

---

Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/raj.abhilash1%40gm...

Security Policy: http://wiki.list.org/x/QIA9

-- Abhilash Raj

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256

On Apr 26, 2013, at 02:09 PM, Stefan Schlott wrote:

• disk queue. I don't remember if mailman persists received (but not yet sent) mails on disk.

Addressing the last point, you can either choose to decrypt the mail in a later stage, or (if this is a bad idea for performance reasons) deal with this problem with an adequate system configuration, although this is tricky and certainly error-prone. But I think it could be done by excluding the queue from backup (unless, of course, the backup is encrypted, which you should do anyway) and having an encrypted file system.

Yes, Mailman caches the messages and the metadata as it transfers the message from queue to queue. These two pieces of information are what make up the .pck (Python pickle) files in the queue directories, so for example, after the message has been moderated, it lives in a pck file until the modification runner picks it up for processing.

One option, which might suck performance-wise, would be to decrypt the message multiple times. Thus the moderation queue runner would decrypt the message if it needs to make moderation decisions based on the encrypted payload (it may not need to though, since a lot can be discerned from the headers and other cleartext information). If it decides that the message is okay to post, it would not store the decrypted message in the queue, but instead the original message with the encrypted payload. The next queue runner would then also have to decrypt the message to do its processing.

OTOH, maybe that's all security theater. If the Mailman system's private key is available to an attacker, then having the encrypted message on disk temporarily is probably not going to stop them from decrypting it.

• -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux)

iQIcBAEBCAAGBQJRess/AAoJEBJutWOnSwa//rcQALx/p1Ba8a4CZWCzL2FGW+PZ 80mP+prL44VisScEJopqxx2vzCmzRNo8w0uH7UwKc2DQ4Bl8O+LdBoZs3UdZAB/9 dgSxIAMFsy78TnVngif3Ps5gESdQUAuLijkViHJGePcKNDXMYMV4hBzeqKZxCj+Q Y1NxyJLLeuLrt3HEvQy4TAmWFA/r4UGG5QM249orv2iOtXeHlGMD+IUi4pqyolY6 qzK6WirEh+ntGLvsXHuIBSxpidG9UvRe4XmLT7/fVAUO6X5EuTBdk9NgT9d+Pw+Z eslyngqPOf2MvV/wKLzZFytblGFog7pLOkOPbJ1UzI+KxIf8K4LMlEUG5mo2IGY+ 7vOZgsD9dxzJ2kX0uk1SFR4b23jWZhrYwHAC/k03x2l3FoMvdUqb5/9+nf6C+/4K ZyeB+exOD33TkKtTSx5iZ8HEO/1vCsENFESLeZ5M79cXQJKihyRMiAQfHXzQfR65 XZ0lCG4SB3c0QmhBSqWTxdNP01In0YcD0E5S+1JlP7HbCRhKTU0oHy45rMVSwKfC h1luVZe74Ecuy0foL2gcNObJG6GrXEsAUfYXL5TIy8vSff5VuNVyP4j0Xq7pmPxN XzEt0Vyyc3GTrHbBbnkX1gM4W3icxSHCt9mvCDZ8Civ46qR2pJjkTg6laPtHfLWB 02sufu7o47Z3xcGM4rbq =pajO -----END PGP SIGNATURE-----

On 26.04.2013 20:55, Terri Oda wrote:

I've been wondering about that... is there any time when the encrypted message on disk would be available but the private key not?

As already pointed out, there are (at least) two ways to avoid an unprotected secret key (or the corresponding pass phrase, respectively) on disk:

• Keep the passphrase only in RAM (e.g. entering it when starting mailman or by using gpg-agent)
• Having the secret key on a smartcard

Stefan.

Barry Warsaw writes:

OTOH, maybe that's all security theater. If the Mailman system's private key is available to an attacker, then having the encrypted message on disk temporarily is probably not going to stop them from decrypting it.

It's worse than that. The attacker doesn't need the key, he just needs to be able to suborn the Mailman process.

There is a scenario where the attacker might want access to the key itself, and that's if he wants to use it somewhere else for some reason (ie, to spoof that Mailman server). But I think the primary scenario is that the attacker just wants access to list traffic, and for that the ability to install a "rule" or "handler" is sufficient in the current architecture.

I think we should assume that the Mailman host is secure[1], and worry about how Mailman itself provides an attack surface.

Footnotes: [1] I know that that assumption is incorrect. Nevertheless, I don't see what Mailman can do about it without a complete redesign starting from the assumption of encrypted messages whose plain text must be exposed as briefly as possible.