Message-ID: <55E8767A.7000408@list.ru>
Date:	Thu, 3 Sep 2015 19:34:02 +0300
From:	Stas Sergeev <stsp@...t.ru>
To:	Austin S Hemmelgarn <ahferroin7@...il.com>,
	Andy Lutomirski <luto@...capital.net>
Cc:	Josh Boyer <jwboyer@...oraproject.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"Andrew Bird (Sphere Systems)" <ajb@...eresystems.co.uk>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Ingo Molnar <mingo@...nel.org>,
	Kees Cook <keescook@...omium.org>,
	Brian Gerst <brgerst@...il.com>
Subject: Re: stop breaking dosemu (Re: x86/kconfig/32: Rename CONFIG_VM86 and
 default it to 'n')

03.09.2015 18:44, Austin S Hemmelgarn пишет:
> On 2015-09-03 08:15, Stas Sergeev wrote:
>> 03.09.2015 15:11, Austin S Hemmelgarn пишет:
>>> On 2015-09-02 17:53, Stas Sergeev wrote:
>>>> 03.09.2015 00:40, Andy Lutomirski пишет:
>>>>> On Wed, Sep 2, 2015 at 2:12 PM, Stas Sergeev <stsp@...t.ru> wrote:
>>>>>> 02.09.2015 23:55, Andy Lutomirski пишет:
>>>>>>
>>>>>>> On Wed, Sep 2, 2015 at 1:47 PM, Stas Sergeev <stsp@...t.ru> wrote:
>>>>>>>> 02.09.2015 23:22, Josh Boyer пишет:
>>>>>>>>> On Wed, Sep 2, 2015 at 1:50 PM, Stas Sergeev <stsp@...t.ru> wrote:
>>>>>>>>>> 02.09.2015 20:46, Josh Boyer пишет:
>>>>>>>>>>> On Wed, Sep 2, 2015 at 10:08 AM, Andy Lutomirski
>>>>>>>>>>> <luto@...capital.net>
>>>>>>>>>>> wrote:
>>>>>>>>>>>> I'd be amenable to switching the default back to y and perhaps
>>>>>>>>>>>> adding
>>>>>>>>>>>> a sysctl to make the distros more comfortable.  Ingo, Kees, Brian,
>>>>>>>>>>>> what do you think?
>>>>>>>>>>> Can you please leave the default as N, and have a sysctl option to
>>>>>>>>>>> enable it instead?  While dosemu might still be in use, it isn't
>>>>>>>>>>> going
>>>>>>>>>>> to be the common case at all.  So from a distro perspective, I
>>>>>>>>>>> think
>>>>>>>>>>> we'd probably rather have the default match the common case.
>>>>>>>>>> The fact that fedora doesn't package dosemu, doesn't automatically
>>>>>>>>>> mean all other distros do not too. Since when kernel defaults should
>>>>>>>>>> match the ones of fedora?
>>>>>>>>> I didn't say that.
>>>>>>>> What you said was:
>>>>>>>> ---
>>>>>>>>
>>>>>>>> While dosemu might still be in use, it isn't going
>>>>>>>> to be the common case at all.  So from a distro perspective
>>>>>>>>
>>>>>>>> ---
>>>>>>>> ... which is likely true only in fedora circe.
>>>>>>>>
>>>>>>>>>       The default right now is N.
>>>>>>>> In a not yet released kernel, unless I am mistaken.
>>>>>>>> If fedora already provides that kernel, other distros likely not.
>>>>>>>>
>>>>>>>>>       I asked it be left
>>>>>>>>> that way.  That's all.
>>>>>>>> Lets assume its not yet N, unless there was a kernel release already.
>>>>>>>> Its easy to get back if its not too late.
>>>>>>> How about CONFIG_SYSCTL_VM86_DEFAULT which defaults to Y?  Fedora
>>>>>>> could set it to N.
>>>>>> Sorry, I don't understand this sysctl proposal.
>>>>>> Could you please educate me what is it all about?
>>>>>> This sysctl will disable or enable the vm86() syscall at run-time,
>>>>>> right? What does it give us? If you disable something in the
>>>>>> config, this gives you, say, smaller kernel image. If OTOH you
>>>>>> add the run-time switch, it gives you a bigger image, regardless
>>>>>> of its default value.
>>>>>> I might be missing something, but I don't understand what
>>>>>> problem will this solve? Have I missed some earlier message
>>>>>> in this thread?
>>>>> For the 99%+ of users who don't use dosemu, it prevents exploits that
>>>>> target vm86 from attacking their kernel.
>>>> 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 PTEs
>>>> 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 without 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 equivalent 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 possible, and in the case of this code, I'd say there is almost certainly some 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.  There 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.
---

> We should not however, wait to disable something by default that (probably) less than 1% of the people who are running Linux on systems that can 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 calculated
the probability of its user base being below 1% of all linux users?
Please provide more details so that I can double-check.


> until someone
> demonstrates a workable exploit. Security is not just a reactionary endeavor, 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 workable 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.
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.

> What has been proposed follows the existing convention on Linux (don't break userspace, and provide the option to people who actually care about their systems being secure to turn it off), the current
> proposal is to make it default to on in the defconfig, and have the sysctl 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 be 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.

> 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'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.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists