From patchwork Tue Jul 25 15:44:23 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Roberto Sassu X-Patchwork-Id: 9862449 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id E73E6601A1 for ; Tue, 25 Jul 2017 15:53:58 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id CDF56286A0 for ; Tue, 25 Jul 2017 15:53:58 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id C0A8B286E3; Tue, 25 Jul 2017 15:53:58 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-4.4 required=2.0 tests=BAYES_00, RCVD_IN_DNSWL_HI, SUSPICIOUS_RECIPS autolearn=ham version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 02FC2286A0 for ; Tue, 25 Jul 2017 15:53:58 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753136AbdGYPx4 (ORCPT ); Tue, 25 Jul 2017 11:53:56 -0400 Received: from lhrrgout.huawei.com ([194.213.3.17]:32212 "EHLO lhrrgout.huawei.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752923AbdGYPxz (ORCPT ); Tue, 25 Jul 2017 11:53:55 -0400 Received: from 172.18.7.190 (EHLO lhreml709-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DLH02723; Tue, 25 Jul 2017 15:53:52 +0000 (GMT) Received: from roberto-HP-EliteDesk-800-G2-DM-65W.huawei.com (10.204.65.245) by smtpsuk.huawei.com (10.201.108.32) with Microsoft SMTP Server (TLS) id 14.3.301.0; Tue, 25 Jul 2017 16:53:45 +0100 From: Roberto Sassu To: CC: , , , , Roberto Sassu Subject: [PATCH 12/12] ima: added Documentation/security/IMA-digest-lists.txt Date: Tue, 25 Jul 2017 17:44:23 +0200 Message-ID: <20170725154423.24845-13-roberto.sassu@huawei.com> X-Mailer: git-send-email 2.9.3 In-Reply-To: <20170725154423.24845-1-roberto.sassu@huawei.com> References: <20170725154423.24845-1-roberto.sassu@huawei.com> MIME-Version: 1.0 X-Originating-IP: [10.204.65.245] X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020204.59776991.0029, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 9a262c23c44b21d043c9ec734bbd5c4e Sender: owner-linux-security-module@vger.kernel.org Precedence: bulk List-ID: X-Virus-Scanned: ClamAV using ClamSMTP This patch adds the documentation of the new IMA feature, to load and measure file digest lists. Signed-off-by: Roberto Sassu --- Documentation/security/IMA-digest-lists.txt | 150 ++++++++++++++++++++++++++++ 1 file changed, 150 insertions(+) create mode 100644 Documentation/security/IMA-digest-lists.txt diff --git a/Documentation/security/IMA-digest-lists.txt b/Documentation/security/IMA-digest-lists.txt new file mode 100644 index 0000000..f9eed21 --- /dev/null +++ b/Documentation/security/IMA-digest-lists.txt @@ -0,0 +1,150 @@ + File Digest Lists + +==== INTRODUCTION ==== + +IMA, for each file matching policy rules, calculates a digest, creates +a new entry in the measurement list and extends a TPM PCR with the digest +of entry data. The last step causes a noticeable performance reduction. + +Since systems likely access the same files, repeating the above tasks at +every boot can be avoided by replacing individual measurements of likely +accessed files with only one measurement of their digests: the advantage +is that the system performance significantly improves due to less PCR +extend operations; on the other hand, the information about which files +have exactly been accessed and in which sequence is lost. + +If this new measurement reports only good digests (e.g. those of +files included in a Linux distribution), and if verifiers only check +that a system executed good software and didn't access malicious data, +the disadvantages reported earlier would be acceptable. + +The Trusted Computing paradigm measure & load is still respected by IMA +with the proposed optimization. If a file being accessed is not in a +measured digest list, a measurement will be recorded as before. If it is, +the list has already been measured, and the verifier must assume that +files with digest in the list have been accessed. + +Measuring digest lists gives the following benefits: + +- boot time reduction + For a minimal Linux installation with 1400 measurements, the boot time + decreases from 1 minute 30 seconds to 15 seconds, after loading to IMA + the digest of all files packaged by the distribution (32000). The new + list contains 92 entries. Without IMA, the boot time is 8.5 seconds. + +- lower network and CPU requirements for remote attestation + With the IMA optimization, both the measurement and digest lists + must be verified for a complete evaluation. However, since the lists + are fixed, they could be sent to and checked by the verifier only once. + Then, during a remote attestation, the only remaining task is to verify + the short measurement list. + +- signature-based remote attestation + Digest list signature can be used as a proof of the provenance for the + files whose digest is in the list. Then, if verifiers trust the signer + and only check provenance, remote attestation verification would simply + consist on checking digest lists signatures and that the measurement + list only contain list metadata digests (reference measurement databases + would be no longer required). An example of a signed digest list, + that can be parsed with this patch set, is the RPM package header. + +Digest lists are loaded in two stages by IMA through the new securityfs +interface called 'digest_lists'. Users supply metadata, for the digest +lists they want to load: path, format, digest, signature and algorithm +of the digest. + +Then, after the metadata digest is added to the measurement list, IMA +reads the digest lists at the path specified and loads the digests in +a hash table (digest lists are not measured, since their digest is already +included in the metadata). With metadata measurement instead of digest list +measurement, it is possible to avoid a performance reduction that would +occur by measuring many digest lists (e.g. RPM headers) individually. +If, alternatively, digest lists are loaded together, their signature +cannot be verified. + +Lastly, when a file is accessed, IMA searches the calculated digest in +the hash table. Only if the digest is not found a new entry is added +to the measurement list. + + + +==== FORMAT ==== + +The format of digest list metadata is: + +algo[2] digest_len[4] digest[digest_len] + signature_len[4] signature[signature_len] + path_len[4] path[path_len] + ref_id_len[4] ref_id[ref_id_len] + list_type_len[4] list_type[list_type_len] + +algo, list_type and _len are little endian. + + +algo values are defined in include/uapi/linux/hash_info.h. The algorithms +in the list metadata must be the same of ima_hash_algo (algorithm used +by IMA to calculate the file digest). + +list type values: + +0: compact digest list +1: RPM package header + + +The format of the compact digest list is: + +entry_id[2] count[4] data_len[4] +data[data_len] +[...] +entry_id[2] count[4] data_len[4] +data[data_len] + +entry_id, count and data_len are little endian. + +At the moment, entry_id can have value 0, which means that 'data' contains +'count' digests concatenated together. For example, a compact digest list +with 10 SHA256 digests will look like: + +0 10 320 +digest1..digest10 + + + +==== MEASUREMENT LIST ==== + +systemd has been modified to load the path of files containing digest list +metadata to the new securityfs interface. Paths must be stored in +/etc/ima/digest-lists. If digest lists, metadata and systemd configuration +file are included in the initial ram disk, a typical measurement list +will look like: + +10