Received: by 10.213.65.68 with SMTP id h4csp1818314imn; Thu, 29 Mar 2018 11:36:07 -0700 (PDT) X-Google-Smtp-Source: AIpwx48IJCHA2nrR0fsJ1M+dwrCDJkrSQn58HQmNbDlQkTIWWQcc+YQfwpQpikDpvPzn9sxEIiq9 X-Received: by 10.101.97.134 with SMTP id c6mr6339517pgv.370.1522348567698; Thu, 29 Mar 2018 11:36:07 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1522348567; cv=none; d=google.com; s=arc-20160816; b=YivKDzvkW9PosyY5cro6hmT1caifMk80FE37hxFmSwRG5HotP/tEbWl3PK9hjz9ncP LY3S+SU8CpzPe4BhcFYwq7HVQ3WsE9LcyXkAvhao5T49dFU5hxmOZCBfjqp5pKArzAqX KVOtUdJcQQhd7/ncdvo41MlqReMq2bsAd++nJALyD1pusku0xHb9IMdKt5PiwdZkizCs 5fv20avrP2G1jaa80ZfboM+txlWD8jt0w1v9v5+Rl6VD99hiPwzPYGoRdQ0stSQBnz6b G9dzgGhAHlrA3mUwo5bpWWnuzJ+edc03TGUYp55rLX0ujMT1teDHMrilWujLblzVNAb6 TrtQ== 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 :arc-authentication-results; bh=yH7C4REB9QSm1PGqcYq16KpLI2KMSsn/rnkMCJAS7iY=; b=aByaEOf1qAIYsNqkarCRjvFecQWAfkzQLUfyICmGI+5hwq58Uf9XLOQCCViXUBIRtU UsQ3Z84d1frX5vP7aUOBsumhBkqokjQ8TQkX2gh0PVgogRl0KaB4QekqGpMrbMeFWALo rXzD3XBS9XwiJ7cbADcPLFrzbm585VUUDi1ZTwGu/Wk3V3fq+XFo0OmRxdz6CoSdHl+j gI4TJ++X7WniptZpAWYaMEWBAEgpi4ICFamQzumefKtiD50br6eFwgBsKD854yRv3S9j j7v8s2Wy2lq67Q7PZaHBSXpHXCL5l7/KEK+bSWwPpxQNoeTTHm6bRAu4wqEs9UWNV5hl V0XA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id e16si5001806pfd.6.2018.03.29.11.35.53; Thu, 29 Mar 2018 11:36:07 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753004AbeC2Set (ORCPT + 99 others); Thu, 29 Mar 2018 14:34:49 -0400 Received: from faui03.informatik.uni-erlangen.de ([131.188.30.103]:56648 "EHLO faui03.informatik.uni-erlangen.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752799AbeC2Ser (ORCPT ); Thu, 29 Mar 2018 14:34:47 -0400 X-Greylist: delayed 412 seconds by postgrey-1.27 at vger.kernel.org; Thu, 29 Mar 2018 14:34:46 EDT Received: from faui06a.informatik.uni-erlangen.de (faui06a.informatik.uni-erlangen.de [IPv6:2001:638:a000:4130:131:188:30:200]) by faui03.informatik.uni-erlangen.de (Postfix) with ESMTP id EB50A24042B; Thu, 29 Mar 2018 20:27:31 +0200 (CEST) Received: by faui06a.informatik.uni-erlangen.de (Postfix, from userid 30064) id DC02EB61C06; Thu, 29 Mar 2018 20:27:31 +0200 (CEST) Date: Thu, 29 Mar 2018 20:27:30 +0200 From: catchall@ghostav.ddnss.de To: Scott Bauer Cc: Jonas Rabenstein , Christoph Hellwig , Jonathan Derrick , Jens Axboe , linux-block@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v2 08/11] block: sed-opal: ioctl for writing to shadow mbr Message-ID: <20180329182730.nrdfgdye5jbark4g@ghostav.ddnss.de> References: <9f94be9c32887aacdcba75bd6a3902d0350eb987.1521482296.git.jonas.rabenstein@studium.uni-erlangen.de> <20180319195224.GA3380@lst.de> <20180320093604.qge2sdnc5jrud6kg@studium.uni-erlangen.de> <20180320220907.zdzf7baag6haaonm@sbauer-Z170X-UD5> <20180321014321.xlkcyvcyr6j3usix@studium.uni-erlangen.de> <20180329173002.5mmhnl4urj4wovyo@studium.uni-erlangen.de> <20180329171641.5cgnpldzq7j3ndhp@sbauer-Z170X-UD5> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180329171641.5cgnpldzq7j3ndhp@sbauer-Z170X-UD5> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Mar 29, 2018 at 11:16:42AM -0600, Scott Bauer wrote: > Yeah, having to autheticate to write the MBR is a real bummer. Theoretically > you could dd a the pw struct + the shador MBR into sysfs. But that's > a pretty disgusting hack just to use sysfs. The other method I thought of > was to authenticate via ioctl then write via sysfs. We already save the PW > in-kernel for unlocks, so perhaps we can re-use the save-for-unlock to > do shadow MBR writes via sysfs? > > Re-using an already exposed ioctl for another purpose seems somewhat dangerous? > In the sense that what if the user wants to write the smbr but doesn't want to > unlock on suspends, or does not want their PW hanging around in the kernel. Well. If we would force the user to a two-step interaction, why not stay completely in sysfs? So instead of using the save-for-unlock ioctl, we could export each security provider( (AdminSP, UserSPX, ...) as a sysfs directory with appropriate files (e.g. mbr for AdminSP) as well as a 'unlock' file to store a users password for the specific locking space and a 'lock' file to remove the stored password on write to it. Of course, while this will prevent from reuse of the ioctl and stays within the same configuration method, the PW will still hang around in the kernel between 'lock' and 'unlock'. Another idea I just came across while writing this down: Instead of storing/releasing the password permanently with the 'unlock' and 'lock' files, those may be used to start/stop an authenticated session. To make it more clear what I mean: Each ioctl that requires authentication has a similar pattern: discovery0, start_session, , end_session Instead of having the combination determined by the ioctl, the 'unlock' would do discovery0 and start_session while the 'lock' would do the end_session. The user is free to issue further commands with the appropriate write/reads to other files of the sysfs-directory. While this removes the requirement to store the key within kernel space, the open session handle may be used from everybody with permissions for read/write access to the sysfs-directory files. So this is not optimal as not only the user who provided the password will finally be able to use it. I already did some basic work to split of the session-information from the opal_dev struct (initially to reduce the memory-footprint of devices with currently no active opal-interaction). So I think, I could get a proof-of-concept of this approach within the next one or two weeks if there are no objections to the base idea. Thank you, Jonas