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 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 02465C76196 for ; Mon, 10 Apr 2023 21:44:53 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229731AbjDJVow (ORCPT ); Mon, 10 Apr 2023 17:44:52 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:40926 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229523AbjDJVov (ORCPT ); Mon, 10 Apr 2023 17:44:51 -0400 Received: from mail-yb1-xb2f.google.com (mail-yb1-xb2f.google.com [IPv6:2607:f8b0:4864:20::b2f]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 709781982 for ; Mon, 10 Apr 2023 14:44:50 -0700 (PDT) Received: by mail-yb1-xb2f.google.com with SMTP id z9so6064991ybs.9 for ; Mon, 10 Apr 2023 14:44:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=paul-moore.com; s=google; t=1681163089; x=1683755089; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=2fqJKygNcTwYXqE/W6HnsQWcXW83jUHOxTtEqQQFCCQ=; b=c8gGW9KEuUs7rOxRy31qPsb5UswCPfrRfqTb0L97WfXCBmTDp1kP7o+kOv1iiUZNxa Lc7XrALeZ43cdvsL5ChYw5E/BViCfJHj8cjUk8BE7YDRTUWxDMcsG0D0W7VYXtSQefgp fbV5QjibYa0q+unpvL5PUVWs5aGUlCfuih1I8/0uqSWe42iN3cO9WgV68A2tDis0uF67 J4dWNfpWzVf5r+xmiIMt+6kgDAeHk+TSdkHiA5C4OjKepRdlTcaQrQErR/Ao/ae/Y7Yo K/5VYanNEQOKwqVaYLvETpgywJl6QxAlUozFRcx6V4ypX4MQabwP9YpEWDJvnRmBHT5W QKqA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1681163089; x=1683755089; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=2fqJKygNcTwYXqE/W6HnsQWcXW83jUHOxTtEqQQFCCQ=; b=XUPbLMkRM4qtOOswNxzKI2KjS2tmGf37ZrxPmi+L1Qjf+aOsRt23sw+zEqq2PGwixR Zlux/4tIY8jjL+RAqQ8MiKFuA84ldriGmIr+0k2DFyj8ZcqYJYQecba84d61+c3kGmgT LbzEeCAUqi0U4RuWz8Y132PzafmOgZLTUh5Kgy0D6REVFAqA+PjC1gADTl2aDG86pkDb 3hCIOuyq2xwM1Z90wQt+jVkspKC/Sv5hoNrp4bywO5RLTF/DoBlAQbR19SAzQntD3T5U dT0wUGckGVckCeqny2De3VET7rLt8695vcwsk8z7M7M59SaPXg45ht8EzuTNoM/oTj+T WIkw== X-Gm-Message-State: AAQBX9cisAnmbsInDQuW5u4IZFbFwZPen/xH8VZQ9xYHxdxch4vR4Hve nZs2zsonxVRz4P3H8+3Jdz3qpcbuXkbqNEiRhWbG X-Google-Smtp-Source: AKy350bw7pWEBerXtD57WYRkTF0n63gFcuFSKH0/ueLBXUsY3z6l7NJlgmPBBAhKqYb2e6cxx21TLQycOA6L5f9O+wE= X-Received: by 2002:a25:d70d:0:b0:b68:7a4a:5258 with SMTP id o13-20020a25d70d000000b00b687a4a5258mr7739153ybg.3.1681163089576; Mon, 10 Apr 2023 14:44:49 -0700 (PDT) MIME-Version: 1.0 References: <93ef5db7-fb4d-bf3f-9456-3fb6e7d5ca29@oracle.com> In-Reply-To: From: Paul Moore Date: Mon, 10 Apr 2023 17:44:38 -0400 Message-ID: Subject: Re: Semantics of blktrace with lockdown (integrity) enabled kernel. To: Junxiao Bi Cc: Konrad Rzeszutek Wilk , linux-kernel@vger.kernel.org, linux-security-module@vger.kernel.org, jmorris@namei.org, serge@hallyn.com, nathanl@linux.ibm.com, joe.jin@oracle.com, Eric , Boris Ostrovsky , axboe@kernel.dk Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: On Mon, Apr 10, 2023 at 5:28=E2=80=AFPM Junxiao Bi = wrote: > On 4/10/23 1:22 PM, Paul Moore wrote: > > On Mon, Apr 10, 2023 at 3:20=E2=80=AFPM Junxiao Bi wrote: > >> On 4/6/23 2:43 PM, Paul Moore wrote: > >>> On Thu, Apr 6, 2023 at 3:33=E2=80=AFPM Konrad Rzeszutek Wilk > >>> wrote: > >>>> On Thu, Apr 06, 2023 at 02:39:57PM -0400, Paul Moore wrote: > >>> ... > >>> > >>>>> Before we go any further, can you please verify that your issue is > >>>>> reproducible on a supported, upstream tree (preferably Linus')? > >>>> Yes. Very much so. > >>> Okay, in that case I suspect the issue is due to the somewhat limited > >>> granularity in the lockdown LSM. While there are a number of > >>> different lockdown "levels", the reality is that the admin has to > >>> choose from either NONE, INTEGRITY, or CONFIDENTIALITY. Without > >>> digging to deep into the code path that you would be hitting, we can > >>> see that TRACEFS is blocked by the CONFIDENTIALITY (and therefore > >>> INTEGRITY too) setting and DEBUGFS is blocked by the INTEGRITY > >>> setting. With DEBUGFS blocked by INTEGRITY, the only lockdown option > >>> that would allow DEBUGFS is NONE. > >>> > >>> Without knowing too much about blktrace beyond the manpage, it looks > >>> like it has the ability to trace/snoop on the block device operations > >>> so I don't think this is something we would want to allow in a > >>> "locked" system. > >> blktrace depends on tracepoint in block layer to trace io events of > >> block devices, > >> > >> through the test with mainline, those tracepoints were not blocked by > >> lockdown. > >> > >> If snoop block devices operations is a security concern in lock down, = these > >> > >> tracepoints should be disabled? > > Possibly, however, as I said earlier I'm not very familiar with > > blktrace and the associated tracepoints. If it is possible to snoop > > on kernel/user data using blktrace then it probably should be > > protected by a lockdown control point. > > > > Is this something you could verify and potentially submit a patch to re= solve? > > blktrace can not snoop kernel/user data. The information it got from > kernel is kind of "io metadata", basically include which process from > which cpu, at what time, triggered what kind of IO events(issue, queue, > complete etc.), to which disk, from which sector offset and how long. > blktrace has no way to know what's inside that io. I am kind of think > this is safe for lockdown mode. Well, you could always submit a patch* and we would review it like any other; that's usually a much better approach. * Yes, there was a patch submitted, but it was against a distro kernel that diverged significantly from the upstream kernel in the relevant areas. --=20 paul-moore.com