In <i2ob0c6f15b1004250000s6c4ed6abza31c9c1eaa691...@mail.gmail.com>, on
04/25/2010
at 02:00 AM, Chris Craddock <crashlu...@gmail.com> said:
>If you let unauthorized code run within that same address space, you
>cannot guarantee that the unauthorized code won't be able inspect or
>modify the authorized application's data.
You can, but it doesn't happen automatically.
>In fact, it is guaranteed that the unauthorized code could do
>exactly that, which is by definition an integrity exposure just on
>its own merit.
Then the Initiator and the TMP are integrity exposures just on its own
merit. because both call unauthorized code from an authorized environment,
changing the value of JSCBAUTH back and forth as needed. It's not the
proper approach for the OP, but it is viable when appropriate. It's also a
lot of work[1] to get it right and only reasonable in highly specialized
situations.
[1] You've mentioned some, but not all, of the things that the
authorized code must deal with. It doesn't happen by magic, but
by blood, sweat, toil and tears.
--
Shmuel (Seymour J.) Metz, SysProg and JOAT
ISO position; see <http://patriot.net/~shmuel/resume/brief.html>
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
