From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1033429AbbKEQPQ (ORCPT ); Thu, 5 Nov 2015 11:15:16 -0500 Received: from h2.hallyn.com ([78.46.35.8]:56601 "EHLO h2.hallyn.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1033088AbbKEQPO (ORCPT ); Thu, 5 Nov 2015 11:15:14 -0500 Date: Thu, 5 Nov 2015 10:15:12 -0600 From: "Serge E. Hallyn" To: Klaus Ethgen 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 4.3 breaks security in systems using capabilities Message-ID: <20151105161512.GA2180@mail.hallyn.com> References: <20151102191616.GA2158@ikki.ethgen.ch> <20151105101953.GA15293@ikki.ethgen.ch> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20151105101953.GA15293@ikki.ethgen.ch> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Nov 05, 2015 at 11:19:54AM +0100, Klaus Ethgen wrote: > Hi, > > sorry for the delay. > > Am Mo den 2. Nov 2015 um 20:45 schrieb Andy Lutomirski: > > > Well, the think that changed is that the ambient capabilities can be set > > > by any process if the pI and pE are matching for a process. But then, > > > that capabilities are inherited via execve to even programs that don't > > > have any capability setting. That allows every subprocess to (mis-)use > > > it. > > > > That's true. I don't see why it's a problem, given that the parent > > can already use or mis-use it however it wants, and the child won't > > get the capability without explicit action by the parent. > > Well the parent can but usually is not aware of to what it gives this > ambient capabilities to. If it sets ambient caps, then it is exactly agreeing to not be aware what it's giving ambient caps to. Maybe the capabilities manpage updates need to be more strongly slanted toward "if you *can* use pI|fI then you really should do so". > Exactly here is the point. There are many applications out there that > needs to be SUID root. Many of them only cause the developer has > something inside like "if getuid() != 0". So in future I suspect many of > such tools that even don't need to give capabilities to childs, are > setting all available capabilities in ambient capabilities before > starting do do something. Well, maybe what's really needed is a capabilities project that works with any upstreams wanting to support a capabilities-only mode to help them do things the right way. I'd happily help out with that. > With the present way, that was no problem (for OSS). You take away the > SUID, set the capabilities and if the tool complains about not being > root, look into the code and remove that stupid thing. With ambient > capabilities, no one will see that the tool is doing such stupid thing > as setting all capabilities unless some trouble is seen. > > And I don't see that as hypothetical. I know many developer who are > misusing sudo as it is introduced by ubuntu by doing: > "sudo less /etc/hosts" > "sudo cd /bla" > "sudo ls" > > and so on. Do you really expect such developer being sensitive to use > capabilities carefully? I don't. With the capabilities until now there > was a great tool for the admin to limit damage that can be done with > SUID by replacing it with proper capabilities. Now, with the new ambient 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. I strongly support people working towards that. -serge