From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932210AbdJJTwF (ORCPT ); Tue, 10 Oct 2017 15:52:05 -0400 Received: from esa2.dell-outbound.iphmx.com ([68.232.149.220]:63126 "EHLO esa2.dell-outbound.iphmx.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756651AbdJJTwB (ORCPT ); Tue, 10 Oct 2017 15:52:01 -0400 From: X-LoopCount0: from 10.166.132.189 X-IronPort-AV: E=Sophos;i="5.43,359,1503378000"; d="scan'208";a="158746181" X-DLP: DLP_GlobalPCIDSS To: CC: , , , , , , , , , , Subject: RE: [PATCH v4 13/14] platform/x86: dell-smbios-wmi: introduce userspace interface Thread-Topic: [PATCH v4 13/14] platform/x86: dell-smbios-wmi: introduce userspace interface Thread-Index: AQHTPWLw3cTS1K7cw0KO72A4U9jBFKLVnUmA//+sfqCAAHEAgIAAAzyAgAAI5gD//6+j0IAIYciA//+tVaA= Date: Tue, 10 Oct 2017 19:51:58 +0000 Message-ID: References: <20171005145911.06a5644c@alans-desktop> <20171005154445.GC29347@kroah.com> <20171005155619.GA10938@pali> <20171005162810.GB4993@kroah.com> <9b58d0a8796948f39776d6bb38bcb9d6@ausx13mpc120.AMER.DELL.COM> <20171010204035.1b827bfe@alans-desktop> In-Reply-To: <20171010204035.1b827bfe@alans-desktop> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.143.242.75] Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by nfs id v9ALIrMO014950 Alan, > -----Original Message----- > From: Alan Cox [mailto:gnomes@lxorguk.ukuu.org.uk] > Sent: Tuesday, October 10, 2017 2:41 PM > To: Limonciello, Mario > Cc: gregkh@linuxfoundation.org; pali.rohar@gmail.com; dvhart@infradead.org; > andy.shevchenko@gmail.com; linux-kernel@vger.kernel.org; platform-driver- > x86@vger.kernel.org; luto@kernel.org; quasisec@google.com; > rjw@rjwysocki.net; mjg59@google.com; hch@lst.de > Subject: Re: [PATCH v4 13/14] platform/x86: dell-smbios-wmi: introduce > userspace interface > > > There are some "write once" items that for the general purpose user that > > won't brick a box, but should probably be blacklisted though. > > I'll think this through some more. > > I would strongly urge you to do whitelisting as it's good security. If > you can divide the calls into something like this it fits the Linxu > desktop model well: > > Safe -> anyone can do it > Console -> only console owner > Superuser -> administrator level (things that can be irritating but > don't persist a reboot) I've added filtering in my most recent submission (v6). I don't feel that any single one of these calls or pieces of data should be accessible without root. Furthermore discussion on the merits of different levels is stepping into bikeshedding territory. If someone wants to bubble up things that they feel are safe to read or write as user, that can be the job of a daemon or other service to decide not the kernel. > > Beyond that it's trickier - if you are an enterprise business then you > don't for example want to allow someone with root on the system to > subvert BIOS level settings they can't access. This level of split is actually comprehended already by the BIOS itself. When you enable an administrative password on the BIOS, you aren't able to access (read or write) a variety of settings without a security key (which requires some handshaking). > > You need a minimum of CAP_SYS_RAWIO for anything that can (through bugs > or design) subvert secure boot type stuff. It's also probably an > appropriate check for 'anything goes' if you decide to have that > category. CAP_SYS_RAWIO implies total power over the machine although > with secureboot it's less clear. > Secure boot can't programmatically be disabled from within OS.