Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755578AbbKETBa (ORCPT ); Thu, 5 Nov 2015 14:01:30 -0500 Received: from mail-ob0-f180.google.com ([209.85.214.180]:34105 "EHLO mail-ob0-f180.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751409AbbKETB2 (ORCPT ); Thu, 5 Nov 2015 14:01:28 -0500 MIME-Version: 1.0 In-Reply-To: <20151105174823.GD9307@ikki.ethgen.ch> References: <20151102191616.GA2158@ikki.ethgen.ch> <20151105101953.GA15293@ikki.ethgen.ch> <20151105161512.GA2180@mail.hallyn.com> <20151105171701.GB9307@ikki.ethgen.ch> <20151105173438.GA3378@mail.hallyn.com> <20151105174823.GD9307@ikki.ethgen.ch> From: Andy Lutomirski Date: Thu, 5 Nov 2015 11:01:07 -0800 Message-ID: Subject: Re: [KERNEL] Re: [KERNEL] Re: [KERNEL] Re: [KERNEL] Re: Kernel 4.3 breaks security in systems using capabilities To: Klaus Ethgen Cc: "Serge E. Hallyn" , Linus Torvalds , Richard Weinberger , 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 Content-Length: 3012 Lines: 64 On Thu, Nov 5, 2015 at 9:48 AM, Klaus Ethgen wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > Am Do den 5. Nov 2015 um 18:34 schrieb Serge E. Hallyn: >> > Am Do den 5. Nov 2015 um 17:15 schrieb Serge E. Hallyn: >> > > I think if you follow your idea to its logical conclusions, you end >> > > up wanting set SECURE_ALL_BITS | SECURE_ALL_LOCKS, which will include >> > > SECURE_NO_CAP_AMBIENT_RAISE, disabling ambient capabilities. >> > >> > That I did miss out and seems to be the solution for the problem. So >> > adding cap_secure_all_bits,cap_secure_all_locks=ep to every binary that >> > gets other caps should solve it? >> >> No that doesn't work, you have to use prctl to set those bits. If you >> can get your system to be fully rootless, you can have init or initramfs >> do this for you. It'll mean that root and setuid-root binaries have no >> automatic privileges beside owning host (proc/sys) files. > > So this is not helping much. But for me it is at least an idea to how to > have abient capabilities _and_ full control for admin. It would be an > un-capability but at least would allow the admin to change the > behaviour. > > Another one, that would be much better would be something like > cap_ambient_cap capability to explicitly allow the use of ambient > capabilities. > > I have to say that I do not know much about prctl. Just reading the man > page currently. But this seems to be about the second way of taking away > rights from UID 0 instead of explicitly giving rights to selective > binaries. OK, everyone, take a deep breath please. Somewhere very high up on my personal list of generally applicable security advice: do not turn security knobs for the warm fully feelings. Let me repeat that in all caps: DO NOT TURN SECURITY KNOBS FOR THE WARM FUZZY FEELINGS. When a whole bunch of us designed and iterated on how ambient caps would work, we were very careful that they would *not* break pre-existing assumptions that SUID programs could make. Securebits are very different: they very much do break pre-existing assumptions. See, for example, CVE-2014-3215 [1], which is a local privilege escalation made possible a because setuid binary turned security knobs for the warm fuzzy feelings. So, no, barring a really good reason and a very convincing argument about why it would be safe, I won't ack any attempt to add xattr knobs to change privilege evolution rules like that. If you really want to turn knobs to make your system feel safer and be safe at the same time, please learn exactly what all the knobs do first and, while you're at it, please think carefully about how they interact. --Andy [1] See http://openwall.com/lists/oss-security/2014/04/29/7 and much related discussion -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/