Hi Alper, On Mon, 21 Jun 2021 at 12:52, Alper Nebi Yasak <[email protected]> wrote: > > The filesystem test setup needs to prepare disk images for its tests, > with either guestmount or loop mounts. The former requires access to the > host fuse device (added in a previous patch), the latter requires access > to host loop devices. Both mounts also need additional privileges since > docker's default configuration prevents the containers from mounting > filesystems (for host security). > > Add any available loop devices to the container and try to add as few > privileges as possible to run these tests, which narrow down to adding > SYS_ADMIN capability and disabling apparmor confinement. However, this > much still seems to be insecure enough to let malicious container > processes escape as root on the host system [1]. > > [1] > https://blog.trailofbits.com/2019/07/19/understanding-docker-container-escapes/ > > Since the mentioned tests are marked to run only on the sandbox board, > add these additional devices and privileges only when testing with that. > > An alternative to using mounts is modifying the filesystem tests to use > virt-make-fs (like some EFI tests do), but it fails to generate a > partitionless FAT filesystem image on Debian systems. Other more > feasible alternatives are using guestfish or directly using libguestfs > Python bindings to create and populate the images, but switching the > test setups to these is nontrivial and is left as future work. > > Signed-off-by: Alper Nebi Yasak <[email protected]> > --- > > (no changes since v2) > > Changes in v2: > - Always pass in /dev/fuse to Azure's docker run invocation. > - Remove "and some EFI tests" from comment (no longer applies to that > block of code). > > .azure-pipelines.yml | 16 +++++++++++++++- > 1 file changed, 15 insertions(+), 1 deletion(-)
Shouldn't this be done in gitlab too? Regards, Simon
