From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-15.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_GIT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 76004C48BDF for ; Sun, 13 Jun 2021 14:08:48 +0000 (UTC) Received: from phobos.denx.de (phobos.denx.de [85.214.62.61]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id CDD7B61285 for ; Sun, 13 Jun 2021 14:08:47 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org CDD7B61285 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id D9F0F80F34; Sun, 13 Jun 2021 16:08:31 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de Authentication-Results: phobos.denx.de; dkim=pass (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.b="FRwdjjt9"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id 3ED6C80ECC; Sun, 13 Jun 2021 16:08:20 +0200 (CEST) Received: from mail-ej1-x635.google.com (mail-ej1-x635.google.com [IPv6:2a00:1450:4864:20::635]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)) (No client certificate requested) by phobos.denx.de (Postfix) with ESMTPS id 30D1880EC7 for ; Sun, 13 Jun 2021 16:08:14 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=alpernebiyasak@gmail.com Received: by mail-ej1-x635.google.com with SMTP id k7so12022682ejv.12 for ; Sun, 13 Jun 2021 07:08:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=A1nYognXfiKNfh5C/UIkFyVVJ0yehwy+U+0KHJvsHTY=; b=FRwdjjt9up3MmZX+nZoYIdgY4o/YhiMJiZSXBup0wDvItO+y5g7/qdtWZxZiv12Wv3 abbtk4KLrTeZw1RinX3o1KnUNheRNlBRnL+OkVuSqXrx8663crd7Gj1hgWyCZZxR3SW9 IXXK08Fxl97aqJJ8KKT1+p1rcSq+a2sWu8ALDCNbPSx9v932uMFJAKQobOX5uUtPoQr+ XpD7I2TuMX1lkWvTldpTpAzAXXWzFDJVxyNG8+MAKNdnHgP3+cyNOx1fOyk2dlRzFDU1 SvatPL0+rwGnn8bCV25iolTeuu8aWxelzvkbWCAyZiOxLSIefM+NyfvCWUTwzxb2mafB mcgw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=A1nYognXfiKNfh5C/UIkFyVVJ0yehwy+U+0KHJvsHTY=; b=PvYgj+yeEpwL+I8Fm+SQ9gaOEQPoeFTmd9bP+rWO5oh9G/kWcZZrOalnRAAcQ+NAlV QhRuHIrg82pTW29RcJVCAQreiA5QiqRBALoOGFfvkJIsMBM9NlRxtZa6rR/r5kd8Jxb/ F/dWibmjvsjQ/ER4521qm3fraoHjna1/tBZLZiJopY9j3bB0UytiMBLUn/xnrFcXfY7H LDm50PYuF/HK/l2pUz5nl2ej2Mt739yurzTHTILhlMsynNOZPz7hLQFDYlilZftc/UdF VpddW2tYhsuODMZ4TyrmuqiEzujtwP9MlDLvB19u30QovvP89v2MohiHO1irsNVLBVxB ZRAg== X-Gm-Message-State: AOAM532nLfPqZt6WScCD7JmrCQvHUgSPX2yHpcBv3Zfw0Q/4Ppq5K2Kn ZsikB8Gz2YOU1Ie8X9XT/8HD5hvPO88= X-Google-Smtp-Source: ABdhPJwcWpZLhzKLOAZ9psnhggVsY4jexyKbIDCHc0dPCrPcKpQMYiF1AIT2IS1BQGyy3uh0qtD6kQ== X-Received: by 2002:a17:906:c316:: with SMTP id s22mr11698443ejz.17.1623593293569; Sun, 13 Jun 2021 07:08:13 -0700 (PDT) Received: from localhost.localdomain ([178.233.26.119]) by smtp.gmail.com with ESMTPSA id n15sm5929803eds.28.2021.06.13.07.08.11 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 13 Jun 2021 07:08:13 -0700 (PDT) From: Alper Nebi Yasak To: u-boot@lists.denx.de Cc: AKASHI Takahiro , Bin Meng , Tom Rini , Simon Glass , Daniel Schwierzeck , Marek Vasut , Heinrich Schuchardt , Alper Nebi Yasak Subject: [PATCH v2 3/3] Azure: Add loop devices and CAP_SYS_ADMIN for sandbox test.py tests Date: Sun, 13 Jun 2021 17:07:30 +0300 Message-Id: <20210613140731.16254-4-alpernebiyasak@gmail.com> X-Mailer: git-send-email 2.32.0 In-Reply-To: <20210613140731.16254-1-alpernebiyasak@gmail.com> References: <20210613140731.16254-1-alpernebiyasak@gmail.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: u-boot@lists.denx.de X-Mailman-Version: 2.1.34 Precedence: list List-Id: U-Boot discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: u-boot-bounces@lists.denx.de Sender: "U-Boot" X-Virus-Scanned: clamav-milter 0.103.2 at phobos.denx.de X-Virus-Status: Clean 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 --- 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(-) diff --git a/.azure-pipelines.yml b/.azure-pipelines.yml index 976868dd2eb7..e36a27c97d56 100644 --- a/.azure-pipelines.yml +++ b/.azure-pipelines.yml @@ -318,8 +318,22 @@ jobs: # as sandbox testing need create files like spi flash images, etc. # (TODO: clean up this in the future) chmod 777 . + # Filesystem tests need extra docker args to run + set -- + if [[ "${TEST_PY_BD}" == "sandbox" ]]; then + # mount -o loop needs the loop devices + if modprobe loop; then + for d in $(find /dev -maxdepth 1 -name 'loop*'); do + set -- "$@" --device $d:$d + done + fi + # Needed for mount syscall (for guestmount as well) + set -- "$@" --cap-add SYS_ADMIN + # Default apparmor profile denies mounts + set -- "$@" --security-opt apparmor=unconfined + fi # Some tests using libguestfs-tools need the fuse device to run - docker run --device /dev/fuse:/dev/fuse -v $PWD:$(work_dir) $(ci_runner_image) /bin/bash $(work_dir)/test.sh + docker run "$@" --device /dev/fuse:/dev/fuse -v $PWD:$(work_dir) $(ci_runner_image) /bin/bash $(work_dir)/test.sh - job: build_the_world displayName: 'Build the World' -- 2.32.0