Containers

I've been asked several times about use of containers. I spent a fair while on it in the recitation session on December 8, especially in the last half of the session, but given the number of people who have asked about it I figured I'd write something up.

Containers protect what's outside them from whatever is running inside them. To figure out if they're needed, go back to what I said in the first lecture is the first question to ask: "What are you trying to protect, and against whom?" That's what we'll use to guide our analysis. And there are three essential components: the certificate authority, which handles passwords (including password changes) and issues certificates; the mail system, which hands out certificates and accepts and distributes encrypted email; and the client. We'll also make a simplifying assumption that would not be valid in the real world: there are no other users and no other services running on these subsystems. That is, the CA, the mail server, and the client can only be attacked via the specified network services. This also implies that nothing else is at risk other than components of these services.

Let's look first at the CA. It has to protect its private signing key for issuing certificates and the hashed password file. (Why?) It talks only to the client, so it can only be attacked that way. A successful theft of the private signing key lets an attacker create forged certificates and hence be able to read mail encrypted to them. The certificates it creates are not sensitive, but they do have to be communicated—somehow!—to the mail server. If you choose to use some sort of containers for the CA, the private key and the hashed password file should be outside it.

The mail server is much less of a problem if it's hacked—other than a private TLS key, for connections, it has nothing particularly sensitive. However, it's running a risky service. What might an attacker get if they hacked it? Nothing much from the mail server—but if it and the CA are on the same VM, can the attacker then get at the CA's private key? A container could prevent that. An alternative in the real world—I'm not suggesting that you do this!—would be to put the CA and the mail server on separate VMs.

What about the client? It has two private keys to protect, the TLS key and the mail decryption key. (Yes, these should be the same here, for simplicity.) Containerization could protect them. But the client can only be attacked if one of the two servers is compromised first, so it's at lesser risk. That, too, can go into your design decisions.

So: while there's no one answer, there are things that containers will and won't do for you.

Another question is how you test your containers. Assume that the attacker can run any program within it—can they break out? If they can't, the container has done its job.