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=-0.7 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=unavailable 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 CCA4EC46477 for ; Thu, 13 Jun 2019 16:40:56 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id A5DFA20644 for ; Thu, 13 Jun 2019 16:40:56 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730895AbfFMQkv (ORCPT ); Thu, 13 Jun 2019 12:40:51 -0400 Received: from lhrrgout.huawei.com ([185.176.76.210]:33005 "EHLO huawei.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1730575AbfFMG5J (ORCPT ); Thu, 13 Jun 2019 02:57:09 -0400 Received: from LHREML712-CAH.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 81C2BB8CCEE475682587; Thu, 13 Jun 2019 07:57:07 +0100 (IST) Received: from [10.220.96.108] (10.220.96.108) by smtpsuk.huawei.com (10.201.108.35) with Microsoft SMTP Server (TLS) id 14.3.408.0; Thu, 13 Jun 2019 07:56:58 +0100 Subject: Re: [PATCH v3 0/2] ima/evm fixes for v5.2 To: Janne Karhunen CC: Mimi Zohar , , , , , References: <20190606112620.26488-1-roberto.sassu@huawei.com> From: Roberto Sassu Message-ID: <144bf319-ea0c-f6b6-5737-0aac34f37186@huawei.com> Date: Thu, 13 Jun 2019 08:57:05 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8"; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Originating-IP: [10.220.96.108] X-CFilter-Loop: Reflected Sender: owner-linux-security-module@vger.kernel.org Precedence: bulk List-ID: On 6/13/2019 8:01 AM, Janne Karhunen wrote: > On Wed, Jun 12, 2019 at 7:33 PM Roberto Sassu wrote: > >>> That's a pretty big change for the userland IMHO. Quite a few >>> configurations out there will break, including mine I believe, so I >>> hope there is a solid reason asking people to change their stuff. I'm >>> fine holding off all writing until it is safe to do so for now.. >> >> The goal of appraisal is to allow access only to files with a valid >> signature or HMAC. With the current behavior, that cannot be guaranteed. >> >> Unfortunately, dracut-state.sh is created very early. It could be >> possible to unseal the key before, but this probably means modifying >> systemd. > > Ok, I see the use case. Now, if you pull a urandom key that early on > during the boot, the state of the system entropy is at all time low, > and you are not really protecting against any sort of offline attack > since the file is created during that boot cycle. Is there really use > for using such key? Wouldn't it be possible to create a new config > option, say IMA_ALLOW_EARLY_WRITERS, that would hold the NEW_FILE flag > until the persistent key becomes available? In other words, it would > start the measuring at the point when the key becomes online? I also thought about similar solutions. Another is for example to keep the appraisal flags at file close, if security.ima is successfully added to the file. Initializing EVM with a key is not a trivial change, but it seemed better to me as it does not introduce exceptions in the IMA behavior. Roberto -- HUAWEI TECHNOLOGIES Duesseldorf GmbH, HRB 56063 Managing Director: Bo PENG, Jian LI, Yanli SHI