From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752247AbbKITDH (ORCPT ); Mon, 9 Nov 2015 14:03:07 -0500 Received: from mail-ig0-f181.google.com ([209.85.213.181]:34029 "EHLO mail-ig0-f181.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751838AbbKITDF (ORCPT ); Mon, 9 Nov 2015 14:03:05 -0500 Subject: Re: [KERNEL] Re: Kernel 4.3 breaks security in systems using capabilities To: "Serge E. Hallyn" , "Theodore Ts'o" , Andy Lutomirski , Linus Torvalds , Richard Weinberger , LKML , Christoph Lameter , Andy Lutomirski , Serge Hallyn , Kees Cook , Andrew Morton References: <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> <5640C999.5050807@gmail.com> <20151109172340.GF3714@ikki.ethgen.ch> From: Austin S Hemmelgarn Message-ID: <5640EDB4.70407@gmail.com> Date: Mon, 9 Nov 2015 14:02:12 -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: <20151109172340.GF3714@ikki.ethgen.ch> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-512; boundary="------------ms060505080003000707040207" X-Antivirus: avast! (VPS 151109-1, 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 This is a cryptographically signed message in MIME format. --------------ms060505080003000707040207 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable On 2015-11-09 12:23, Klaus Ethgen wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > Am Mo den 9. Nov 2015 um 17:28 schrieb Austin S Hemmelgarn: >>> Having some scripts in the process is definitively a nightmare to >>> control. That should be prevented wherever possible. And usually it i= s >>> 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 sc= ripts >> to fit any local configuration. It's not anywhere near as easy to re-= write >> a compiled program to account for any local configuration. > > I would not only say that it is avoidable, it is the worst that can > happen. Scripts will always be necessary unless you have a purpose built system=20 that never gets updated or relocated, and never has any changes to the=20 hardware (and guess what, you use scripts constantly if you use the=20 command-line, option syntax and configuration files are technically=20 domain-specific scripting languages). > > Usually a shell is calling a binary to do the real work. So it should > even never ever needed to have some raised privileges for the shell. Unless you need the binary to be run with some privileges and can't=20 reasonably use capabilities on it (for example, it's a lot of work to=20 maintain a system with no set{u,g}id binaries on it and keep the=20 software up-to-date on it as well). > >>> 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 exist= s >>> in English...) instead of giving proper error messages. >> This is debatable. While the app should be giving a user friendly err= or >> message, getting a stack-trace and the exception name (and the excepti= ons >> are usually sanely named) is still far better than just getting someth= ing >> like 'Segmentation Fault', or just returning the error in the return c= ode. >> There is no added security from not providing the stack-trace because = there >> is no data leaked by it (it contains no information about the contents= of >> variables, and function names and included libraries can easily be see= n by >> just looking at the python program itself). > > My pointing to that python problem is not about security then about how= > lazy some developer are. And lazyness and security is nothing that can > go together. That depends on what you mean by lazy. Scripts can't do core-dumps=20 (there is no practical way to do a core-dump from a script and still be=20 reasonably easy to debug), so they have to do something to provide data=20 so developers can debug it. By having such things just dump a=20 stacktrace, the developers are making it easier for stuff like ABRT and=20 whatever Ubuntu uses for automated bug reporting to actually report=20 things, which in turn makes handling bug reports more efficient (and a=20 desire for efficiency is _not_ the same as being lazy). >>> By the way, guys, can we start to _not_ add every one in this discuss= ion >>> to the Cc? Currently I get every mail twice. One from the list and on= e >> >from Cc. I still leave all Ccs intact with this mail but I would pref= er >>> to just reply to the list. If anybody is not reading the list and wou= ld >>> like to get the mail, please insist. >> If you're getting duplicates with the same Message-ID header, then you= r >> mail-server is (arguably) broken. > > I do not know any mailserver that cares about message-ids. Even more, > which one is the original one if they differ in body? (as they do for > example in this list.) > > It it even more broken as some (surely broken) MUAs reuse message ids. > >> It should be delivering exactly one copy of a message with a given >> Message-ID: header (this is really a de-facto standard, > > I wouldn't say so. The Message-ID header is supposed to be unique for the lifetime of the=20 message (which effectively means almost forever for stuff on LKML, as=20 it's archived). If you are getting multiple copies of a message with=20 the same Message-ID header and different content in the message, then=20 something is very broken, and if a MUA is reusing Message-ID's, then=20 someone needs to file a bug against that MUA. --------------ms060505080003000707040207 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 hvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTUxMTA5MTkwMjEyWjBPBgkq hkiG9w0BCQQxQgRAkfubu+qqqhfD36Ew40EEyAD44pBnrEZAhklR8AJIRWhlJ5R64bH6rx7d WAYBUJO9n8CqwCjKgwfgzts4NF+D7jBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjAL BglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFA MAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGRBgkrBgEEAYI3EAQxgYMwgYAweTEQMA4GA1UE ChMHUm9vdCBDQTEeMBwGA1UECxMVaHR0cDovL3d3dy5jYWNlcnQub3JnMSIwIAYDVQQDExlD QSBDZXJ0IFNpZ25pbmcgQXV0aG9yaXR5MSEwHwYJKoZIhvcNAQkBFhJzdXBwb3J0QGNhY2Vy dC5vcmcCAxEt+DCBkwYLKoZIhvcNAQkQAgsxgYOggYAweTEQMA4GA1UEChMHUm9vdCBDQTEe MBwGA1UECxMVaHR0cDovL3d3dy5jYWNlcnQub3JnMSIwIAYDVQQDExlDQSBDZXJ0IFNpZ25p bmcgQXV0aG9yaXR5MSEwHwYJKoZIhvcNAQkBFhJzdXBwb3J0QGNhY2VydC5vcmcCAxEt+DAN BgkqhkiG9w0BAQEFAASCAgCKvhn3/snJ9PlH55Ek2GwqtXlialkIgITenW+rZPeBDJA3KsSY m1j+w5V/tIWhaunz0ewgpPudux/yUps7zjkQuMWKRdWmPebJ53B4oIPgwErV9R0NNjPmlMBr VzBHb7p6UYBfz0qpb8qM3/fgyk2kJnraxGS1jkMikVrfUJAtd5t5GSG5hwDFPEizur/8kCvS 0LKD8lcX9zu9T+Hmzec+cJuNSEUdfdz590uF2oDEW3PcbBxQ1AeZb8ZbP2WkC1GhV6w12DGd xYGevPtKDH9AlU7ts1pabq3/8G6r8lro7mLp329Qb0bMlnQpS9TH/fQIeWRS/mbhDM6yJ6jI Fia0X330/q0UieA/HGTHwegL/m+Uxr4qN3eS84M56e5uazHat52RYQNB5F9CP3Fz9CzT4ckm +QUyZ4lt0cHnaE7glZSS8It8plM3oUz/sCdvoB1HFEnt2pzPD43nZA7WMkGODloL3sC3sn+y DsDgs3k7Lu1GdbbPZvtAOcO4GKbkr7OUFNLrXvd0jwu5bRQICnWb1zd6NffLm5Kbg2LjoVKS nPiK92uev76g2Q0h46pJe9yLD8At55Lb0Kl91ofL4MjbjpQILiLaFP6p3PrrbYaLdX+B+fPO TSXOVmEO72HSEsnslKflkmfSS5Luo08zoJtcvc+nwK+43WjTthRd78raSAAAAAAAAA== --------------ms060505080003000707040207--