Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755037AbbKJR7K (ORCPT ); Tue, 10 Nov 2015 12:59:10 -0500 Received: from tschil.ethgen.ch ([5.9.7.51]:38116 "EHLO tschil.ethgen.ch" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754971AbbKJR66 (ORCPT ); Tue, 10 Nov 2015 12:58:58 -0500 Date: Tue, 10 Nov 2015 18:58:49 +0100 From: Klaus Ethgen To: Austin S Hemmelgarn Cc: "Theodore Ts'o" , Andy Lutomirski , Serge Hallyn , Kees Cook , Christoph Lameter , "Serge E. Hallyn" , Andrew Morton , Richard Weinberger , LKML , Linus Torvalds Subject: Re: [KERNEL] Re: [KERNEL] [PATCH] Kernel 4.3 breaks security in systems using capabilities Message-ID: <20151110175849.GB26726@ikki.ethgen.ch> Mail-Followup-To: Austin S Hemmelgarn , Theodore Ts'o , Andy Lutomirski , Serge Hallyn , Kees Cook , Christoph Lameter , "Serge E. Hallyn" , Andrew Morton , Richard Weinberger , LKML , Linus Torvalds References: <20151107110246.GA7230@ikki.ethgen.ch> <5640C999.5050807@gmail.com> <20151109172340.GF3714@ikki.ethgen.ch> <5640EDB4.70407@gmail.com> <20151109212937.GA17624@ikki.ethgen.ch> <20151110115526.GA2958@ikki.ethgen.ch> <20151110124043.GC3717@thunk.org> <20151110131907.GB2958@ikki.ethgen.ch> <5641F2B7.9050408@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; x-action=pgp-signed In-Reply-To: <5641F2B7.9050408@gmail.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: 3815 Lines: 82 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Am Di den 10. Nov 2015 um 14:35 schrieb Austin S Hemmelgarn: > On 2015-11-10 08:19, Klaus Ethgen wrote: > >Hi Ted, hy others in this discussion, > > > >Am Di den 10. Nov 2015 um 13:40 schrieb Theodore Ts'o: > >>Whether or not that will be acceptable upstream, I don't know, mainly > >>because I think a strong case can be made that such a patch has an > >>audience of one, and adding more complexity here for an idea which has > >>been time-tested over decades to be a failure is just not a good idea. > > > >I wouldn't tell the implementation until now to be a failure. It helped > >a lot to keep a system sane. It is true that all distributions ignored > >capabilities completely but I don't think that is due the design. > I think it's mostly due to the fact that there are a lot of potential > security issues in using capabilities as implemented in Linux (and other > POSIX systems), Well, of course. If you give a process capabilities, it can use it. That is in the nature of the problem. But in comparison to SUID, it is selective rights. That makes it much more troublesome to exploit. Why the hell is, for example, ping installed SUID root? There is only one privileged right that is needed instead of all or nothing. > and unlike chroot(), it's not as easy to protect against stuff trying > to bypass them while still keeping them useful. It is the same, you have to be aware of the problem and need to mitigate it. chroot addresses different thinks than capabilities. And also chroot is exploitable and you can break out in some cases. You have to do it right... > If you do a web search you can relatively easily find info on how to > use many of the defined capabilities to get root-equivalent access > (CAP_SYS_ADMIN and CAP_SYS_MODULE are obvious, but many of the others > can be used also if you know what you are doing, for example > CAP_DAC_OVERRIDE+CAP_SYS_BOOT can be used on non-SecureBoot systems to > force the system to reboot into an arbitrary kernel). Well, that is like it should be. If you give an exploitable application rights that it should not have, it can get exploited. But this decision is in the responsibility of the admin. With ambient capabilities, you transfer that responsibilities to all the different developers that once in a while wrote a SUID tool (or tool with raised capabilities). So, tell me, where does the ambient capabilities raise the security? For the records: It does in limited cases when you start with all capabilities and take away most except the one some sub tools needs. But, sorry, I just sees that as a limited use. Nevertheless, for such cases, ambient capabilities might be useful. 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 iQGcBAEBCgAGBQJWQjBNAAoJEKZ8CrGAGfasvvUL/R/T1jG/gUV1N+8wYric3MvJ T8do3YJUwaHId/1kOgL/FrS86LOchWSV7g8osWf6MZV0LToVrjUYKzUdsTlQ3Rdf rYAegJG5hruWv2uWTe7v/ndzN1drg3q81hmCAx2c12bwJON1F03O7iCQEuJVWeP/ h9xYu1lIH37Pj36BEb/K5vCheTrdoQDGeAi/HcpmPmb0AfrSyYeNgrr6jcpvJnvm aelyBt70MSymrwN2K4X8bPKSoheSZiW9Ol3dc6lLMWXbksX8tz5v2+8SeH38xETn f0Ew1re12bxKRvK2XWzMQwHmEHTOhydWcIQjx+2Xu7M/l1YdevPRoENkCb/QmbZv D3/fUNgtGU3fUPPzokSS6pqZyKHVNmPs767nPOAP0T/sPdwyMAP81LI/yspWJc7C Tg1XqUSe9DUP3Dcejf+g7LqvimvErHAbJQ5OyubcFddOj4OeZhhbQZNnt60a1Fva 13zzZq7RQMIt9ZL/Hlqyx7pNXzw99fP0Mkfj93WyaQ== =eUYZ -----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/