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 <s.bauman@northeastern.edu>
>> 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
_______________________________________________
Tei-council mailing list
Tei-council@lists.tei-c.org
http://lists.lists.tei-c.org/mailman/listinfo/tei-council