From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Google-Smtp-Source: AH8x225ecHnhPHvDxn1ZjFP4tSGxI0pFikHy0lWMED+bItyosAoGmS8iCepFB7NGMQ3XVQ33cMe0 ARC-Seal: i=1; a=rsa-sha256; t=1516808612; cv=none; d=google.com; s=arc-20160816; b=iEzxWzWeXWmkftNkFfcI1CvqRJ3g32A5xFp2VEHpRMILZdW7AwFhWInhJ4ROJZWIOK cr2mDF3qRXdA9AMmMMT+sNhjSjjpcz9g/AAD7ue/DEO+sAoYBuLgxjxAY08qyp+KmgiK PMpGOZFN83Mfp93lQWhDDfynyUN7o8bMAx0I2yLKnGpZpFHKQra7GKesDzNPa9q6nB8l OslMz5mlVRxRWzP84AzWHZLkxJ4Rq7bn0BLapWQh0gicgngcLdLaV9RitNniEtz+koG4 s++gLoeZtjV7vQUzUHdFlogc+17U69fxT5obmxaOcfT8uXDwBzJukhUyI2J9I5iCXsI+ 6gwg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:mime-version:organization:references :in-reply-to:message-id:subject:cc:to:from:date :arc-authentication-results; bh=V0iCKHIGVHBrs4mEh9h3jV8b/pXeSNkJsOzkzTDWW8Q=; b=Aq2X2VABBDzQ79TJZ9AyR/r0cF07xwS35eVPrYqLac3UJxDIQ4iHsd/VBONXYh3u20 F4J1Hnla+77PEo2UvFjEumq4WZRV5aUHgoiXsxlSqYMzekgc+0hefuyVRBF2Y9Qzh298 sgQxqjMQN4dQkvv2ZEjqs2GNmdVdFUUF03AiPauTpYZddKX1T7Qwd33RUiO0MH7rNKQp RAEWk9IA66+ZoXcuOE9HrnrAuxmSQd7icbMx0uYz3zZLJOA9fw9HF6cZzi/yjKUOoWJW Mgjoc0R0KUPh0eg3623abXfogJtxNrAZUYVWdD5uxZUVFZh4ZkvwkFLBXsAk17unVw4q qoqg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of gnomes@lxorguk.ukuu.org.uk designates 82.70.14.225 as permitted sender) smtp.mailfrom=gnomes@lxorguk.ukuu.org.uk Authentication-Results: mx.google.com; spf=pass (google.com: domain of gnomes@lxorguk.ukuu.org.uk designates 82.70.14.225 as permitted sender) smtp.mailfrom=gnomes@lxorguk.ukuu.org.uk Date: Wed, 24 Jan 2018 15:42:54 +0000 From: Alan Cox To: Dominik Brodowski Cc: Martin Schwidefsky , linux-kernel@vger.kernel.org, linux-s390@vger.kernel.org, kvm@vger.kernel.org, Heiko Carstens , Christian Borntraeger , Paolo Bonzini , Cornelia Huck , David Hildenbrand , Greg Kroah-Hartman , Jon Masters , Marcus Meissner , Jiri Kosina , w@1wt.eu, keescook@chromium.org, thomas.lendacky@amd.com, dwmw@amazon.co.uk, ak@linux.intel.com, pavel@ucw.cz Subject: Re: Avoiding information leaks between users and between processes by default? [Was: : [PATCH 1/5] prctl: add PR_ISOLATE_BP process control] Message-ID: <20180124154254.318ddde4@alans-desktop> In-Reply-To: <20180124083705.GA14868@light.dominikbrodowski.net> References: <1516712825-2917-1-git-send-email-schwidefsky@de.ibm.com> <1516712825-2917-2-git-send-email-schwidefsky@de.ibm.com> <20180123170719.GA4154@isilmar-4.linta.de> <20180124072953.50851fec@mschwideX1> <20180124083705.GA14868@light.dominikbrodowski.net> Organization: Intel Corporation X-Mailer: Claws Mail 3.15.1-dirty (GTK+ 2.24.31; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: =?utf-8?q?1590462291652474475?= X-GMAIL-MSGID: =?utf-8?q?1590489107586382442?= X-Mailing-List: linux-kernel@vger.kernel.org List-ID: On Wed, 24 Jan 2018 09:37:05 +0100 > To my understanding, Linux traditionally tried to aim for the security goal > of avoiding information leaks *between* users[+], probably even between > processes of the same user. It wasn't a guarantee, and there always were Not between processes of the same user in general (see ptrace or use gdb). > (and will be) information leaks -- and that is where additional safeguards > such as seccomp come into play, which reduce the attack surface against seccomp is irrelevant on many processors (see the Armageddon paper). You can (given willing partners) transfer data into and out of a seccomp process at quite a respectable rate depending upon your hardware features. > I am a bit worried whether this is a sign for a shift in the security goals. > I fully understand that there might be processes (e.g. some[?] kernel > threads) and users (root) which you need to trust anyway, as they can dumpable is actually very useful but only in a specific way. The question if process A is dumpable by process B then there is no meaningful protection between them and you don't need to do any work. Likewise if A and B can dump each other and are both running on the same ht pair you don't have to worry about them attacking one another. In all those cases they can do it with ptrace already. [There's a corner case here of using BPF filters to block ptrace] Alan