From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932156AbbKBSwf (ORCPT ); Mon, 2 Nov 2015 13:52:35 -0500 Received: from mail-ig0-f169.google.com ([209.85.213.169]:38466 "EHLO mail-ig0-f169.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752190AbbKBSwa (ORCPT ); Mon, 2 Nov 2015 13:52:30 -0500 MIME-Version: 1.0 In-Reply-To: References: <20151102180624.GA28014@ikki.ethgen.ch> Date: Mon, 2 Nov 2015 10:52:30 -0800 X-Google-Sender-Auth: dJg6gK1gmlZTcgdc5lPUaCOKQj0 Message-ID: Subject: Re: Kernel 4.3 breaks security in systems using capabilities From: Linus Torvalds To: Richard Weinberger Cc: Klaus Ethgen , LKML , Christoph Lameter , Andy Lutomirski , Serge Hallyn , Kees Cook , Andrew Morton Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Nov 2, 2015 at 10:38 AM, Richard Weinberger wrote: >> >> With the patch above, any process that is spawned by such a program will >> inherit the raised capabilities if it has no own filecapabilities set. Do you actually have a real example of this? The ambient capabilities stay empty unless you explicitly raise them. So your old workflow shouldn't actually have any change in it at all. And if your old workflow gave a capability to something you don't trust, and that then decides to now uses the ambient capabilities, what does that change? It had the capability already. So please explain what it is you actually object to. With actual real issues. If behavior actually changed of existing setups, then that would be a bug, and yes, it should be fixed. The new ambient capabilities should only matter when you choose to use them. Linus