Security analysis on ODK Docker - How?

[matentzn]

Given reports on ever more malicious public docker images I would like to do due diligence on ODK to make sure that there is zero malicious code (through packages, dependencies of packages, etc) in ODK. Is such an analysis at all possible? Is it as easy as running a command line virus scan or something inside a container?

[gouttegd]

Few random thoughts on the topic.

Running a virus scan

It shouldn’t be difficult to run a ClamAV scan from within the image. Download the image, start a container with it, and once inside, install ClamAV (it’s available in the distribution’s repository) and run it on the entire system.

An obvious problem with that approach is that we trust the image to download and run the scanner. If the image is compromised, we shouldn’t trust it for that – one could imagine that whoever compromised the image has managed to alter the behaviour of apt-get so that, for example, running apt-get install clamav actually installs a bogus scanner that only pretends to scan the system while doing nothing.

A better approach would be to unpack the image and run the scanner from the host system, without ever running anything from the image itself. Something like:

$ docker save obolibrary/odkfull | tar xf -
$ for layer in */layer.tar ; do mkdir -p tmp ; tar xf $layer -C tmp ; clamscan -r tmp ; rm -rf tmp ; done

(Rough sketch, could be optimized e.g. to use clamdscan instead of clamscan, to avoid loading the signature database for each layer.)

Whether ClamAV would be enough to claim the image contains zero malicious code would be a bit of a stretch, though. I particular, I don’t think it would detect malicious Python packages, that doesn’t seem to be in its scope.

(Other thoughts to be added at a more decent time.)

[matentzn]

This is an excellent idea; I never thought of running a virus scanner! I wonder if there is a way to:

1. Build an image
2. Spawn a container
3. from within, run a CLI virus scanner

As part of CI/CD?

[matentzn]

Orthogonal, but related, discussion is a about security in GitHub actions. Here two comments from slack I wanted to preserve:

[gouttegd]

(Just remembered that I completely forgot to follow up on this with more thoughts.)

Software inventory

One thing we need to have is a complete inventory of all the software packages we have in the ODK. This won't actually make the ODK any more secure, but it will at least allow us to know whether the ODK is affected by a given security vulnerability when we hear about one. E.g., if we learn (through any channel) that software package Foo has had a security vulnerability that was introduced in v1.2.3 and fixed in version v1.4.5, we must be able to tell whether the ODK has included a vulnerable version at any point in time, so that we can let our users know about it.

For packages coming from the Ubuntu repositories, we can get the complete list with the apt-* tools.

For Python packages, we actually already have that list: that's the constraints.txt file.

For the other components that are "manually" installed, the inventory would have to be compiled by hand.