Message-ID: <55E99752.3090107@list.ru>
Date:	Fri, 4 Sep 2015 16:06:26 +0300
From:	Stas Sergeev <stsp@...t.ru>
To:	Austin S Hemmelgarn <ahferroin7@...il.com>,
	Chuck Ebbert <cebbert.lkml@...il.com>
Cc:	Andy Lutomirski <luto@...capital.net>,
	Josh Boyer <jwboyer@...oraproject.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')

04.09.2015 15:34, Austin S Hemmelgarn пишет:
> On 2015-09-04 06:46, Stas Sergeev wrote:
>> 04.09.2015 13:09, Chuck Ebbert пишет:
>>> On Fri, 4 Sep 2015 00:28:04 +0300
>>> Stas Sergeev <stsp@...t.ru> wrote:
>>>
>>>> 03.09.2015 21:51, Austin S Hemmelgarn пишет:
>>>>> There are servers out there that have this enabled and _never_ use it
>>>>> at all,
>>>> Unless I am mistaken, servers usually use special flavour of the
>>>> distro (different from desktop install), where of course this will
>>>> be disabled _compile time_.
>>> Many (most?) distros use just one kernel for everything, because it's
>>> just too much work to have a separate flavor for servers.
>> But for example menuconfig promotes CONFIG_PREEMPT_NONE for server
>> and CONFIG_PREEMPT for desktop. Also perhaps server would need an
>> lts version rather than latest.
>> I wonder if RHEL Server offers the generic desktop-suited kernel
>> with vm86() enabled?
>>
>> In any case, if there is some generic mechanism to selectively
>> disable syscalls at run-time for server, then vm86() is of course
>> a good candidate. I wonder how many other syscalls are currently
>> run-time controlled? (those that are not marked as an "attack surface"
>> and defaulted to Y; I suppose the "attack surface" is currently only vm86())
>>
> OK, I think I need to clarify something here.
> 
> The attack surface of a given system refers to the number of different ways that someone could potentially attack that system.  An individual syscall is not in itself an attack surface, but is part of
> the attack surface for the whole system.  One of the core concepts of proactive security is to minimize the attack surface, because the fewer ways someone could possibly attack you, the less likely it
> is that they will succeed.
> 
> I however, referred to vm86 as a potential attack vector, which refers one way in which someone could attempt to attack the system (be it through arbitrary code execution , privilege escalation, or
> some other type of exploit), note that something does not need to have a known exploit to be classified as a potential attack vector (most black hat's out there will keep quiet about discovered
> exploits until they can actually make use of them themselves).  By their very definition, every single site that userspace can call into the kernel is a _potential_ attack vector, including vm86(). 
But they are not marked as such, while vm86() is.
And they do not have a run-time disabling knob.
So why is such a big difference?

> vm86() is one of the more attractive syscalls to attempt to use as an attack vector on 32-bit x86 systems because it's relatively unaudited,
This can be changed if it is at least stripped from the known
bloat, for example. This could have been done _before_ taking any
other actions on it, because the actions would then be entirely
different. Maybe, if it is properly cleaned up, the action will
change from disabling or introducing a knob to auditing it?

> significantly modifies the execution state of the
> processor, and is available on a majority of 32-bit x85 systems in the wild.  This does not mean that it is exploitable directly, just that it's a possible target for an exploit.
So you say it is more dangerous than other syscalls, and I can
believe you, but this needs a proper justification. Someone have
to write why exactly it is more dangerous, can it be fixed or not,
etc. Like it was done for mark_screen_rdonly - I am not asking you
how it can be exploited because I take your word that this code is
a potential risk. But it can be removed. If there are other risky
parts, they also have to be identified. I simply don't think the
sufficient justification was spelled to consider it as more dangerous
than all other syscalls (modulo mmap_min_addr - that one was identified).

What I mean is that when you add some knob for the user to make his
system more (or less) secure, you have to also supply him with the
information on what exactly risk does he accept. Eg if he writes 0
to mmap_min_addr, he knows exactly what risk does he accept, and that
risk is low, he knows. But if he enables vm86() via some magic sysctl,
the only info he has, is a vague "attack surface" in Kconfig. Do you
really think it is enough for the user to make a decision and accept
the risk? I think it is just a threatening attempt which will force
him to never enable that, because he knows exactly zero about the
risk he is going to accept.
So what I ask for, is just:
1. Strip the bloat that is _already_ identified as dangerous
2. See what remains and properly document the danger
3. If that is _still_ needed, add a knob and document exactly what
risk the user have to accept. But likely it won't be needed at that
point at all.
Instead, people go right to 3, shifting all the problems to the user,
without even giving him the needed hint. I don't believe this follows
an existing kernel policy at all.
--
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