[Cc'ing linux-integrity] On Fri, 2018-01-26 at 09:58 -0500, Theodore Ts'o wrote: > > > > Currently container images are simple tar files and one of the main > > value adds of docker as a tool is the simplicity of the image creation > > process. That process depends on standard tools like tar to create the > > image, so I was trying to fit this proposal into that process. > > The goal of fs-verity is protect arbitrary files without breaking the > backwards compatibility of those that *read* the file. So for > example, an APK file is downloaded and verified at the intial download > --- and never verified again. It is *used* many times after the > initial download (and hence, potentially after an evil maid attack), > and this is done by many different tools, including by code inside the > APK itself. So it is not feasible to change the tools that read the > APK, which means we can't make any backwards-incompatible changes to > the file itself. > > However, changing the tools that *establish* the locally verified copy > is considered completely fair game. I'll note that this is true no > matter what system you use. If you are using IMA, after the file is > downloaded, you still have to set the magic "trusted xattr" (which, I > will note, requires root access since it is a trusted root access). > So you have to make at least *some* changes to the code path which > writes the file that you want to be integrity protected. In the case > of IMA, this includes code that has to run as root. Different types of software packages (eg. tar, rpm, multiple deb prototypes) can be built to include file signatures. Both the file data and metadata (eg. signatures) would be installed together by the same app, which already has root privileges needed to install them. Mimi
