Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933513AbeAKVue (ORCPT + 1 other); Thu, 11 Jan 2018 16:50:34 -0500 Received: from wtarreau.pck.nerim.net ([62.212.114.60]:39665 "EHLO 1wt.eu" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932906AbeAKVuc (ORCPT ); Thu, 11 Jan 2018 16:50:32 -0500 Date: Thu, 11 Jan 2018 22:49:39 +0100 From: Willy Tarreau To: Dave Hansen Cc: Linus Torvalds , Andy Lutomirski , Peter Zijlstra , LKML , X86 ML , Borislav Petkov , Brian Gerst , Ingo Molnar , Thomas Gleixner , Josh Poimboeuf , "H. Peter Anvin" , Greg Kroah-Hartman , Kees Cook Subject: Re: [RFC PATCH v2 6/6] x86/entry/pti: don't switch PGD on when pti_disable is set Message-ID: <20180111214939.GB15528@1wt.eu> References: <1515502580-12261-1-git-send-email-w@1wt.eu> <1515502580-12261-7-git-send-email-w@1wt.eu> <20180110082207.GX29822@worktop.programming.kicks-ass.net> <20180110091102.GH14066@1wt.eu> <20180111064259.GC14920@1wt.eu> <0f08d89e-61e1-20e3-5c59-0b2f7b32bf0c@linux.intel.com> <20180111154412.GA15296@1wt.eu> <06a7c031-3ef9-7f8d-6292-18e2cca0698a@linux.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <06a7c031-3ef9-7f8d-6292-18e2cca0698a@linux.intel.com> User-Agent: Mutt/1.6.1 (2016-04-27) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Return-Path: On Thu, Jan 11, 2018 at 10:35:57AM -0800, Dave Hansen wrote: > On 01/11/2018 07:44 AM, Willy Tarreau wrote: > >> 4. Cleared on setuid() and friends > > This one causes me a problem : some daemons already take care of dropping > > privileges after the initial fork() for the sake of security. Haproxy > > typically does this at boot : > > > > - parse config > > - chroot to /var/empty > > - setuid(dedicated_uid) > > - fork() > > This makes me a _bit_ nervous. I think Andy touched on this, but I'll > say it another way: you want PTI turned off because you trust an app to > be good, but you also drop permissions because it is exposed to an > environment where you do *not* fully trust it. > > I'm not sure how you reconcile that. > > If your proxy gets compromised, and pti is turned off, you are entirely > exposed to meltdown from that process. Yes but security is not either black or white, it's about adding protections that make sense wherever possible. Meltdown would "only" allow you to dump the system's memory. Running as root would additionally allow you to modify this memory, ptrace processes outside of the chroot to inject backdoors etc. For me, and for a lot of users I guess, the choice is easily made. > I don't know exactly what you > are doing, but isn't this proxy sitting there shuffling untrusted user > data around all day? Yes definitely for some users, while it can be very trusted data for others. For example those dealing with wire transfers have much more to care about than someone reading their kernel memory when they can also read and modify the amount of money in the transfers if they want! And it has to do all this *fast*, that's one of its most touted qualities. And that's even why people who care the most about performance always install it on Linux because today it's the best OS for this job. Again Dave, it's a tradeoff. People using such components generally know what they are doing and are the ones to decide. Some of them prefer to run as root because it allows them to bind to foreign addresses, others cannot start as root because the local policy is strict about this, some do a lot of things some of us would consider ugly but which are critical to their acitvity. It's not up to me as the software's author nor to us as system developers to tell our users how they will be much slower to be more secure if they decide that they don't care about this *specific* risk. Our job is to properly protect those who don't know they're at risk and to help the other ones reduce the risk to the minimum needed for a given task. In this case the minimum can be pretty well summarized : - PTI on by default on the system - no PTI for the performance-sensitive process if the admin decides it - switch to a harmless uid/gid couple once not needed to be root anymore - if the process may execute external processes, give it an option to disable PTI before or during execve() to avoid exposing the system to what they could be doing. I think that's pretty reasonable for a normal production environment. Willy