From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752014AbdKHKRU (ORCPT ); Wed, 8 Nov 2017 05:17:20 -0500 Received: from lhrrgout.huawei.com ([194.213.3.17]:39855 "EHLO lhrrgout.huawei.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751495AbdKHKRP (ORCPT ); Wed, 8 Nov 2017 05:17:15 -0500 Subject: Re: [PATCH v2 00/15] ima: digest list feature To: "Safford, David (GE Global Research, US)" , "linux-integrity@vger.kernel.org" CC: "linux-security-module@vger.kernel.org" , "linux-fsdevel@vger.kernel.org" , "linux-doc@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "silviu.vlasceanu@huawei.com" References: <20171107103710.10883-1-roberto.sassu@huawei.com> From: Roberto Sassu Message-ID: Date: Wed, 8 Nov 2017 11:16:57 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8"; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 7bit X-Originating-IP: [10.220.96.228] X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020205.5A02D9A8.00B2,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: d68879d33dd1b60beae8c8a6e5284e28 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 11/7/2017 7:03 PM, Safford, David (GE Global Research, US) wrote: >> -----Original Message----- >> From: linux-integrity-owner@vger.kernel.org [mailto:linux-integrity- >> owner@vger.kernel.org] On Behalf Of Roberto Sassu >> Sent: Tuesday, November 07, 2017 5:37 AM >> To: linux-integrity@vger.kernel.org >> Cc: linux-security-module@vger.kernel.org; linux-fsdevel@vger.kernel.org; >> linux-doc@vger.kernel.org; linux-kernel@vger.kernel.org; >> silviu.vlasceanu@huawei.com; Roberto Sassu >> Subject: EXT: [PATCH v2 00/15] ima: digest list feature >> >> IMA is a security module with the objective of reporting or enforcing the >> integrity of a system, by measuring files accessed with the execve(), >> mmap() and open() system calls. For reporting, it takes advantage of the >> TPM and extends a PCR with the digest of an evaluated event. For enforcing, >> it returns a value which is zero if the operation should be allowed, negative if >> it should be denied. >> >> Measuring files of an operating system introduces three main issues. First, >> since the overhead introduced by the TPM is noticeable, the performance of >> the system decreases linearly with the number of measurements taken. >> This can be seen especially at boot time. > > If you want the measurement chain of trust, every link must be extended in the TPM. > This is inherent in the model. Doing local verification of TCB files is really no substitute. Digest list measurement is extended in the TPM. If not, digest lookup is disabled until reboot. The same happens for appraisal: if the digital signature of digest lists is invalid, digest list cannot be used for local verification. This check is done in patch 10/15. The Trusted Computing paradigm measure and load is respected: either the digest list has been measured and local verification can be done, or individual digests are reported. I would compare the digest list measurement as the same as the measurement of a security policy containing allowed permissions. Trusting the measurement of the policy and the system means trusting the system to enforce the security policy. > Not to mention that leaving out "known" hashes from attestation eliminates the > ability to do analytics on the patterns of usage of the good files. Local appraisal is a > good thing, but not a complete substitute for remote attestation. Patch 11/15 gives the possibility to selectively enable digest list lookup for specific rules. This means that, for example, digest lookup can be enabled for PCR 10, so that its value is predictable and can be used for sealing policies, and disabled for a different PCR, which can be used to report more information. >> Second, managing large measurement >> lists requires computation power and network bandwidth. > > So 200 nodes with 5000 entries, 100bytes per entry average (that's a pretty large TCB, but OK): > that's roughly .8 seconds total on a single Gb link. I was also considering the overhead due to using the TCG format (XML). >> Third, it is >> necessary to obtain reference measurements (i.e. digests of software >> known to be good) to evaluate/enforce the integrity of the system. If file >> signatures are used to enforce access, Linux distribution vendors have to >> modify their building systems in order to include signatures in their packages. > > Or you can use the initial enrollment to transfer a reference manifest. > Or you can use SWIDS. Or you can sign everything yourself. (That's what we do.) The first two suggestions look similar to what I'm proposing, having a list of digests signed by the vendor. >> Digest lists aim at mitigating these issues. A digest list is a list of digests that >> are taken by IMA as reference measurements and loaded before files are >> accessed. Then, IMA compares calculated digests of accessed files with >> digests from loaded digest lists. If the digest is found, measurement, >> appraisal and audit are not performed. > > So who manages the "good" hash lists? They have to go into the initramfs, > and be updated with every package update. And Leaving out attestation of > good TCB files reduces the potential power of analytics. The initial ram disk should contain at least (for appraisal) the digests of files that will be accessed before the root filesystem is mounted. Then, the remaining digest lists can be loaded by systemd, for example. Previously, I mentioned the possibility of using different PCRs for a more complete report. But, if a sealing policy for PCR 10 should provide more guarantees than just which set of files can be possibly accessed (for example, which subset of files have been actually accessed), this can be achieved by extending the TPM with the digest of a policy to check that condition, and creating a measurement entry when the condition becomes true. This will keep the PCR 10 value predictable. I have an use case for the predictable state: I want to seal the EVM key to PCR 10, use the key to protect mutable files and enforce the Biba strict policy in order to allow writes to mutable files only by the TCB. Then, if the EVM key is securely generated (sensitiveDataOrigin is set), and the system proves during remote attestation that the expected key has been loaded and PCR values match those used to seal the key, the measurement of mutable files can be avoided. >> Multiple digest lists can be loaded at the same time, by providing to IMA >> metadata for each list: digest, signature and path. The digest is specified so >> that loaded digest lists can be identified only with the measurement of >> metadata. The signature is used for appraisal. If the verification succeeds, >> IMA loads the digest list even if security.ima is missing. >> >> Digest lists address the first issue because the TPM is used only if the digest >> of a measured file is unknown. On a minimal system, 10 of 1400 >> measurements are unknown because of mutable files (e.g. log files). > > At 5ms per extend, you at most save 7 seconds at boot. But the savings are > actually much less, as the extends run simultaneously with most of the > other boot operations. I typically can't tell the difference without a > stopwatch. I performed some tests on a HP EliteDesk 800 G2. The boot time without an IMA policy is 8.5 seconds. With the IMA policy and without the TPM performance patches is 1 minute and 30 seconds. With the TPM performance patches is 24 seconds. 1400 measurements are recorded. Roberto >> Digest lists mitigate the second issue because, since digest lists do not >> change, they don't have to be sent at every remote attestation. Sending >> unknown measurements and a reference to digest lists would be sufficient. > > The .8 second isn't a problem, and even that can be pretty much eliminated by > sending just the delta measurements. > >> Finally, digest lists address also the third issue because Linux distribution >> vendors already provide the digests of files included in each RPM package. >> The digest list is stored in the RPM header, signed by the vendor. > > But then tooling is needed to select the desired hashes and put them in > the initramfs for loading. > > I guess I don't see the problem, and think the cure introduces issues of its own. > > dave > -- HUAWEI TECHNOLOGIES Duesseldorf GmbH, HRB 56063 Managing Director: Bo PENG, Qiuen PENG, Shengli WANG