Re: Arbitrary Sandbox

[Tero Koskinen <tero.koskinen@iki.fi>]

On Fri, 17 Feb 2012 20:47:36 -0800 (PST)
Shark8 <onewingedshark@gmail.com> wrote:

> On Feb 15, 3:07 pm, "Randy Brukardt" <ra...@rrsoftware.com> wrote:
> > "Shark8" <onewingedsh...@gmail.com> wrote in message
> >
> > news:203d63cf-42a9-49ef-82cd-943d77b5e438@c21g2000yqi.googlegroups.com...
> > On Feb 11, 8:10 pm, "Randy Brukardt" <ra...@rrsoftware.com> wrote:
> >
> > >> Windows and Unix-based systems do not have a properly designed (native)
> > >> runtime environment -- stuff we did to make Janus/Ada more secure on DOS
> > >> extenders in the 1980s never made it to OS environments).
> >
> > The vast majority of programs do not have self-modifying code, and it
> > shouldn't be possible for them to run such code in any way. If that's the
> > case, most code-injection attacks cannot happen.
> >
> > We used the native segmentation of the Intel hardware to completely separate
> > code and data in Janus/Ada programs. It was impossible to accidentally
> > execute data simply because the data wasn't even in the same address space.
> >
> >                                                 Randy.
> 
> You know; I always wondered why they (developers, and OS designers)
> didn't take advantage of segments. It seems to be a very nice way to
> enforce security. (As you said, going all the way to the 286.)

OpenBSD uses somewhat similar tactic on i386 for its W^X
(write-or-execute) feature:  https://en.wikipedia.org/wiki/W%5EX

You can set the execute or write flags using mprotect system call, so
Just-In-Time compilers and other programs with fancy memory usage work
more of less out of the box.

Theo de Raadt's presentation from 2005 has some implementation info
and also descriptions of other security features of OpenBSD:
http://www.openbsd.org/papers/ven05-deraadt/index.html

-- 
Tero Koskinen - http://iki.fi/tero.koskinen/