[kernel-hardening] HARDEN_VM86

[kernel-hardening] HARDEN_VM86

[Vasiliy Kulikov]

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

Re: [kernel-hardening] HARDEN_VM86

[Solar Designer]

Vasiliy,

On Tue, Jun 14, 2011 at 12:35:59PM +0400, Vasiliy Kulikov wrote:
> 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.

CAP_SYS_RAWIO makes more sense to me.  This is relatively low level
access to hardware, similar in spirit to what e.g. X servers do/did.
There's little sysadmin'ish in running dosemu.

> 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.

This would definitely be more usable than a capability, because both
CAP_SYS_RAWIO and CAP_SYS_ADMIN grant way too much (actually "root").

If upstream is fine with sysctl's setting gids, and this appears to be
the case, then let's go for this.

A group range would make some sense to me, but a single group is also
fine.  With just a single number to specify, you reserve two values for
special meaning, but that's OK.  Just make sure you don't grant anything
to group root by default, because gid 0 is sometimes leaked to a user
inadvertently.

BTW, a related syscall is modify_ldt(2).  You could want to research
what programs use it, and consider restricting it as well.  Perhaps with
a separate sysctl?

Thanks,

Alexander

Re: [kernel-hardening] HARDEN_VM86

[Vasiliy Kulikov]

Solar,

On Wed, Jun 15, 2011 at 18:38 +0400, Solar Designer wrote:
> If upstream is fine with sysctl's setting gids, and this appears to be
> the case, then let's go for this.

I see one problem with gid style - as gid is a per pid_namespace thing,
it should be configurable per pid_namespace.

But on the other hand, a potential bug might lead to a privilege
escalation (not a in-namespace root, but e.g. arbitrary write into any
physical address) due to the nature of the syscall.  So, in-namespace
root shouldn't be able to configure who is able to do vm86(2), otherwise
it is able to gain full root.

I'm confused :\

-- 
Vasiliy

Re: [kernel-hardening] HARDEN_VM86

[Vasiliy Kulikov]

On Wed, Jun 15, 2011 at 19:38 +0400, Vasiliy Kulikov wrote:
> On Wed, Jun 15, 2011 at 18:38 +0400, Solar Designer wrote:
> > If upstream is fine with sysctl's setting gids, and this appears to be
> > the case, then let's go for this.
> 
> I see one problem with gid style - as gid is a per pid_namespace thing,
> it should be configurable per pid_namespace.
> 
> But on the other hand, a potential bug might lead to a privilege
> escalation (not a in-namespace root, but e.g. arbitrary write into any
> physical address) due to the nature of the syscall.  So, in-namespace
> root shouldn't be able to configure who is able to do vm86(2), otherwise
> it is able to gain full root.

With CAP_SYS_RAWIO there is no such problem in OpenVZ by default as
CAP_SYS_RAWIO is disabled in CT by default.  So, specifically for OpenVZ
I see the cap check as a more preferable one.

-- 
Vasiliy Kulikov
http://www.openwall.com - bringing security into open computing environments

Re: [kernel-hardening] HARDEN_VM86

[Vasiliy Kulikov]

Solar,

On Wed, Jun 15, 2011 at 18:38 +0400, Solar Designer wrote:
> BTW, a related syscall is modify_ldt(2).  You could want to research
> what programs use it, and consider restricting it as well.  Perhaps with
> a separate sysctl?

It starts to look like seccomp v2.

http://thread.gmane.org/gmane.linux.kernel/833539/focus=833864

- but with capable(CAP_SYS_RAWIO) instead of just deny and static
syscalls list.  Will Drewry is trying to push his limiting patch with
ftrace-like syntax restrictions, but (a) it is not yet applied and (b)
it is not inherited by execve's:

https://lkml.org/lkml/2011/6/12/184

If it was not limited to one task it would serve our needs :(


-- 
Vasiliy