Received: by 2002:a05:6902:102b:0:0:0:0 with SMTP id x11csp674697ybt; Mon, 6 Jul 2020 20:09:09 -0700 (PDT) X-Google-Smtp-Source: ABdhPJx5wWrPGBMqa4aNFkx4wDoliu2wgPNmaWXkUkmOJ5e3izNqPXT5docGyl4X1VENvgjsvZjA X-Received: by 2002:a17:906:538e:: with SMTP id g14mr45311371ejo.300.1594091349454; Mon, 06 Jul 2020 20:09:09 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1594091349; cv=none; d=google.com; s=arc-20160816; b=hfYx2YeG+1U+rdwzKIDkazrRFY4c5yq3TBXNbSo/3fpUJEn3gkQ3vgnS6u6/JL4G67 WGY1OZoqXvW9G7fVM3FjhRxxXVcfttKqhgs12Z4Mj9tpUB9aYjTCymzztZ1F45avt0+N E1htBu1TE3pdVEsRbSDMzgoS86nK8w03TF3ASDZ9IsVrtW1o1xt+qrJkqI3tGGQAeno3 uwEz0xE6n6btTGaaUtqZWKYPMXgKJTgCnGJOEwUnABvznC9+1nwPuypqioR096FkzI00 9gE94tLw9U/fdfTjVJ+r6wJJkvvJAazML5V0Utq1U8d3swBwrU49I+isGK51o3QW5/8D cAQA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :dkim-signature; bh=mAgioibrvE891f5K7HmCJlPOrtHJXNuC1DkC4uszNXM=; b=Mtn3LrPCjZONtBThygs4ZIFXGu+urajQ1UKP0GF4y5d6LEC5/gIOFp+KTWIZj9cZFR YvWUOEPZfFyNTQTWITQ2jYKJdsYw+r4ItDtypPmdXhOEOI6v8ucBD3yUagnmrSiGQXTP sf7cUEksgLqhpoozmEyozEBdHgbkOztowdUiRYDYvKp8qCGr3gEZ9qLgOLU5uGkPZEmb Nmk+3qhA6P6rTcL87t/dvOeXUIQeKT31zCnwLvV1TZ+ntqztpDTv1/+bCci6DXQNRh+6 vHS0iUm/Php0uMpB9/HDE7jFIyyt/ai5cglNYWAC1F7E83w1DanzM+jn2Mm1x5fJPuPL XZSg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@chromium.org header.s=google header.b=gP+Wl4DJ; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=chromium.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id s23si13219669eji.327.2020.07.06.20.08.46; Mon, 06 Jul 2020 20:09:09 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@chromium.org header.s=google header.b=gP+Wl4DJ; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=chromium.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728103AbgGGDIi (ORCPT + 99 others); Mon, 6 Jul 2020 23:08:38 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:60234 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727945AbgGGDIh (ORCPT ); Mon, 6 Jul 2020 23:08:37 -0400 Received: from mail-pl1-x643.google.com (mail-pl1-x643.google.com [IPv6:2607:f8b0:4864:20::643]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id DF3C9C08C5DF for ; Mon, 6 Jul 2020 20:08:37 -0700 (PDT) Received: by mail-pl1-x643.google.com with SMTP id x9so2484901plr.2 for ; Mon, 06 Jul 2020 20:08:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=mAgioibrvE891f5K7HmCJlPOrtHJXNuC1DkC4uszNXM=; b=gP+Wl4DJKDJ3UySQvm6ehWCx/RKB143fnyHUuQ0t9BRhhXM335BMaeWAeNXiPHFS+A yuJXG+rXHT/me7lsV8JRFhJGr0PHF+YCM9CfQH6E2adRJBk43IvCMRwvvBVl3/3Ixm3I fq54xhOeSkABkDAJr2DPslruFRUcT0nLWUjG0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=mAgioibrvE891f5K7HmCJlPOrtHJXNuC1DkC4uszNXM=; b=KdeoUCMa7LZpHiSUzAiIveErV3IQxlqpzExKNA5qs4MevA3+pDTg5RIdUYBnjDLvtZ ZvsE+h/shmMCyFGgUuoE9x231/WoOSUadCSpizQokF1J5ebUgQEtJkvvD/a7z5TL5Bfa uN/2sCcV6bpTNrBhV5uAbjRUxZeNSF2uiJ8sUE1cv4l+UJeddvQr3rfxQZYHTSPr+zK6 QeFx0yMEDfArj9h+nRcT5CRUnCUvvdkrZlzimcML2yUexFvah1iKoTc+Uwz2/mTtr7Hl h4wGq+z52MuxNgePyYNO3uB+ZMqJF1DVvh/jO6UUryOaLp/erVFz0qFKP9WHMOc5ofAX H3+A== X-Gm-Message-State: AOAM533BhKTUENW3fHeUg/sR7bRVsTLjkQ1aOk2U1BNYhgz7TQCsXnAu CKDLEhW0zoHGevx1ATiw9f6ZSg== X-Received: by 2002:a17:902:b204:: with SMTP id t4mr45161895plr.132.1594091317238; Mon, 06 Jul 2020 20:08:37 -0700 (PDT) Received: from www.outflux.net (smtp.outflux.net. [198.145.64.163]) by smtp.gmail.com with ESMTPSA id f14sm20750527pgj.62.2020.07.06.20.08.36 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 06 Jul 2020 20:08:36 -0700 (PDT) Date: Mon, 6 Jul 2020 20:08:35 -0700 From: Kees Cook To: Scott Branden Cc: Luis Chamberlain , Wolfram Sang , Greg Kroah-Hartman , David Brown , Alexander Viro , Shuah Khan , bjorn.andersson@linaro.org, Shuah Khan , Arnd Bergmann , Mimi Zohar , "Rafael J . Wysocki" , linux-kernel@vger.kernel.org, linux-arm-msm@vger.kernel.org, linux-fsdevel@vger.kernel.org, BCM Kernel Feedback , Olof Johansson , Andrew Morton , Dan Carpenter , Colin Ian King , Takashi Iwai , linux-kselftest@vger.kernel.org, Andy Gross , linux-integrity@vger.kernel.org, linux-security-module@vger.kernel.org Subject: Re: [PATCH v10 9/9] ima: add FIRMWARE_PARTIAL_READ support Message-ID: <202007061950.F6B3D9E6A@keescook> References: <20200706232309.12010-1-scott.branden@broadcom.com> <20200706232309.12010-10-scott.branden@broadcom.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200706232309.12010-10-scott.branden@broadcom.com> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Jul 06, 2020 at 04:23:09PM -0700, Scott Branden wrote: > Add FIRMWARE_PARTIAL_READ support for integrity > measurement on partial reads of firmware files. Hi, Several versions ago I'd suggested that the LSM infrastructure handle the "full read" semantics so that individual LSMs don't need to each duplicate the same efforts. As it happens, only IMA is impacted (SELinux ignores everything except modules, and LoadPin only cares about origin not contents). Next is the problem that enum kernel_read_file_id is an object TYPE enum, not a HOW enum. (And it seems I missed the addition of READING_FIRMWARE_PREALLOC_BUFFER, which may share a similar problem.) That it's a partial read doesn't change _what_ you're reading: that's an internal API detail. What happens when I attempt to do a partial read of a kexec image? I'll use kernel_pread_file() and pass READING_KEXEC_IMAGE, but the LSMs will have no idea it's a partial read. Finally, what keeps the contents of the file from changing between the first call (which IMA will read the entire file for) and the next reads which will bypass IMA? I'd suggested that the open file must have writes disabled on it (as execve() does). So, please redesign this: - do not add an enum - make the file unwritable for the life of having the handle open - make the "full read" happen as part of the first partial read so the LSMs don't have to reimplement everything -Kees -- Kees Cook