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

Vasiliy,

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.

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

Solar,

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

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

Solar,

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