Re: Arbitrary Sandbox

[Shark8 <onewingedshark@gmail.com>]

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).
>
> >Could you elaborate on that? (Both what's needed to make such an
> >environment and what was done on Janus/Ada.)
>
> 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.
>
> Of course, some programs do need self-modifying code, and an OS would have
> provided an API for that purpose. But it should have been rarely used.
>
> Now, I recognize that DEP was added to Intel hardware to provide some of
> this protection, but the problem is that a lot of programs can't use it
> because of the basic architectual mistake (including GNAT programs until
> recently, which is why I had to leave it off on my computer - boo). Plus
> requiring a new feature to get this protection is annoying as it was always
> available in Intel hardware (back to 80286); people just had to use it and
> they didn't. (I think that was a consequence of Windows NT copying the bad
> Unix memory model more than an intentional decision - and of course the
> security issues hadn't popped up so much then). [Aside: Intel has
> de-emphasized segments in modern hardware to the point that you probably
> couldn't do this today, as you would pay a nasty performance price. Boo
> again (understandable, though).]
>
>                                                 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.)

I realize that the flat memory model is simpler, in concept, and
likely the programming community wanted to be able to "just take the
integer value of the location"... and likely was a "cheap-and-dirty"
way of handling inter-process communication. But isn't such a layout/
usage is almost asking for abuse (as you can then just fiddle around
in memory), and asking for both uncontrolled memory usage (leaks) and
unauthorized access (like you mentioned about self-modifying code)?

Though, that does bring to mind a design question: what is/are the
best way(s) to handle inter-process communication in a general-purpose
OS?