[PATCH v3 3/3] Azure: Add loop devices and CAP_SYS_ADMIN for sandbox test.py tests

Tom Rini trini at konsulko.com
Sat Jun 26 22:46:12 CEST 2021


On Sat, Jun 26, 2021 at 12:29:56PM -0600, Simon Glass wrote:
> Hi Alper,
> 
> On Mon, 21 Jun 2021 at 12:52, Alper Nebi Yasak <alpernebiyasak at gmail.com> 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 <alpernebiyasak at gmail.com>
> > ---
> >
> > (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?

In GitLab we don't control how docker is launched, is the problem.
That's up to the admins and we sometimes do, sometimes don't have the
capabilities enabled.  That probably means we should update the CI doc
and also email the various CI admins about updating things.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20210626/cab88590/attachment.sig>


More information about the U-Boot mailing list