|
Message-ID: <20110614083559.GB7973@albatros> Date: Tue, 14 Jun 2011 12:35:59 +0400 From: Vasiliy Kulikov <segoon@...nwall.com> To: kernel-hardening@...ts.openwall.com 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 CAP_SYS_RAWIO-only. 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: 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. Thanks, -- Vasiliy
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.