From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-0.9 required=5.0 tests=BAYES_00,FORGED_GMAIL_RCVD, FREEMAIL_FROM autolearn=no autolearn_force=no version=3.4.4 X-Google-Thread: 103376,af0c6ea85f3ed92d X-Google-NewGroupId: yes X-Google-Attributes: gida07f3367d7,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII Received: by 10.68.74.201 with SMTP id w9mr8425781pbv.0.1329540456742; Fri, 17 Feb 2012 20:47:36 -0800 (PST) Path: wr5ni38278pbc.0!nntp.google.com!news2.google.com!postnews.google.com!f30g2000yqh.googlegroups.com!not-for-mail From: Shark8 Newsgroups: comp.lang.ada Subject: Re: Arbitrary Sandbox Date: Fri, 17 Feb 2012 20:47:36 -0800 (PST) Organization: http://groups.google.com Message-ID: References: <2aaee0a4-e820-4a75-bbaf-d9d09c366d2c@f5g2000yqm.googlegroups.com> <4da4bf75-e6c9-4c17-9072-ab6f533ed93f@vd8g2000pbc.googlegroups.com> <203d63cf-42a9-49ef-82cd-943d77b5e438@c21g2000yqi.googlegroups.com> NNTP-Posting-Host: 24.230.151.194 Mime-Version: 1.0 X-Trace: posting.google.com 1329540456 28747 127.0.0.1 (18 Feb 2012 04:47:36 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Sat, 18 Feb 2012 04:47:36 +0000 (UTC) Complaints-To: groups-abuse@google.com Injection-Info: f30g2000yqh.googlegroups.com; posting-host=24.230.151.194; posting-account=lJ3JNwoAAAAQfH3VV9vttJLkThaxtTfC User-Agent: G2/1.0 X-Google-Web-Client: true X-Google-Header-Order: HUALESNKRC X-HTTP-UserAgent: Mozilla/5.0 (Windows NT 6.1; rv:9.0.1) Gecko/20100101 Firefox/9.0.1,gzip(gfe) Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Date: 2012-02-17T20:47:36-08:00 List-Id: On Feb 15, 3:07=A0pm, "Randy Brukardt" wrote: > "Shark8" wrote in message > > news:203d63cf-42a9-49ef-82cd-943d77b5e438@c21g2000yqi.googlegroups.com... > On Feb 11, 8:10 pm, "Randy Brukardt" 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 D= OS > >> 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 separ= ate > 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 spac= e. > > Of course, some programs do need self-modifying code, and an OS would hav= e > 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 alwa= ys > available in Intel hardware (back to 80286); people just had to use it an= d > they didn't. (I think that was a consequence of Windows NT copying the ba= d > 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).] > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 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?