From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932887AbbCPSPI (ORCPT ); Mon, 16 Mar 2015 14:15:08 -0400 Received: from mail-bn1on0117.outbound.protection.outlook.com ([157.56.110.117]:32457 "EHLO na01-bn1-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1754362AbbCPSPE (ORCPT ); Mon, 16 Mar 2015 14:15:04 -0400 From: Matthew Garrett To: "gnomes@lxorguk.ukuu.org.uk" CC: "keescook@chromium.org" , "linux-kernel@vger.kernel.org" , "james.l.morris@oracle.com" , "serge@hallyn.com" , "linux-security-module@vger.kernel.org" , "hpa@zytor.com" Subject: Re: Trusted kernel patchset Thread-Topic: Trusted kernel patchset Thread-Index: AQHQX/fTAooV4Q4CdEWM7HLx0fA65p0faksA Date: Mon, 16 Mar 2015 18:15:01 +0000 Message-ID: <1426529700.22371.20.camel@nebula.com> References: <1426282708-21485-1-git-send-email-matthew.garrett@nebula.com> <20150316144504.4e013789@lxorguk.ukuu.org.uk> In-Reply-To: <20150316144504.4e013789@lxorguk.ukuu.org.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2602:243:200f:a923:3e97:eff:fe42:415e] authentication-results: spf=none (sender IP is ) smtp.mailfrom=matthew.garrett@nebula.com; x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN1PR05MB422; x-forefront-antispam-report: BMV:1;SFV:NSPM;SFS:(10019020)(979002)(6009001)(377424004)(51704005)(24454002)(122556002)(103116003)(40100003)(2656002)(87936001)(36756003)(92566002)(2501003)(102836002)(2900100001)(2950100001)(62966003)(54356999)(50986999)(76176999)(99286002)(33646002)(86362001)(77156002)(106116001)(19580405001)(110136001)(2351001)(46102003)(19580395003)(3826002)(969003)(989001)(999001)(1009001)(1019001);DIR:OUT;SFP:1102;SCL:1;SRVR:BN1PR05MB422;H:BN1PR05MB423.namprd05.prod.outlook.com;FPR:;SPF:None;MLV:ovrnspm;PTR:InfoNoRecords;LANG:en; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:(601004)(5002010)(5005006);SRVR:BN1PR05MB422;BCL:0;PCL:0;RULEID:;SRVR:BN1PR05MB422; x-forefront-prvs: 05177D47DC Content-Type: text/plain; charset="utf-8" Content-ID: <5970128D7B21F04B810BE9C27EC132AE@namprd05.prod.outlook.com> MIME-Version: 1.0 X-OriginatorOrg: nebula.com X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Mar 2015 18:15:01.2395 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: d9cc6df8-58db-46f5-bf3e-083732d8ac63 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1PR05MB422 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 base64 to 8bit by nfs id t2GIFFS4027443 On Mon, 2015-03-16 at 14:45 +0000, One Thousand Gnomes wrote: > On Fri, 13 Mar 2015 11:38:16 -1000 > Matthew Garrett wrote: > > > 4) Used the word "measured" > > > > Nothing is being measured. > > Nothing is being trusted either. It's simple ensuring you probably have > the same holes as before. > > Also the boot loader should be measuring the kernel before it runs it, > thats how it knows the signature is correct. That's one implementation. Another is the kernel being stored on non-volatile media. > On other points: > > - your sysfs node is useless. I can mount over it to fake trusted and > fool apps even in a supposedly "trusted" environment - it has to be a > syscall I think so anything sensitive can invoke it directly from > statically bound code and get a true answer. The sysfs node isn't intended to be used as a mechanism for userspace to determine whether the kernel is trustworthy - there's clearly no way to do that, since anyone able to launch an untrusted kernel can simply modify it so that it lies there. It exists so that people deploying some form of trusted boot chain can enable the lockdowns while still within the trusted codebase. If you want to prove trustworthiness then you're still going to need something like TPM-based attestation. > - there are devices that do things triggered on read cycles. It might not > be a bad idea to lock down reading mem and kmem too Yeah, at the very least doing that for anything mapped as a device is entirely reasonable. Let me look at that. > - All suspend/resumes allow modifying the kernel. I can boot Linux > suspend, boot windows, modify the Linux restore image, boot Linux and > own the box. You would need to sign the resume image somehow I think or > just disable all suspend/resume I'm kind of torn on this - yes, there are deployment scenarios where hibernation can be used to circumvent the restrictions, but there are also scenarios where that can be avoided (eg, the bootloader verifies some state with respect to the hibernation image). > - Why pick on ASUS WMI - every magical firmware interface has this > property, and given how bad most firmware is I'd be more worried about > access to things like UEFI services or straight forward ACPI methods. The ASUS WMI driver basically allows the execution of an entirely unknown set of SMI calls, whereas all the other drivers execute a curated subset of functions. Specific platforms may have specific bugs, but in general we control access to firmware calls quite strictly. > Also consider user access to GPIO pins. You can do some very > interesting things on certain machines with those, such as glitching > device power rails for a few microseconds. Good point. In general there's also the risk that GPIOs may be used for features like TPM physical presence detection, so exposing those to userspace does seem like a bad idea. > What you don't document is the assumption about how the kernel boot > parameters are handled. A large number of boot parameters allow arbitrary > I/O access or allow code execution if used with skill and cunning. Things that spring to mind here: 1) The ability to disable IOMMUs (some handwaving about the number of machines that still don't have IOMMUs because security is a perfectly reasonable thing to perform product differentiation on I guess?) 2) Your previous concerns about being able to manipulate the memory map in hostile ways 3) Drivers that allow users to tell the kernel devices exist at arbitrary memory addresses and then benefit from probe routines that write blindly Are there any other categories you're worried about? I have made an effort to audit the generic kernel options and the only ones I'm especially worried about in category (3) are the earlyprintk ones, but obviously there's a bunch of old drivers that allow arbitrary addresses to be passed and cleaning those up would be worth it. {.n++%ݶw{.n+{G{ayʇڙ,jfhz_(階ݢj"mG?&~iOzv^m ?I