linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Austin S Hemmelgarn <ahferroin7@gmail.com>
To: Stas Sergeev <stsp@list.ru>, Chuck Ebbert <cebbert.lkml@gmail.com>
Cc: Andy Lutomirski <luto@amacapital.net>,
	Josh Boyer <jwboyer@fedoraproject.org>,
	linux-kernel@vger.kernel.org,
	"Andrew Bird (Sphere Systems)" <ajb@spheresystems.co.uk>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Ingo Molnar <mingo@kernel.org>, Kees Cook <keescook@chromium.org>,
	Brian Gerst <brgerst@gmail.com>
Subject: Re: stop breaking dosemu (Re: x86/kconfig/32: Rename CONFIG_VM86 and default it to 'n')
Date: Fri, 4 Sep 2015 08:34:31 -0400	[thread overview]
Message-ID: <55E98FD7.8020809@gmail.com> (raw)
In-Reply-To: <55E9767B.2020501@list.ru>

[-- Attachment #1: Type: text/plain, Size: 2737 bytes --]

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@list.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().  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, 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.


[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 3019 bytes --]

  reply	other threads:[~2015-09-04 12:34 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-09-02  9:37 stop breaking dosemu (Re: x86/kconfig/32: Rename CONFIG_VM86 and default it to 'n') Stas Sergeev
2015-09-02 14:08 ` Andy Lutomirski
2015-09-02 15:31   ` Kees Cook
2015-09-02 17:30   ` Stas Sergeev
2015-09-02 17:46   ` Josh Boyer
2015-09-02 17:50     ` Stas Sergeev
2015-09-02 20:22       ` Josh Boyer
2015-09-02 20:47         ` Stas Sergeev
2015-09-02 20:55           ` Andy Lutomirski
2015-09-02 20:59             ` Josh Boyer
2015-09-02 21:12             ` Stas Sergeev
2015-09-02 21:40               ` Andy Lutomirski
2015-09-02 21:53                 ` Stas Sergeev
2015-09-03 12:11                   ` Austin S Hemmelgarn
2015-09-03 12:15                     ` Stas Sergeev
2015-09-03 15:44                       ` Austin S Hemmelgarn
2015-09-03 16:34                         ` Stas Sergeev
2015-09-03 18:51                           ` Austin S Hemmelgarn
2015-09-03 21:28                             ` Stas Sergeev
2015-09-04 10:09                               ` Chuck Ebbert
2015-09-04 10:46                                 ` Stas Sergeev
2015-09-04 12:34                                   ` Austin S Hemmelgarn [this message]
2015-09-04 13:06                                     ` Stas Sergeev
2015-09-04 19:51                                       ` Austin S Hemmelgarn
2015-09-04 21:16                                         ` Stas Sergeev
2015-09-04 21:30                                           ` Stas Sergeev
2015-09-04 22:46                                             ` Raymond Jennings
2015-09-04 23:18                                               ` Stas Sergeev
2015-09-03 22:39                             ` Stas Sergeev
2015-09-03 16:57                         ` Linus Torvalds
2015-09-03 17:19                           ` Stas Sergeev
2015-09-03 17:21                             ` Andy Lutomirski
2015-09-03 17:34                               ` Stas Sergeev
2015-09-03 17:13                         ` Stas Sergeev
2015-09-03 12:01               ` Austin S Hemmelgarn
2015-09-03 12:09                 ` Stas Sergeev
2015-09-02 17:52     ` Kees Cook
2015-09-02 20:25       ` Josh Boyer
2015-09-02 18:19     ` Andy Lutomirski
2015-09-02 20:26       ` Josh Boyer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=55E98FD7.8020809@gmail.com \
    --to=ahferroin7@gmail.com \
    --cc=ajb@spheresystems.co.uk \
    --cc=brgerst@gmail.com \
    --cc=cebbert.lkml@gmail.com \
    --cc=jwboyer@fedoraproject.org \
    --cc=keescook@chromium.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luto@amacapital.net \
    --cc=mingo@kernel.org \
    --cc=stsp@list.ru \
    --cc=torvalds@linux-foundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).