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 60D90C433EF for ; Fri, 15 Jul 2022 19:38:47 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229455AbiGOTiq (ORCPT ); Fri, 15 Jul 2022 15:38:46 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:41662 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229966AbiGOTin (ORCPT ); Fri, 15 Jul 2022 15:38:43 -0400 Received: from mail-ed1-x52f.google.com (mail-ed1-x52f.google.com [IPv6:2a00:1450:4864:20::52f]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 38CBC638D for ; Fri, 15 Jul 2022 12:38:41 -0700 (PDT) Received: by mail-ed1-x52f.google.com with SMTP id r6so7565129edd.7 for ; Fri, 15 Jul 2022 12:38:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=message-id:date:mime-version:user-agent:subject:content-language:to :cc:references:from:in-reply-to:content-transfer-encoding; bh=EcHI0RFme1P+FHdB6sWN7r2D7IfzNHh0dba57jzLiec=; b=PVXIyx1Jlo5l6dsDhDIeAOd52cDUe7BouKInskEDgw8F3WFBCdhmvz5PfRtKvdKW/Q EfXTW+WHLZIdjdc9lyi5A7r3n5erxOZ/T/gqpmwD5/EnofvbaSNz07NwKK9UpEs554sx oo8GPoaNK6MZMEhkEv39Aw5p1G3EBnVHea05lqXnaXP+rlaQfkpWttPoqd0YnL6KhmF2 lnzGUXm/xRRhVUKh2ooV37jau1IJjnD9J/9byJZ1BJqRVt60YyD61RkZU9LTOm/6CTM+ rAqQTki+ZLUhz2rcrbFTSUVUjKPjvfIwnGvhbSSd1cSUihw5EPCcblzhJOaYisyKfxnr tsRw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:cc:references:from:in-reply-to :content-transfer-encoding; bh=EcHI0RFme1P+FHdB6sWN7r2D7IfzNHh0dba57jzLiec=; b=R26mxxE4Vdo62Wb+vUPQPvxkSQg6Rv9zo7wpzjtSvlLk19W0b9zY4FspzTkbAg8W6U XSVxSiP7hesD1UlynbqNhx2jn6sEJxP7ttFl5+Jp2RajL/wrGam0rmMbOFNoRfTDRvng 1ziPHxnYIHJWDeFVVIMF2FC9jGY7zv9rKJLgsoMyMVz5Rjrfxiy6HoVRIOo77JHmkP5q jt/MGYLY+km5jD4kEv+HECiHI7iwJXWOikQoxOwZvGEg6DXzcSzuOprtdcu5wTR8Flzv oC8t1w6NgNFHC1kkeyE9uGBF2I5xUEm4lHpA8pLOz5DbF5Y7dlrj3J7V+K2qLJ+0sSqp l93w== X-Gm-Message-State: AJIora/p7uGnKe11SuzEXHCcc1Ave0PGbm0I58+hHbIv3HmvtoqFq2/z nJvmHD4KlLGnFfrw9lfkzE0= X-Google-Smtp-Source: AGRyM1t7ZLWeZqKRDMnbSZm440nvKe3q7hq5HnywN8/NkfbVf3xIOHWfjSVlGbYdoxccZXlAOXhWPg== X-Received: by 2002:aa7:dcd5:0:b0:43a:70f7:8e4d with SMTP id w21-20020aa7dcd5000000b0043a70f78e4dmr20604931edu.85.1657913919826; Fri, 15 Jul 2022 12:38:39 -0700 (PDT) Received: from [192.168.1.4] (78-3-70-107.adsl.net.t-com.hr. [78.3.70.107]) by smtp.gmail.com with ESMTPSA id cw11-20020a056402228b00b0043a8f40a038sm3370511edb.93.2022.07.15.12.38.37 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 15 Jul 2022 12:38:39 -0700 (PDT) Message-ID: Date: Fri, 15 Jul 2022 21:38:35 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Firefox/91.0 Thunderbird/91.10.0 Subject: Re: [dm-devel] [PATCH 1/1] dm: add message command to disallow device open Content-Language: en-US To: Mikulas Patocka , Daniil Lunev Cc: dm-devel@redhat.com, Mike Snitzer , Brian Geffon , Alasdair Kergon , linux-kernel@vger.kernel.org References: <20220704000225.345536-1-dlunev@chromium.org> <20220704100221.1.I15b3f7a84ba5a97fde9276648e391b54957103ff@changeid> From: Zdenek Kabelac In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Dne 15. 07. 22 v 11:36 Mikulas Patocka napsal(a): > > On Fri, 15 Jul 2022, Daniil Lunev wrote: > >> Hi Mike, >> Thank you for your response. I should have probably added more context >> to the commit message that I specified in the cover letter. The idea is to >> prohibit access of all userspace, including the root. The main concern here >> is potential system applications' vulnerabilities that can trick the system to >> operate on non-intended files with elevated permissions. While those could >> also be exploited to get more access to the regular file systems, those firstly >> has to be useable by userspace for normal system operation (e.g. to store >> user data), secondly, never contain plain text secrets. Swap content is a >> different story - access to it can leak very sensitive information, which >> otherwise is never available as plaintext on any persistent media - e.g. raw >> user secrets, raw disk encryption keys etc, other security related tokens. >> Thus we propose a mechanism to enable such a lockdown after necessary >> configuration has been done to the device at boot time. >> --Daniil > If someone gains root, he can do anything on the system. > > I'm quite skeptical about these attempts; protecting the system from the > root user is never-ending whack-a-mole game. It's in fact a 'design feature' of whole DM  that root can always open any device in device stack (although cause some troubles to i.e. some lvm2 logic) such feature is useful i.e. for debugging device problems. There was never an intention to prohibit root user from 'seeing' all stacked devices. Regards Zdenek