Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752297AbbKIQaV (ORCPT ); Mon, 9 Nov 2015 11:30:21 -0500 Received: from mail-ig0-f172.google.com ([209.85.213.172]:36255 "EHLO mail-ig0-f172.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752832AbbKIQ2X (ORCPT ); Mon, 9 Nov 2015 11:28:23 -0500 Subject: Re: Kernel 4.3 breaks security in systems using capabilities To: Klaus Ethgen , "Serge E. Hallyn" References: <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> <20151106135835.GB11901@ikki.ethgen.ch> <20151106155303.GB6160@thunk.org> <20151106175619.GA19491@ikki.ethgen.ch> <20151106181820.GB16749@mail.hallyn.com> <20151107110246.GA7230@ikki.ethgen.ch> Cc: "Theodore Ts'o" , Andy Lutomirski , Linus Torvalds , Richard Weinberger , LKML , Christoph Lameter , Andy Lutomirski , Serge Hallyn , Kees Cook , Andrew Morton From: Austin S Hemmelgarn Message-ID: <5640C999.5050807@gmail.com> Date: Mon, 9 Nov 2015 11:28:09 -0500 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <20151107110246.GA7230@ikki.ethgen.ch> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-512; boundary="------------ms010506030002040108040202" X-Antivirus: avast! (VPS 151109-0, 2015-11-09), Outbound message X-Antivirus-Status: Clean Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 8427 Lines: 155 This is a cryptographically signed message in MIME format. --------------ms010506030002040108040202 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable On 2015-11-07 06:02, Klaus Ethgen wrote: > Am Fr den 6. Nov 2015 um 19:18 schrieb Serge E. Hallyn: >> A piece of system configuration software needs to do some >> networking setup with some privilege, including calling scripts. It c= an >> either do so as root or not at all - polluting every program that will= end >> up getting called with fI is not only ugly but simply doesn't work (be= cause >> scripts). Saying that the whole thing must be written as self-contain= ed >> executable that never needs to be re-execed is frequently unrealistic.= >> So this allows a piece of software to run with reduce privilege, and i= t >> is an improvement over the previous state of affairs. > > Having some scripts in the process is definitively a nightmare to > control. That should be prevented wherever possible. And usually it is > as the scripts might be used for computing some values that are used > later in privileged stuff. It's still unavoidable in a number of cases. It's easy to re-write=20 scripts to fit any local configuration. It's not anywhere near as easy=20 to re-write a compiled program to account for any local configuration. > > However, that usecase has one more flaw I think. It is the human nature= =2E > > Someone that create a tool made for running as root or especially SUID > is usually careful to do so. If they know right now that the tool is > never run as root, then they don't care about many thinks that needs to= > get addressed for root stuff. > > Good example are all that userspace python tools that throw all that > stack traces around the users ears (I don't know if that saying exists > in English...) instead of giving proper error messages. This is debatable. While the app should be giving a user friendly error = message, getting a stack-trace and the exception name (and the=20 exceptions are usually sanely named) is still far better than just=20 getting something like 'Segmentation Fault', or just returning the error = in the return code. There is no added security from not providing the=20 stack-trace because there is no data leaked by it (it contains no=20 information about the contents of variables, and function names and=20 included libraries can easily be seen by just looking at the python=20 program itself). > >> I would have been happy if there had been a default-off PR_ENABLE_AMBI= ENT >> prctl which required a new CAP_ENABLE_AMBIENT capability to turn on, b= ut >> the current set of rules which removes bits from pA whenever doing an >> action which capability-aware software does something which it would h= ave >> reasonably expected to drop privilege is a nice safeguard. > > Well, not really. You can only prevent ambient capabilities to be given= > to tools you don't want to have any capabilities by setting that tool > SUID or setting just one random capability for it. > > By the way, guys, can we start to _not_ add every one in this discussio= n > to the Cc? Currently I get every mail twice. One from the list and one > from Cc. I still leave all Ccs intact with this mail but I would prefer= > to just reply to the list. If anybody is not reading the list and would= > like to get the mail, please insist. If you're getting duplicates with the same Message-ID header, then your=20 mail-server is (arguably) broken. It should be delivering exactly one=20 copy of a message with a given Message-ID: header (this is really a=20 de-facto standard, GMail, Yahoo, and most other mail-providers do this,=20 as does Exchange. Postfix does not, but it's pretty easy to work around = with some filtering and procmail). --------------ms010506030002040108040202 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgMFADCABgkqhkiG9w0BBwEAAKCC Brgwgga0MIIEnKADAgECAgMRLfgwDQYJKoZIhvcNAQENBQAweTEQMA4GA1UEChMHUm9vdCBD QTEeMBwGA1UECxMVaHR0cDovL3d3dy5jYWNlcnQub3JnMSIwIAYDVQQDExlDQSBDZXJ0IFNp Z25pbmcgQXV0aG9yaXR5MSEwHwYJKoZIhvcNAQkBFhJzdXBwb3J0QGNhY2VydC5vcmcwHhcN MTUwOTIxMTEzNTEzWhcNMTYwMzE5MTEzNTEzWjBjMRgwFgYDVQQDEw9DQWNlcnQgV29UIFVz ZXIxIzAhBgkqhkiG9w0BCQEWFGFoZmVycm9pbjdAZ21haWwuY29tMSIwIAYJKoZIhvcNAQkB FhNhaGVtbWVsZ0BvaGlvZ3QuY29tMIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEA nQ/81tq0QBQi5w316VsVNfjg6kVVIMx760TuwA1MUaNQgQ3NyUl+UyFtjhpkNwwChjgAqfGd LIMTHAdObcwGfzO5uI2o1a8MHVQna8FRsU3QGouysIOGQlX8jFYXMKPEdnlt0GoQcd+BtESr pivbGWUEkPs1CwM6WOrs+09bAJP3qzKIr0VxervFrzrC5Dg9Rf18r9WXHElBuWHg4GYHNJ2V Ab8iKc10h44FnqxZK8RDN8ts/xX93i9bIBmHnFfyNRfiOUtNVeynJbf6kVtdHP+CRBkXCNRZ qyQT7gbTGD24P92PS2UTmDfplSBcWcTn65o3xWfesbf02jF6PL3BCrVnDRI4RgYxG3zFBJuG qvMoEODLhHKSXPAyQhwZINigZNdw5G1NqjXqUw+lIqdQvoPijK9J3eijiakh9u2bjWOMaleI SMRR6XsdM2O5qun1dqOrCgRkM0XSNtBQ2JjY7CycIx+qifJWsRaYWZz0aQU4ZrtAI7gVhO9h pyNaAGjvm7PdjEBiXq57e4QcgpwzvNlv8pG1c/hnt0msfDWNJtl3b6elhQ2Pz4w/QnWifZ8E BrFEmjeeJa2dqjE3giPVWrsH+lOvQQONsYJOuVb8b0zao4vrWeGmW2q2e3pdv0Axzm/60cJQ haZUv8+JdX9ZzqxOm5w5eUQSclt84u+D+hsCAwEAAaOCAVkwggFVMAwGA1UdEwEB/wQCMAAw VgYJYIZIAYb4QgENBEkWR1RvIGdldCB5b3VyIG93biBjZXJ0aWZpY2F0ZSBmb3IgRlJFRSBo ZWFkIG92ZXIgdG8gaHR0cDovL3d3dy5DQWNlcnQub3JnMA4GA1UdDwEB/wQEAwIDqDBABgNV HSUEOTA3BggrBgEFBQcDBAYIKwYBBQUHAwIGCisGAQQBgjcKAwQGCisGAQQBgjcKAwMGCWCG SAGG+EIEATAyBggrBgEFBQcBAQQmMCQwIgYIKwYBBQUHMAGGFmh0dHA6Ly9vY3NwLmNhY2Vy dC5vcmcwMQYDVR0fBCowKDAmoCSgIoYgaHR0cDovL2NybC5jYWNlcnQub3JnL3Jldm9rZS5j cmwwNAYDVR0RBC0wK4EUYWhmZXJyb2luN0BnbWFpbC5jb22BE2FoZW1tZWxnQG9oaW9ndC5j b20wDQYJKoZIhvcNAQENBQADggIBADMnxtSLiIunh/TQcjnRdf63yf2D8jMtYUm4yDoCF++J jCXbPQBGrpCEHztlNSGIkF3PH7ohKZvlqF4XePWxpY9dkr/pNyCF1PRkwxUURqvuHXbu8Lwn 8D3U2HeOEU3KmrfEo65DcbanJCMTTW7+mU9lZICPP7ZA9/zB+L0Gm1UNFZ6AU50N/86vjQfY WgkCd6dZD4rQ5y8L+d/lRbJW7ZGEQw1bSFVTRpkxxDTOwXH4/GpQfnfqTAtQuJ1CsKT12e+H NSD/RUWGTr289dA3P4nunBlz7qfvKamxPymHeBEUcuICKkL9/OZrnuYnGROFwcdvfjGE5iLB kjp/ttrY4aaVW5EsLASNgiRmA6mbgEAMlw3RwVx0sVelbiIAJg9Twzk4Ct6U9uBKiJ8S0sS2 8RCSyTmCRhJs0vvva5W9QUFGmp5kyFQEoSfBRJlbZfGX2ehI2Hi3U2/PMUm2ONuQG1E+a0AP u7I0NJc/Xil7rqR0gdbfkbWp0a+8dAvaM6J00aIcNo+HkcQkUgtfrw+C2Oyl3q8IjivGXZqT 5UdGUb2KujLjqjG91Dun3/RJ/qgQlotH7WkVBs7YJVTCxfkdN36rToPcnMYOI30FWa0Q06gn F6gUv9/mo6riv3A5bem/BdbgaJoPnWQD9D8wSyci9G4LKC+HQAMdLmGoeZfpJzKHMYIE0TCC BM0CAQEwgYAweTEQMA4GA1UEChMHUm9vdCBDQTEeMBwGA1UECxMVaHR0cDovL3d3dy5jYWNl cnQub3JnMSIwIAYDVQQDExlDQSBDZXJ0IFNpZ25pbmcgQXV0aG9yaXR5MSEwHwYJKoZIhvcN AQkBFhJzdXBwb3J0QGNhY2VydC5vcmcCAxEt+DANBglghkgBZQMEAgMFAKCCAiEwGAYJKoZI hvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTUxMTA5MTYyODA5WjBPBgkq hkiG9w0BCQQxQgRA1fmnJCliyJSfiiuSKAiesU20r1V1mV18FADIofTb2QJ6HjJQI96z6vqx zFt7yld4N6PytXIUr12EjVmje6e0+TBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjAL BglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFA MAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGRBgkrBgEEAYI3EAQxgYMwgYAweTEQMA4GA1UE ChMHUm9vdCBDQTEeMBwGA1UECxMVaHR0cDovL3d3dy5jYWNlcnQub3JnMSIwIAYDVQQDExlD QSBDZXJ0IFNpZ25pbmcgQXV0aG9yaXR5MSEwHwYJKoZIhvcNAQkBFhJzdXBwb3J0QGNhY2Vy dC5vcmcCAxEt+DCBkwYLKoZIhvcNAQkQAgsxgYOggYAweTEQMA4GA1UEChMHUm9vdCBDQTEe MBwGA1UECxMVaHR0cDovL3d3dy5jYWNlcnQub3JnMSIwIAYDVQQDExlDQSBDZXJ0IFNpZ25p bmcgQXV0aG9yaXR5MSEwHwYJKoZIhvcNAQkBFhJzdXBwb3J0QGNhY2VydC5vcmcCAxEt+DAN BgkqhkiG9w0BAQEFAASCAgASkX8C6atYv6x+ttE7J/1wzEeljHq1eW7x/5OQizOINoZo4T7t 5qr6LIzi/1Dy2OJSssWF85aJB2zXPV5F1eGgw7vewOrQJk7zcxWw2ZUzMviAsuBWPu+hXwZb cdx8UtdIk63ijdIS6VL2QVmnMYR7P8oScav4uKWAyuV7GRrM/6G2IHHEt5JIWfGQkfvo7XNW oVbINsqWGW11BdBM6ZA+hOXH/ESxHM1o+i9KQMMYDnTnezYC1QEx18xaKuvOOHst0G+AoAQs pr3gjsnLukV8ulELKRQe1LY1Y5mqNVrxo2p4O6cIyO+Yi4Hl53R0+Svf+90L6beRxZrf/mJq 1t/xwhJDuOorL8YBHt6otZR1lShqyUoIE5+r+8ywJ8KiBth89AGQI+3I9LjtbQr6JMwZ3cu2 mQe680KW9aDMMRFjzU5QCpiWs+ukchTcftTXZW45xljzg5nCNCas48VtNyHWEC9eEdTf8Sq6 L5xKltufk7oDCMuQ1vSoEvkMUVkefkbppNAp+753NblpjeDvEUBJi/f+bJUIV/UKXoHimuhW S7uuPfnFAEVxnSmhwtvDVYqL9my+E+0QP7ntlC+1tp9ME36SynGO+szORQDcThDEUKhdoJHt BG5RJ9M/xLSo4pQ0hN/6Y37uhdpvpeNWXEoAKhFo4aVK7E5ElUG4fsqG4wAAAAAAAA== --------------ms010506030002040108040202-- -- 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/