From patchwork Wed Mar 14 15:57:27 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Petr Vorel X-Patchwork-Id: 885874 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Authentication-Results: ozlabs.org; spf=pass (mailfrom) smtp.mailfrom=lists.linux.it (client-ip=213.254.12.146; helo=picard.linux.it; envelope-from=ltp-bounces+incoming=patchwork.ozlabs.org@lists.linux.it; receiver=) Authentication-Results: ozlabs.org; dmarc=none (p=none dis=none) header.from=suse.cz Received: from picard.linux.it (picard.linux.it [213.254.12.146]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 401bwK00CKz9sVQ for ; Thu, 15 Mar 2018 02:57:52 +1100 (AEDT) Received: from picard.linux.it (localhost [IPv6:::1]) by picard.linux.it (Postfix) with ESMTP id 503183E76DE for ; Wed, 14 Mar 2018 16:57:50 +0100 (CET) X-Original-To: ltp@lists.linux.it Delivered-To: ltp@picard.linux.it Received: from in-5.smtp.seeweb.it (in-5.smtp.seeweb.it [217.194.8.5]) by picard.linux.it (Postfix) with ESMTP id 1615E3E6DE7 for ; Wed, 14 Mar 2018 16:57:47 +0100 (CET) Received: from mx2.suse.de (mx2.suse.de [195.135.220.15]) (using TLSv1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by in-5.smtp.seeweb.it (Postfix) with ESMTPS id 18A276002CE for ; Wed, 14 Mar 2018 16:57:46 +0100 (CET) Received: from relay2.suse.de (charybdis-ext.suse.de [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 52AD3AE89; Wed, 14 Mar 2018 15:57:46 +0000 (UTC) From: Petr Vorel To: ltp@lists.linux.it Date: Wed, 14 Mar 2018 16:57:27 +0100 Message-Id: <20180314155731.5943-1-pvorel@suse.cz> X-Mailer: git-send-email 2.16.2 X-Virus-Scanned: clamav-milter 0.99.2 at in-5.smtp.seeweb.it X-Virus-Status: Clean X-Spam-Status: No, score=-0.0 required=7.0 tests=SPF_PASS autolearn=disabled version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on in-5.smtp.seeweb.it Cc: linux-integrity@vger.kernel.org, Mimi Zohar Subject: [LTP] [RFC PATCH v2 0/4] Rewrite tests into new API + fixes X-BeenThere: ltp@lists.linux.it X-Mailman-Version: 2.1.18 Precedence: list List-Id: Linux Test Project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Errors-To: ltp-bounces+incoming=patchwork.ozlabs.org@lists.linux.it Sender: "ltp" Hi, this is a second attempt to rewrite IMA tests. Comments and fixes are welcome. Changes v1->v2: * ima_measurements.sh: add support for "ima-ng" and "ima-sig" IMA measurement templates * ima_measurements.sh: add support for most of hash algorithms is defined in include/uapi/linux/hash_info.h * fix ima_boot_aggregate ("ima/ima_boot_aggregate: Increase MAX_EVENT_SIZE to 8k") * ima_tpm.sh: fixes of TPM test ("ima/tpm: Various fixes") * ima_measurements.sh: drop ima_measure and use evmctl (external dependency) instead * ima_measurements.sh: check XFS version for iversion support TODO * ima_measurements.sh: Add support for ima_template_fmt kernel parameter. * ima_policy.sh: Detect if the policy must be signed [1] (IMA_WRITE_POLICY or "secure_boot" kernel parameter). @Mimi: What is a best approach in case policy must be signed? measure.policy and measure.policy-invalid files are not signed should we skip all tests in ima_policy.sh with something like "Not supported when policy must be signed"? Or running them both and expect them to fail as they're not signed? As that's how I understand your related commit in kernel (19f8a84713ed "ima: measure and appraise the IMA policy itself"). BTW load_policy() use old approach catting the content into sysfs policy file. Maybe it'd be good to echo policy filename into sysfs policy file for kernel > 4.6 (feature added in 7429b092811f "ima: load policy using path"). * ima_measurement.sh,ima_violations.sh: Avoid using tmpfs filesystem [1]. You suggested using RAM block device. Would it be ok to use filesystem created on loop device (/dev/loop0)? Or even create image file in $TMPDIR (mostly /tmp, which can be tmpfs) and use it as a loop device? To be honnest, I'm not sure if I addressed your comment [2]: These tests are for the IMA-measurement aspect only, not IMA- appraisal. Adding measurements to the measurement list won't cause the system to stop working, unless keys are sealed to a particular TPM PCR value. Nobody is or should be sealing keys to PCR-10, since the ordering of the measurements is non deterministic. As we add IMA-appraisal tests requiring files to be signed, things will fail if either the public key isn't on the IMA keyring or the file isn't properly signed. For this reason, limiting file IMA- appraisal tests to a particular filesystem simplifies testing. [1] http://lists.linux.it/pipermail/ltp/2018-January/006970.html [2] http://lists.linux.it/pipermail/ltp/2018-January/007024.html Kind regards, Petr Petr Vorel (4): security/ima: Rewrite tests into new API + fixes security/ima: Run measurements after policy ima/ima_boot_aggregate: Increase MAX_EVENT_SIZE to 8k ima/tpm: Various fixes runtest/ima | 8 +- testcases/kernel/security/integrity/.gitignore | 1 - .../integrity/ima/src/ima_boot_aggregate.c | 2 +- .../security/integrity/ima/src/ima_measure.c | 219 ------------------- .../integrity/ima/tests/ima_measurements.sh | 239 +++++++++++---------- .../security/integrity/ima/tests/ima_policy.sh | 148 ++++++------- .../security/integrity/ima/tests/ima_setup.sh | 110 ++++------ .../kernel/security/integrity/ima/tests/ima_tpm.sh | 160 ++++++-------- .../security/integrity/ima/tests/ima_violations.sh | 217 +++++++++---------- 9 files changed, 417 insertions(+), 687 deletions(-) delete mode 100644 testcases/kernel/security/integrity/ima/src/ima_measure.c mode change 100755 => 100644 testcases/kernel/security/integrity/ima/tests/ima_setup.sh