Re: [Tei-council] meetings and containers (was "Re: Stylesheets (and other) meeting time")

HI all, On 2020-01-02 12:09 p.m., Hugh Cayless wrote:

Apart from rare exceptions, all you should need to do to get patched versions of packaged software is to build a new image. There is actually nothing I can do on my end to facilitate this process—other than possibly change the base system I’m using. I maintain the Dockerfile that Docker uses to build the image that you run in a container. My understanding of the process is that updates are applied when the image is built. If you want to keep a container hanging around, you could also periodically run apt-get update && apt-get dist-upgrade in your container.

This is what I would recommend.

The attack vectors against your personal machine are not going to be multiplied by doing TEI things in a container that isn’t listening on any ports. You’re probably a bit safer if anything, even running an unpatched system. If a hacker could get access to it, they’re already in your machine, or they’ve compromised something the TEI build process needs. In other words, you were already doomed.

There is one well-known attack vector that we're all vulnerable to, and that's the fact that if any GitHub id of anyone with commit privileges is compromised, then the git repo can be used to launch an attack on any machine that's running a build process based on the repo contents. Normally when you run a build process outside docker, you're running it as your regular user, on a fully-updated machine, so although the results could be bad, it would be unusual if a hacker could get root on your machine that way, except through a zero-day. However, if you're running the build in a docker container which is not updated, it's more likely the hack could get root on that container; and if that's combined with a method of escaping the container, and the container itself is running as root on the host system, then you could be in trouble. And if you don't really understand docker very well (and I don't, even though I use it), then you can end up running things with more privileges than they really merit by accident. I know this does sound a bit paranoid, but I always think we should err on the side of paranoia rather than nonchalance when it comes to security. :-) Cheers, Martin

Note that the above does not apply if you’re running a server—paranoia is fully justified in that case.

Hugh

...

On Jan 2, 2020, at 14:10, Bauman, Syd wrote:

Whether I make it or not, I hope the topic of keeping the Docker containers updated is discussed. My thoughts on this topic follow, in no particular order.

* It is definitely important to keep the OS running in a Docker container up to date with security patches. It may not be as big a problem as Martin worries it is, especially if we are all vigilant in leaving a container running for the minimum amount of time necessary. But it is still important enough that we should have a process for doing it.

* The solution is probably administrative, not technical.

* It is probably unfair to insist that Peter and Hugh be solely responsible for doing this. (That said, if they don't object, I don't either. I would if it were only 1 person -- at least 2 people should know how to do everything that is even semi-important.) Could be a rotating responsibility.

* My suggested administrative idea: Once a month, 1-24 hours *before* the Council meeting, the Docker maintainer or designee should update each container with the latest OS security patches. (Chair should send a reminder 48 hours before the meeting.) Immediately *after* the Council meeting each Council member should download and install the updated container.

* Peter pointed out that doing such an update might break the build within the container. He's right, but that's no reason not to install security patches. It's a reason to fix the build process so it works on a properly updated system. Doing this on meeting day, I figure, gives us a higher chance of noticing a build fail, finding a fix, and promulgating the solution rapidly. _______________________________________________ Tei-council mailing list Tei-council@lists.tei-c.org http://lists.lists.tei-c.org/mailman/listinfo/tei-council

-- ------------------------------------------ Martin Holmes UVic Humanities Computing and Media Centre