From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752586AbbICSwL (ORCPT ); Thu, 3 Sep 2015 14:52:11 -0400 Received: from mail-io0-f175.google.com ([209.85.223.175]:34275 "EHLO mail-io0-f175.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750818AbbICSwJ (ORCPT ); Thu, 3 Sep 2015 14:52:09 -0400 Subject: Re: stop breaking dosemu (Re: x86/kconfig/32: Rename CONFIG_VM86 and default it to 'n') To: Stas Sergeev , Andy Lutomirski References: <55E6C36F.6080309@list.ru> <55E736E9.2000201@list.ru> <55E7607B.4070800@list.ru> <55E7663B.30402@list.ru> <55E76FCB.7090304@list.ru> <55E838E6.8060205@gmail.com> <55E839C7.8010501@list.ru> <55E86AF7.3090200@gmail.com> <55E8767A.7000408@list.ru> Cc: Josh Boyer , "linux-kernel@vger.kernel.org" , "Andrew Bird (Sphere Systems)" , Linus Torvalds , Ingo Molnar , Kees Cook , Brian Gerst From: Austin S Hemmelgarn Message-ID: <55E896C7.1010500@gmail.com> Date: Thu, 3 Sep 2015 14:51:51 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <55E8767A.7000408@list.ru> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-512; boundary="------------ms020700000400030803080701" X-Antivirus: avast! (VPS 150903-0, 2015-09-03), 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. --------------ms020700000400030803080701 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable On 2015-09-03 12:34, Stas Sergeev wrote: > 03.09.2015 18:44, Austin S Hemmelgarn =D0=BF=D0=B8=D1=88=D0=B5=D1=82: >> On 2015-09-03 08:15, Stas Sergeev wrote: >>> 03.09.2015 15:11, Austin S Hemmelgarn =D0=BF=D0=B8=D1=88=D0=B5=D1=82:= >>>> On 2015-09-02 17:53, Stas Sergeev wrote: [... trimmed for brevity ...] >>>>> I don't think the attack scenario was satisfactory explained. >>>>> IIRC you only said that >>>>> --- >>>>> >>>>> The mark_screen_rdonly thing is still kind of scary. It changes PT= Es >>>>> on arbitrary mappings behind the vm's back. >>>>> >>>>> --- >>>>> Just go ahead and remove mark_screen_rdonly, big deal. >>>>> Is this all of the threat? >>>>> Or do we treat _every_ syscall as the potential attack target? >>>> Anything that messes with the VM subsystem (doubly if it does so wit= hout actually calling into the VM subsystem) is a potential target >>> ... and should be removed. >>> Remove mark_screen_rdonly hack. >>> >>>> as is anything that messes with execution mode or privilege >>>> level (as in, possibly messes with which ring (or whatevere equivale= nt metaphor other processors use) execution is happening in). This does = potentially all three (depending on how it's called). Just >>>> because there are no known working exploits doesn't mean it's not po= ssible, and in the case of this code, I'd say there is almost certainly s= ome way to exploit it either to crash the system or gain >>>> root-equivalent privileges. >>> Please be specific, show the dangerous code, we'll then remove it >>> or fix it. >>> >> The problem is we don't _know_ what could be exploited in there. Ther= e is no way to know for certain without a full audit of the code > As was indicated in this thread already: > https://lkml.org/lkml/2015/9/2/317 > Brian Gerst recently audited it: > --- > That's > hopefully in much better shape now, though. > --- By audit, I don't mean just one person trying to make it more=20 maintainable and fixing any bugs he found, I mean a team of people=20 actively trying to make it break in every way imaginable. I'd be=20 particularly interested to see how it reacts to being hit from multiple=20 cores concurrently with trinity. >> We should not however, wait to disable something by default that (prob= ably) less than 1% of the people who are running Linux on systems that ca= n even use this are actually using > I am puzzled with this "probably". > Given that ubuntu and debian do provide it, and that (unmaintained) > SF page shows a few hundreds of downloads per week, how have you calcul= ated > the probability of its user base being below 1% of all linux users? > Please provide more details so that I can double-check. A few hundred downloads per week, as compared to tens of millions of=20 people using Linux worldwide (rough guess, although probably=20 conservative), with 10% of the Linux users using 32-bit x86 (again,=20 another rough guess, although this one is more generous), still works=20 out to around 1%. It's not possible to get exact numbers for this, and=20 downloads from the SF page also happen for the automated build testing=20 that most modern distributions do these days and a number of reasons=20 other than people using it. >> until someone >> demonstrates a workable exploit. Security is not just a reactionary en= deavor, you need to be proactive about it as well. This means minimizing= the attack surface whenever possible (and yes, this an >> potential attack vector, regardless of whether there are known workabl= e exploits or not). > There are ways to minimize the risk: just remove the bloat, then > see what remains. > If you leave the bloat and just call it "dangerous", people will > start disabling it, because _then_ it will really be an unmaintained > attack target. So what you propose, is the worst solution, not the best= =2E > It will threaten the current vm86() users instead of doing them a > favour by cleaning and fixing the code, and they will start looking > into abandoning it. As of right now, the only open-source project that I know of that is=20 actually actively used by people on new kernels that uses vm86 is dosemu = (and the forked dosemu2). the only other open source user of vm86()=20 that I know of is v86d, which is no longer needed except on ancient=20 hardware with old kernels. And as far as proprietary code goes, they=20 need to pull their heads out of DOS, realize that sane people use=20 protected or long mode for modern software, and get on with their lives. I'm not saying that we shouldn't improve the code, but that we need to=20 provide the option to turn this off at runtime. Just one program that=20 isn't used by a large segment of the community depending on something is = not a good reason to make everyone have it turned on. There are servers out there that have this enabled and _never_ use it at = all, having a system call like this one usable but unused is a potential = security hole, period, irrespective of the quality of the code the=20 syscall executes. As for abandoning it, that is happening already, 32-bit x86 systems are=20 becoming more and more difficult to find, and it's not supported at all=20 on 64-bit kernels. > >> What has been proposed follows the existing convention on Linux (don't= break userspace, and provide the option to people who actually care abou= t their systems being secure to turn it off), the current >> proposal is to make it default to on in the defconfig, and have the sy= sctl default to leaving it enabled. >> >> On top of this, vm86 has a set of very specific niche use cases, most = syscalls like this (AIO, bpf(), seccomp(), {m,f}advise(), etc) can only b= e turned on and off by completely rebuilding the kernel. > "on and off"? Nice, but they are On by default (except for bpf()). > So the fact that they have no runtime knob doesn't look like a big > surprise. Most of those (other than seccomp) are used almost exclusively in server = applications, and in the case of AIO, it is possible to prevent anything = from using it at runtime, but this can't be sanely relayed to any=20 applications that use it (bonus points if you can figure out how to stop = everyone from using it and why applications can't easily detect this). >> This lets you turn this on or off at runtime. > With a big warning that "it is an attack surface and less than > 1% of people use it, please don't touch"? No thankyou. I'm not saying that such a warning should be put in, and based on the=20 backlash that the original change that sparked this thread got, nothing=20 like that is going to be put in, but there is no reason to not be able=20 to enable/disable it at runtime. Most people who are using desktop=20 systems are not going to inherently know if they need it or not until=20 they do need it, and unlike many of the other syscalls that can be=20 disabled, many people who are likely to be using it aren't the type who=20 are comfortable compiling their own kernel. > I'll be looking into testing and sending the patch that removes > mark_screen_rdonly. Maybe then this thread will shift a bit from > guesses and assumptions. My statement that there is a potential security risk inherent in vm86 is = not a guess or assumption, it's a fact. Every single way that user code = can call into the kernel is a potential attack vector, period,=20 irrespective of what it does. You can't say with 100% certainty that=20 something is not a possible attack vector unless it isn't there to begin = with. While disabling it at runtime is not the best option from a=20 security standpoint, it makes it a much more difficult to even try to=20 exploit the code. --------------ms020700000400030803080701 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 Brgwgga0MIIEnKADAgECAgMQblUwDQYJKoZIhvcNAQENBQAweTEQMA4GA1UEChMHUm9vdCBD QTEeMBwGA1UECxMVaHR0cDovL3d3dy5jYWNlcnQub3JnMSIwIAYDVQQDExlDQSBDZXJ0IFNp Z25pbmcgQXV0aG9yaXR5MSEwHwYJKoZIhvcNAQkBFhJzdXBwb3J0QGNhY2VydC5vcmcwHhcN MTUwMzI1MTkzNDM4WhcNMTUwOTIxMTkzNDM4WjBjMRgwFgYDVQQDEw9DQWNlcnQgV29UIFVz 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 b20wDQYJKoZIhvcNAQENBQADggIBABr5e8W+NiTER+Q/7wiA2LxWN3UdhT3eZJjqqSlP370P KL5iWqeTfxQ67Ai/mHbJcT2PgAJ+/D2Ji+aRR03UWnU/vtOwzyDLUMstqnfl0Zs+sz/CJe7x nBA5jlpjC2DKuMVfbPze7eySaen7XSGFHKE1QoVIIpQ2kVjC4nbbJQnUbAVX1Iz29WxeVGt9 XYigz3tDPf3tglN+q23E7YjQl4abTIoM7i98yV1H9gfY8lFfKZ6jREB9+n6ie2EwS3Kat2mG tl2wBx4MfRnoSQSKsLKQ5oTwhWf0JqlFwpLfl374p0Njcykej9/jnWG8Ks1V/AXTHqI4eyIP Mf5yMZkPv7n7LS9WWKdG4Nd38iv4T2EiAaWsmgu+r81qL5CJu9AyA0SBS4ttKf6k3e63w2Mv N9R45vpQ3QhAhfWyFxFhZN95APe3YECDG3+XIRJpRYPEtHuIsOyzI70ajF93gg/BidvqKsmV MM2ccktDMfqwZXea6zey7F8Geu9R7BqjXmG2HlNuXu7e/xnHOgXf5D3wPmnRLlBhXL1Ch97a w2KjaupjpAHfFjv5kGnZXN87UvvlwzIZiKXwa3vTDwK+rrKn/sHPkfDZPSiyt/ZBIK6lX83P 34H/CzGg+Kx57rHYOIHGumIvpDa5vfWp8O0sGgawb1C2Aae4sTUVIWmIjVuGI062MYIE0TCC BM0CAQEwgYAweTEQMA4GA1UEChMHUm9vdCBDQTEeMBwGA1UECxMVaHR0cDovL3d3dy5jYWNl cnQub3JnMSIwIAYDVQQDExlDQSBDZXJ0IFNpZ25pbmcgQXV0aG9yaXR5MSEwHwYJKoZIhvcN AQkBFhJzdXBwb3J0QGNhY2VydC5vcmcCAxBuVTANBglghkgBZQMEAgMFAKCCAiEwGAYJKoZI hvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTUwOTAzMTg1MTUxWjBPBgkq hkiG9w0BCQQxQgRA1q2Ok3oN9pHOP6fUoUGks7+/TIuPHUe0uyu8cc8dGj0aJRcd00wuD16A YxbQ4a3Lylb3bUOpL3nwUK2SUh67HTBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjAL BglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFA MAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGRBgkrBgEEAYI3EAQxgYMwgYAweTEQMA4GA1UE ChMHUm9vdCBDQTEeMBwGA1UECxMVaHR0cDovL3d3dy5jYWNlcnQub3JnMSIwIAYDVQQDExlD QSBDZXJ0IFNpZ25pbmcgQXV0aG9yaXR5MSEwHwYJKoZIhvcNAQkBFhJzdXBwb3J0QGNhY2Vy dC5vcmcCAxBuVTCBkwYLKoZIhvcNAQkQAgsxgYOggYAweTEQMA4GA1UEChMHUm9vdCBDQTEe MBwGA1UECxMVaHR0cDovL3d3dy5jYWNlcnQub3JnMSIwIAYDVQQDExlDQSBDZXJ0IFNpZ25p bmcgQXV0aG9yaXR5MSEwHwYJKoZIhvcNAQkBFhJzdXBwb3J0QGNhY2VydC5vcmcCAxBuVTAN BgkqhkiG9w0BAQEFAASCAgCZC6T0cTv98cHOyK5ku/i0qWEk8fDGdHR6FlK6ViLEuJQB341B yOMzm7Ivhke4gBHBllsXYEpeKqj2RXyegi3dzFi3qWBWumcUGxPcVjh+9c2/wMRtG7TEp0Bu IldGTPA/MQx/qr0RmEY9zilBVYC0N+SIXrY2FtdPwtyzjajVOSGE+c8lheGgrLLE8Kde+CBB gWb3T2824Yg5xYJLCP9poQgBSZtGW4NxiidynzMPyvWGLl+sc7B7EXtUQzlLn5ruVQmEgFWJ WxOLmNlvHbFaYmhXDsIQzK8dOAfLTkZRNLq3IIJ24Rzr9hmxwSnFfJ3PtAPB0t8RmqztexER 3Qt7SY34z7U1NUA+52+j2LZ7TS0XvLGJMei5N1YDJLf3BPyLRBLfdKSMnvY+FYzxJoClDSXE IwfnqL7j617ukq1XcTQmR20LBnL1kGrGZoEE6HGmYLetWyEFvlJx5rbSeq1n3Zrv+hyfIYQB LPoT8SM3N2fFLUa5G9ZouzzeYcRKFWr9DKQkpUPM8IdJquHK5ih92YZTDr07MtQt+UJVUrKo JMEAv1NXq8ylTqHE4zDQTqPBe2MaxXpGegiVH76kFAre6kowNrzNWsTu8tRlgxG4Ox03yihq eIH9TK/hl4S2qWxQvNy705RIBs5NCuIRnlz4141sBZAZzvxMfTNyoOVRaAAAAAAAAA== --------------ms020700000400030803080701--