Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1161654AbbKFN6o (ORCPT ); Fri, 6 Nov 2015 08:58:44 -0500 Received: from tschil.ethgen.ch ([5.9.7.51]:53567 "EHLO tschil.ethgen.ch" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1161301AbbKFN6n (ORCPT ); Fri, 6 Nov 2015 08:58:43 -0500 Date: Fri, 6 Nov 2015 14:58:36 +0100 From: Klaus Ethgen To: "Serge E. Hallyn" Cc: Andy Lutomirski , Linus Torvalds , Richard Weinberger , LKML , Christoph Lameter , Andy Lutomirski , Serge Hallyn , Kees Cook , Andrew Morton Subject: Re: [KERNEL] Re: [KERNEL] Re: [KERNEL] Re: [KERNEL] Re: [KERNEL] Re: Kernel 4.3 breaks security in systems using capabilities Message-ID: <20151106135835.GB11901@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> <20151105220843.GA6027@mail.hallyn.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; x-action=pgp-signed In-Reply-To: <20151105220843.GA6027@mail.hallyn.com> OpenPGP: id=79D0B06F4E20AF1C; url=http://www.ethgen.ch/~klaus/79D0B06F4E20AF1C.txt; preference=signencrypt User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 5440 Lines: 122 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi, Am Do den 5. Nov 2015 um 23:08 schrieb Serge E. Hallyn: > On Thu, Nov 05, 2015 at 11:01:07AM -0800, Andy Lutomirski wrote: > > 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. > > Not exactly. It's restoring the full unadulterated use of posix > capabilities. - -v > > 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. I never talked about capabilities _and_ SUID, I always talked about capabilities _instead_ of SUID. I want to get rid of the SUIDs. > > Securebits > > are very different: they very much do break pre-existing assumptions. > > ... thought i was clear about that. What I read about, that ist clear for me too. > > 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. Hmm.. That is exactly what I fear about ambient capabilities too. Maybe I am a bit more paranoid than the author of ambient capabilities but I droved good with that paranoia level in the past. > > 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. Well, I think I have a good understanding about capabilities. I just think that we talk at cross purposes. I never ever talked about using capabilities in _combination_ with SUID. That was brought to the line by others and, how I read the patch that brought ambient capabilities in, the main reason for it. But that left out completely the, I think more important, usecase of _removing_ SUID completely and _replacing_ it with very tight capability setting. And that is what I always talked about. I did not know about that "security bits", shame on me. But I do not think that they are any kind of solution for the problem that ambient capabilities brought into the kernel. Nor do I think that they change any about the second usecase I always talked about. Regards Klaus - -- Klaus Ethgen http://www.ethgen.ch/ pub 4096R/4E20AF1C 2011-05-16 Klaus Ethgen Fingerprint: 85D4 CA42 952C 949B 1753 62B3 79D0 B06F 4E20 AF1C -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQGcBAEBCgAGBQJWPLIGAAoJEKZ8CrGAGfaspF8MAKst2DUJ6id4VcPFZGbC6Koe DROSPWJpZ2+5kW5q4hHX5+E+pQls3ipDwi0K+HyhqjTOXZbRC4Irv8RynbZBgvmN C7wL2H9o+zjnK29XTlZf7Gr2nCYw/ct10CMtXm56OhIaZcEhb9yNDXa5X+wiPy+B qVP8xGdFVORa7ziQnyv7j8TRMGejT3qkX+vxLB9bfX5KvuuBgg0X7JIVMqFET6By HaKWAoVEWoRNbifbOiG0FRq7z8usXB0/5Yhz9u89n4MiGf14bQb4ivrJStIyMb4q BxHZxQsEtf+wSpd4itoICdKl2vUO5J46mNc3vNvi0tCv1EKIff8HvQRjAYQYpYB9 Vn862aXUQlFrM5z7QjywhYH4que5Xs8PRP+zBsh2eVCZgecwkt7aUh+zK1FzBaWG Rr+vYwZdObMYQjA3/1v4sQhJmINO0A5yGgLjRCSO1uirU+gjNScXRmGCyvidzaSR eOlfcv34EfAxzDUrT/X7TSTph308W8s6y3Em9prbKA== =8opp -----END PGP SIGNATURE----- -- 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/