Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date: Tue, 14 Jun 2011 12:35:59 +0400
From: Vasiliy Kulikov <>
Subject: HARDEN_VM86

Solar, all -

While actual implementation of CONFIG_HARDEN_VM86 is trivial, the most
important part of pushing the feature into upstream is clarifying to
what security domain vm86(2)/vm86old(2) should be restricted.  In -ow
and -grsecurity it is restricted to CAP_SYS_RAWIO.

I see 3 possibilities:

1) Restrict it to CAP_SYS_RAWIO and make it configurable via sysctl
kernel.vm86_restricted.  0 means current behaviour, 1 means

2) The same as (1), but CAP_SYS_ADMIN.

3) Restrict it to some group or CAP_SYS_ADMIN, configurable via
kernel.vm86_group_allowed.  As vm86 is a rarely used thing, group range
makes little sense for me.  0 means root only, -1 means current
behaviour, X>0 means group X.

For people not familiar with CONFIG_HARDEN_VM86:

  On x86 processors, the Virtual 8086 (VM86) mode allows the execution
  of real mode operating systems and applications (primarily DOS) under
  protected mode operating systems such as Linux (with dosemu).  This
  requires support from the kernel.  Although the amount of kernel code
  needed to support the VM86 mode is small and no security problems
  with it are currently known, that code is unused on most Linux systems
  and as such it poses an unreasonable risk.  This option restricts
  access to system calls used to enter the VM86 mode to processes that
  possess the CAP_SYS_RAWIO capability.  The effect is that any potential
  security bugs in the VM86 mode support code are neutralized.



Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.