Obviously Lisp is not prone to buffer overfow controls. (unless
optimations turn bounds checking off)
But there is the question of Java.final.
Apperaently there is no equivalence in Lisp.
Simularly there is the possibility to change inheritance after runtime.
Also decaring code after runtime.
Obviously if you get trough the outer defenses Lisp is chanseless.
Any chance of anyone (Allegro) deveoping a 'sandbox' for lisp?
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
John Thingstad wrote:
> Obviously Lisp is not prone to buffer overfow controls. (unless
> optimations turn bounds checking off)
> But there is the question of Java.final.
> Apperaently there is no equivalence in Lisp.
> Simularly there is the possibility to change inheritance after runtime.
> Also decaring code after runtime.
> Obviously if you get trough the outer defenses Lisp is chanseless.
> Any chance of anyone (Allegro) deveoping a 'sandbox' for lisp?
What is your threat model? Do you allow users to add Lisp code to your
system, and want them limited to a safe subset? Or are you worried about
what is ostensibly user provided data breaching the code/data boundary
(a la buffer overflow)?
On Mon, 31 Oct 2005 15:41:54 +0100, Cameron MacKinnon
<··········@clearspot.net> wrote:
> John Thingstad wrote:
>> Obviously Lisp is not prone to buffer overfow controls. (unless
>> optimations turn bounds checking off)
>> But there is the question of Java.final.
>> Apperaently there is no equivalence in Lisp.
>> Simularly there is the possibility to change inheritance after runtime.
>> Also decaring code after runtime.
>> Obviously if you get trough the outer defenses Lisp is chanseless.
>> Any chance of anyone (Allegro) deveoping a 'sandbox' for lisp?
>
> What is your threat model? Do you allow users to add Lisp code to your
> system, and want them limited to a safe subset? Or are you worried about
> what is ostensibly user provided data breaching the code/data boundary
> (a la buffer overflow)?
Reply to me in person and I'll show why I didn't come with a release just
yet.
The comparabilities have been reported to CERT.
I had a near break in. Only tripwire (actually it's Microsoft equivalent)
save me.
They had managed to elevate privilege from user to admin.
I thought a program that played Othello was safe.
I was wrong! I nerly got a lawsuit against me.
Now I take security seriously!
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
On Mon, 31 Oct 2005 15:41:54 +0100, Cameron MacKinnon
<··········@clearspot.net> wrote:
> John Thingstad wrote:
>> Obviously Lisp is not prone to buffer overfow controls. (unless
>> optimations turn bounds checking off)
>> But there is the question of Java.final.
>> Apperaently there is no equivalence in Lisp.
>> Simularly there is the possibility to change inheritance after runtime.
>> Also decaring code after runtime.
>> Obviously if you get trough the outer defenses Lisp is chanseless.
>> Any chance of anyone (Allegro) deveoping a 'sandbox' for lisp?
>
> What is your threat model? Do you allow users to add Lisp code to your
> system, and want them limited to a safe subset? Or are you worried about
> what is ostensibly user provided data breaching the code/data boundary
> (a la buffer overflow)?
I forgot the power of read-line.
A macro got through before I could verify the line.
Be warned!
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
+ Espen Vestre <·····@vestre.net>:
| "John Thingstad" <··············@chello.no> writes:
|
|> I forgot the power of read-line.
|
| read-line? Not read?
Let me guess. READ and *READ-EVAL* ?
(I'm sure we're all guessing the same, but let us say it out loud.)
--
* Harald Hanche-Olsen <URL:http://www.math.ntnu.no/~hanche/>
- Debating gives most of us much more psychological satisfaction
than thinking does: but it deprives us of whatever chance there is
of getting closer to the truth. -- C.P. Snow
On Mon, 31 Oct 2005 18:20:32 +0100, Harald Hanche-Olsen
<······@math.ntnu.no> wrote:
> + Espen Vestre <·····@vestre.net>:
>
> | "John Thingstad" <··············@chello.no> writes:
> |
> |> I forgot the power of read-line.
> |
> | read-line? Not read?
>
> Let me guess. READ and *READ-EVAL* ?
> (I'm sure we're all guessing the same, but let us say it out loud.)
>
No I was aware of read and *read-eval* not nil would
allow insertion attacks by exploiting lisp's macro facillity.
It was read-line. Which I presummed read a steam of characters and put
them into a buffer.
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
"John Thingstad" <··············@chello.no> writes:
> No I was aware of read and *read-eval* not nil would
> allow insertion attacks by exploiting lisp's macro facillity.
> It was read-line. Which I presummed read a steam of characters and put
> them into a buffer.
I just checked read-line in the CLHS to be sure. It just reads in
characters to a string. You must have done something unsafe with the
string. Did you perhaps followup with a read-from-string without
having set *read-eval* to nil?
--
http://www.david-steuber.com/
The UnBlog: An island of conformity in a sea of quirks.
The lowest click through rate in Google's AdSense program.
----------------------------------------------------------------------
On Tue, 01 Nov 2005 03:45:00 +0100, David Steuber
<·····@david-steuber.com> wrote:
> "John Thingstad" <··············@chello.no> writes:
>
>> No I was aware of read and *read-eval* not nil would
>> allow insertion attacks by exploiting lisp's macro facillity.
>> It was read-line. Which I presummed read a steam of characters and put
>> them into a buffer.
>
> I just checked read-line in the CLHS to be sure. It just reads in
> characters to a string. You must have done something unsafe with the
> string. Did you perhaps followup with a read-from-string without
> having set *read-eval* to nil?
>
It wasn't quite that lame.
After I read the data I run cl-ppcre to check for legal format.
What they had done is utilize that utf8 encoding can be coded
in many ways to get past detection. A socalled 'venetian blind'
attack. My mistake was using a check string that was to permissive.
(unicode offers all kinds of suprises to the uninitiated.
Also it isn't covered in the CLHS ..)
The problem is I want to allow general names so a simple
[a-zA-Z]* isn't good enogh
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
On Tue, 01 Nov 2005 10:06:10 +0100, John Thingstad
<··············@chello.no> wrote:
> On Tue, 01 Nov 2005 03:45:00 +0100, David Steuber
> <·····@david-steuber.com> wrote:
>
>> "John Thingstad" <··············@chello.no> writes:
>>
>>> No I was aware of read and *read-eval* not nil would
>>> allow insertion attacks by exploiting lisp's macro facillity.
>>> It was read-line. Which I presummed read a steam of characters and put
>>> them into a buffer.
>>
>> I just checked read-line in the CLHS to be sure. It just reads in
>> characters to a string. You must have done something unsafe with the
>> string. Did you perhaps followup with a read-from-string without
>> having set *read-eval* to nil?
>>
>
> It wasn't quite that lame.
> After I read the data I run cl-ppcre to check for legal format.
> What they had done is utilize that utf8 encoding can be coded
> in many ways to get past detection. A socalled 'venetian blind'
> attack. My mistake was using a check string that was to permissive.
> (unicode offers all kinds of suprises to the uninitiated.
> Also it isn't covered in the CLHS ..)
> The problem is I want to allow general names so a simple
> [a-zA-Z]* isn't good enogh
>
Before you ask.. I did just store the value and nothing happened.
The problem came later when the application saved the data.
Now reading it from a disk which the user does not have wite access
is safe right. Wrong! It used read (acually the points persistent
classes lib did) Now the string get's executed..
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
John Thingstad wrote:
> Obviously Lisp is not prone to buffer overfow controls. (unless
> optimations turn bounds checking off)
> But there is the question of Java.final.
> Apperaently there is no equivalence in Lisp.
> Simularly there is the possibility to change inheritance after runtime.
> Also decaring code after runtime.
> Obviously if you get trough the outer defenses Lisp is chanseless.
> Any chance of anyone (Allegro) deveoping a 'sandbox' for lisp?
This will probably take a lot of work because there are a lot of
potential security holes. (Think about (setf symbol-function).)
Dylan has a notion of sealed generic functions and sealed classes which
could be useful here. However, an all-or-nothing approach is also not
quite right. You probably want a more fine-grained approach which allows
you to give different parts of a program different "rights" or capabilities.
We are actually thinking about using something like ContextL to grant
rights for some code in a certain context (and disallow changing the
rights for that context at the same time). However, this is no more than
a vague idea by now, there is probably a lot of work to be done to make
this work.
Pascal
--
My website: http://p-cos.net
Closer to MOP & ContextL:
http://common-lisp.net/project/closer/
On Mon, 31 Oct 2005 14:30:24 +0100, Pascal Costanza <··@p-cos.net> wrote:
>
> We are actually thinking about using something like ContextL to grant
> rights for some code in a certain context (and disallow changing the
> rights for that context at the same time). However, this is no more than
> a vague idea by now, there is probably a lot of work to be done to make
> this work.
>
>
> Pascal
>
Well if you ever do start. Sign me in!
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
On Mon, 31 Oct 2005 14:30:24 +0100, Pascal Costanza <··@p-cos.net> wrote:
> John Thingstad wrote:
>> Obviously Lisp is not prone to buffer overfow controls. (unless
>> optimations turn bounds checking off)
>> But there is the question of Java.final.
>> Apperaently there is no equivalence in Lisp.
>> Simularly there is the possibility to change inheritance after runtime.
>> Also decaring code after runtime.
>> Obviously if you get trough the outer defenses Lisp is chanseless.
>> Any chance of anyone (Allegro) deveoping a 'sandbox' for lisp?
>
> This will probably take a lot of work because there are a lot of
> potential security holes. (Think about (setf symbol-function).)
>
> Dylan has a notion of sealed generic functions and sealed classes which
> could be useful here. However, an all-or-nothing approach is also not
> quite right. You probably want a more fine-grained approach which allows
> you to give different parts of a program different "rights" or
> capabilities.
>
> We are actually thinking about using something like ContextL to grant
> rights for some code in a certain context (and disallow changing the
> rights for that context at the same time). However, this is no more than
> a vague idea by now, there is probably a lot of work to be done to make
> this work.
>
>
> Pascal
>
Well seems to me secutity is on a functional unit basis.
(colection of fuctions, mostly because allegro concatinates functions
with a jmp instruction sometimes. (tail recursion elimintaion))
It seems to me the appropriate messure is to use a feature simular
to filesystems and the windows registry. To assign a ACL to a
package directive. Ideally that feature would be set to t
but in our case I think nil would provide better compatabillity.
A function-pr-function privelege seems too expensive.
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
On Mon, 31 Oct 2005 14:30:24 +0100, Pascal Costanza <··@p-cos.net>
wrote:
>John Thingstad wrote:
>> Any chance of anyone (Allegro) developing a 'sandbox' for lisp?
>
>This will probably take a lot of work because there are a lot of
>potential security holes. (Think about (setf symbol-function).)
>
>Dylan has a notion of sealed generic functions and sealed classes which
>could be useful here. However, an all-or-nothing approach is also not
>quite right. You probably want a more fine-grained approach which allows
>you to give different parts of a program different "rights" or capabilities.
Continuing in the Scheme vein, you could use R5RS eval with a
customized environment. A real leak proof sandbox would be a chore,
but it might suffice to replace set! and define with safe versions
that won't rebind core functions.
George
--
for email reply remove "/" from address
On Wed, 2 Nov 2005 05:13:47 +0000 (UTC), ·······@typhoon.xnet.com
(James Graves) wrote:
>George Neuner <·········@comcast.net> wrote:
>
>... you could use R5RS eval with a
>>customized environment. A real leak proof sandbox would be a chore,
>>but it might suffice to replace set! and define with safe versions
>>that won't rebind core functions.
>
>It isn't much of a chore in Scheme. Jonathan Rees had done his
>dissertation on implementing object capability security in Scheme.
>It is mostly about the module system.
>
>Please check out:
>
>http://mumble.net/~jar/pubs/secureos/
Rees implemented a version of Scheme [Scheme48] based on a secure
virtual machine and compiler. His built in "security kernel" used
checked binding forms, a code walking verifier, immutable types and
secure instructions in the VM to ensure that untrusted code wouldn't
violate it's security profile - which was module based. I don't see
how completely reimplementing the language is _not_ a "chore".
AFAIK, Scheme48 is the only working implementation that supports
Rees's security constructs. I've never used it, but it is reported to
be reliable. It is considered an experimental version, but even so,
it might be an option for the original poster.
Working _in_ Scheme rather than _on_ it, R5RS defined eval to require
a specified execution environment ... which can be the program's
interaction environment [similar to Lisp's eval], a basic unextended
Scheme environment, or a null environment. Some implementations
extend the report to provide a full first class environment type which
eval can extend incrementally and which can be preserved between uses.
In portable Scheme the eval environment resets with every call unless
you always specify the program's interaction environment. If you want
something vastly different you have specify one of the template
environments [basic or null] and pass a form which (re)constructs your
desired environment each time ... it makes the usage very unwieldy and
really only suitable for long running tasks or REPLs.
George
--
for email reply remove "/" from address
On Thu, 03 Nov 2005 14:19:40 +0100, George Neuner <·········@comcast.net>
wrote:
and which can be preserved between uses.
>
> In portable Scheme the eval environment resets with every call unless
> you always specify the program's interaction environment. If you want
> something vastly different you have specify one of the template
> environments [basic or null] and pass a form which (re)constructs your
> desired environment each time ... it makes the usage very unwieldy and
> really only suitable for long running tasks or REPLs.
>
> George
> --
> for email reply remove "/" from address
Yes, I read a "Security Kernal based on the lambda-calculus" by Jonathan
A. Rees.
Obviously two namespaces complicate things a bit.
Nevertheless with double the effort I think it can be approached.
It convinced me it could be done (even in Common-Lisp)!
Thanks for the (unexpected) help from the Scheme comunity :)
(By the way why is scheme written with one 'e' instead of two as in
scheeme?)
John
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
On Thu, 03 Nov 2005 16:32:01 +0100, "John Thingstad"
<··············@chello.no> wrote:
>(By the way why is scheme written with one 'e' instead of two as in
>scheeme?)
Because "scheme" is correct English meaning, variously, "a plan" or
"to plan". I believe the long 'e' pronunciation stems from Greek.
[anyone who knows the etymology for certain, feel free to correct.]
As for Scheme the language, it was originally called SCHEMER (one who
plans). The name shortened because the ITS system used to develop it
had a 6 character filename limit.
George
--
for email reply remove "/" from address
John Thingstad <··············@chello.no> wrote:
>Yes, I read a "Security Kernal based on the lambda-calculus" by Jonathan
>A. Rees.
>Obviously two namespaces complicate things a bit.
>Nevertheless with double the effort I think it can be approached.
>It convinced me it could be done (even in Common-Lisp)!
>Thanks for the (unexpected) help from the Scheme comunity :)
>(By the way why is scheme written with one 'e' instead of two as in
>scheeme?)
Common Lisp being a Lisp-2 vs. Scheme being a Lisp-1 is not the
problem.
The problem is that Common Lisp has a lot of global variables which
control state. Many of these are writable.
Also, you've got constructs like SETF, which is really handy because you
can then do things like (setf (car list1) 'foobar). However, this
requires DEFSETF which keeps a database of the different kinds of forms
you can use with SETF.
I had started looking into what it would take to implement object-level
confinement in Common Lisp. I concluded that what you'd end up with
couldn't reasonably be called Common Lisp anymore. So I gave up on that.
James Graves
On Fri, 04 Nov 2005 02:52:49 +0100, James Graves
<·······@typhoon.xnet.com> wrote:
>
> I had started looking into what it would take to implement object-level
> confinement in Common Lisp. I concluded that what you'd end up with
> couldn't reasonably be called Common Lisp anymore. So I gave up on that.
>
> James Graves
Perhaps, I rejoyced to early?
Do you have a report of your insights.
Not that I distrust your jugement. But I need to see for myself.
For what it is worth I hope you are wrong but fear you are right.
John
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
John Thingstad <··············@chello.no> wrote:
>Do you have a report of your insights.
>Not that I distrust your jugement. But I need to see for myself.
>For what it is worth I hope you are wrong but fear you are right.
A report? No.
Here are a couple of my recent postings on the subject to
the e-lang mailing list:
http://eros.cs.jhu.edu/pipermail/e-lang/2005-September/011012.html
http://eros.cs.jhu.edu/pipermail/e-lang/2005-September/011014.html
See also this thread:
http://eros.cs.jhu.edu/pipermail/e-lang/2005-August/010914.html
Which links back to this post by Mark Miller:
http://www.eros-os.org/pipermail/e-lang/2005-April/010572.html
The extreme case for object-level confinement is being able to
handle mobile code. Code from an untrusted 3rd party which you
want to be able to call safely. (*)
I then started looking at all the bits of CL which would have
to be turned off. Not just operations on files and streams,
either. Stuff like *GENSYM-COUNTER* and *READTABLE* needs to
be walled off too.
So you end up with some subset of CL which is "safe".
Stuff like CAR, CDR, REVERSE (not NREVERSE), and so on. And
you'll need to re-do or replace the package system, because
otherwise, a package could just load COMMON-LISP to get
all that stuff back.
The problem, in my view, is that you've now broken source
compatibility with all non-trivial code already out there.
And you've still got to do some severe work on the CL
implementation you've chosen too.
Hope that helps,
James Graves
(*) By safely I mean that you give it some data, and you get an
answer back for example. That doesn't mean the answer is correct,
or even that the code won't fail in some way. But that does mean
it won't crash your system, upset the calling application (if
written properly), and most importantly, won't start e-mailiing
spam to everyone in your address book.
On Sat, 05 Nov 2005 03:40:48 +0100, James Graves
<·······@typhoon.xnet.com> wrote:
>
> Hope that helps,
>
> James Graves
>
Yes, I have a better idea of the hornets nest I have stuck my hand into
now :)
I do have a few ideas however:
1. A function (check-practises 'my-proccess) that thunks 'dangerous' Lisp
functions like
read and make-array (with dynamic array it is succepible to a DOS
attack)
Gives you a better idea of what a untrusted library does.
Needs a measure of code coverage to be effective but most Lisp's
(with debug setting) have a means of providing this.
2. Trapping access to global vaiables and checking for write. (This should
not be a error but a warning.)
This might help setf style unsecure practises without hurting
performance overmuch.
3. Trapping attemps to overwrite ANSI / vendor spesific functions.
There are probably many more isses. For instance I have not covered file
access and area/settings.
Not entirely sure if this is practical but at least I have a better idea
than I had 5 days ago.
As usual any feedback (from anyone with a informed view) is welcome!
Thanks for the feedback James.
I also want to look into Pascal Constanza's suggestion of a more fine
grained security.
That is a posibillity of setting a security level.
John
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
John Thingstad <··············@chello.no> wrote:
>Yes, I have a better idea of the hornets nest I have stuck my hand into
>now :)
>I do have a few ideas however:
>
>1. A function (check-practises 'my-proccess) that thunks 'dangerous' Lisp
>functions like
> read and make-array (with dynamic array it is succepible to a DOS
>attack)
> Gives you a better idea of what a untrusted library does.
> Needs a measure of code coverage to be effective but most Lisp's
> (with debug setting) have a means of providing this.
>
>2. Trapping access to global vaiables and checking for write. (This should
>not be a error but a warning.)
> This might help setf style unsecure practises without hurting
>performance overmuch.
>
>3. Trapping attemps to overwrite ANSI / vendor spesific functions.
>
>There are probably many more isses. For instance I have not covered file
>access and area/settings.
>Not entirely sure if this is practical but at least I have a better idea
>than I had 5 days ago.
>As usual any feedback (from anyone with a informed view) is welcome!
>Thanks for the feedback James.
>I also want to look into Pascal Constanza's suggestion of a more fine
>grained security.
>That is a posibillity of setting a security level.
After I came to the conclusion that object-level confinement wouldn't be
workable, I spent some time thinking about image-level confinement
instead.
What I mean by this is a scheme to quickly and easily create a new
operating system level sandbox for a CL instance to run in. Like the
FreeBSD jail() or a entire virtual server using Xen or VMware.
The CL implementation runs inside the sandbox, thinking it has access to
the entire machine and network. However, you carefully place inside the
environment the files it should have access to, and you also restrict
network access using a stateful firewall.
It is then also easy to place limits on the resource usage (memory, CPU,
disk) by the library / application.
The work will be to create the management structure. This would make it
easy to spawn off a new sandbox, configure it, and populate it.
Ideally, instead of copying files into the sandbox, there would be a
means to just selectively map individual files and directories into the
sandbox.
There could be a lot of optimization done to speed up creation of the
sandboxes, and to speed up the communication between them.
This would make the possibility of running unmodified CL
implementations, or other languages entirely. As long as they all use
the same network protocol for RPC / object exchange / whatever.
Ideally, more people would implement promise pipelining libraries, as in
E.
I hope I've given you plenty to think about.
Take care,
James Graves
·······@typhoon.xnet.com (James Graves) writes:
> (*) By safely I mean that you give it some data, and you get an
> answer back for example. That doesn't mean the answer is correct,
> or even that the code won't fail in some way. But that does mean
> it won't crash your system, upset the calling application (if
> written properly), and most importantly, won't start e-mailiing
> spam to everyone in your address book.
/me is waiting for the day when a text messaging worm starts
propagating itself over wireless phone networks.
--
http://www.david-steuber.com/
The UnBlog: An island of conformity in a sea of quirks.
http://www.david-steuber.com/snippets/Boycott_Sony/
----------------------------------------------------------------------
On Fri, 04 Nov 2005 02:52:49 +0100, James Graves
<·······@typhoon.xnet.com> wrote:
> John Thingstad <··············@chello.no> wrote:
>
>> Yes, I read a "Security Kernal based on the lambda-calculus" by Jonathan
>> A. Rees.
>> Obviously two namespaces complicate things a bit.
>> Nevertheless with double the effort I think it can be approached.
>> It convinced me it could be done (even in Common-Lisp)!
>> Thanks for the (unexpected) help from the Scheme comunity :)
>> (By the way why is scheme written with one 'e' instead of two as in
>> scheeme?)
>
> Common Lisp being a Lisp-2 vs. Scheme being a Lisp-1 is not the
> problem.
>
> The problem is that Common Lisp has a lot of global variables which
> control state. Many of these are writable.
>
> Also, you've got constructs like SETF, which is really handy because you
> can then do things like (setf (car list1) 'foobar). However, this
> requires DEFSETF which keeps a database of the different kinds of forms
> you can use with SETF.
>
> I had started looking into what it would take to implement object-level
> confinement in Common Lisp. I concluded that what you'd end up with
> couldn't reasonably be called Common Lisp anymore. So I gave up on that.
>
> James Graves
There is a option you may not have seen.
Isolate the global data in a seperate segment.
Now interupt when the segment is accessed then check it.
The same can be used for setf.
Use the OS to your advantage!
John
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
George Neuner <·········@comcast.net> wrote:
>Rees implemented a version of Scheme [Scheme48] based on a secure
>virtual machine and compiler. His built in "security kernel" used
>checked binding forms, a code walking verifier, immutable types and
>secure instructions in the VM to ensure that untrusted code wouldn't
>violate it's security profile - which was module based. I don't see
>how completely reimplementing the language is _not_ a "chore".
I meant "not a chore" in the sense that he didn't have to invent his
own language.
Also, keep in mind that Scheme 48 got its name because the first
implementation was written in one weekend. It is not that big a
codebase, really.
>AFAIK, Scheme48 is the only working implementation that supports
>Rees's security constructs. I've never used it, but it is reported to
>be reliable. It is considered an experimental version, but even so,
>it might be an option for the original poster.
Scheme 48 is a testbed for the authors' ideas and experimentation.
However, the docs are decent (though not complete). And the
implementation itself seems pretty stable.
Scheme 48 is also used as the foundation for SCSH.
>Working _in_ Scheme rather than _on_ it, R5RS defined eval to require
>a specified execution environment ... which can be the program's
>interaction environment [similar to Lisp's eval], a basic unextended
>Scheme environment, or a null environment. Some implementations
>extend the report to provide a full first class environment type which
>eval can extend incrementally and which can be preserved between uses.
>
>In portable Scheme the eval environment resets with every call unless
>you always specify the program's interaction environment. If you want
>something vastly different you have specify one of the template
>environments [basic or null] and pass a form which (re)constructs your
>desired environment each time ... it makes the usage very unwieldy and
>really only suitable for long running tasks or REPLs.
That is unfortunate. I don't recall that eval enviroment improvements
were on the table for R6RS. Is anyone pushing that?
James Graves
On Fri, 4 Nov 2005 02:04:15 +0000 (UTC), ·······@typhoon.xnet.com
(James Graves) wrote:
>George Neuner <·········@comcast.net> wrote:
>
>>Rees implemented a version of Scheme [Scheme48] based on a secure
>>virtual machine and compiler. His built in "security kernel" used
>>checked binding forms, a code walking verifier, immutable types and
>>secure instructions in the VM to ensure that untrusted code wouldn't
>>violate it's security profile - which was module based. I don't see
>>how completely reimplementing the language is _not_ a "chore".
>
>I meant "not a chore" in the sense that he didn't have to invent his
>own language.
Well, Rees did his work during the R4RS era, so if he had started with
an up-to-date compliant Scheme, at a minimum he would have had to
design and implement everything associated with multiple environments.
I know that isn't terribly difficult, but it is time consuming to get
right.
I recall that a few of the R4RS implementations were starting to deal
with multiple environments already, but there was little agreement on
what support was needed. I've always had the feeling that the R5RS
committee really didn't want to deal with them and included the bare
minimum functionality just to get people to shut up.
>Also, keep in mind that Scheme 48 got its name because the first
>implementation was written in one weekend. It is not that big a
>codebase, really.
That's true, but the first [several] versions didn't include either
the code verifier or the module design and the VM was revised twice
that I'm aware of. The Scheme48 VM was written in PreScheme which
Rees developed with Rick Kelsey. I was a student of Kelsey's in
1991-2 when he was working on PreScheme [not that he would remember me
and I never met Rees]. I followed the progress of their work for
quite a while afterward.
>Scheme 48 is also used as the foundation for SCSH.
I wasn't aware of that - thanks!
>>In portable Scheme the eval environment resets with every call unless
>>you always specify the program's interaction environment. If you want
>>something vastly different you have specify one of the template
>>environments [basic or null] and pass a form which (re)constructs your
>>desired environment each time ... it makes the usage very unwieldy and
>>really only suitable for long running tasks or REPLs.
>
>That is unfortunate. I don't recall that eval enviroment improvements
>were on the table for R6RS. Is anyone pushing that?
The committee has said that a module system will _definitely_ be part
of R6RS so they will certainly have to address issues with multiple
environments. I think there are probably enough implementations which
already have first class environments that a common API for them can
be settled without much controversy.
George
--
for email reply remove "/" from address
John Thingstad wrote:
> Obviously Lisp is not prone to buffer overfow controls. (unless
> optimations turn bounds checking off)
> But there is the question of Java.final.
> Apperaently there is no equivalence in Lisp.
> Simularly there is the possibility to change inheritance after runtime.
> Also decaring code after runtime.
> Obviously if you get trough the outer defenses Lisp is chanseless.
> Any chance of anyone (Allegro) deveoping a 'sandbox' for lisp?
>
I think that final classes and sandboxes are two distinct things. To
construct a sandbox you need to create an environment in which the
running program has no access to the "outer" world, like access to the
filesystem and operating system calls - remove all corresponding
functions from the environment.
Final classes come IMO from the same paranoid object philosophy that
brought us private variables/methods. They are supposed to enforce the
clean usage of libraries - in practise more often create encumberments
than are beneficial to the code quality. One of the worst misdesigns of
the Java language was making String a final class instead of an
interface and letting the current String and StringBuffer classes just
implement that interface. This is one of the reasons, that while the
Hotspot JVM is basically very fast, many Java programs are slow, because
you can't get around this (inefficient) string implementation.
Peter
--
Ltk, the easy lisp gui http://www.peter-herth.de/ltk/
* John Thingstad:
> Obviously Lisp is not prone to buffer overfow controls. (unless
> optimations turn bounds checking off)
Not true, AREF is not guaranteed to check bounds even in "safe" code.
Florian Weimer wrote:
> * John Thingstad:
>
>
>>Obviously Lisp is not prone to buffer overfow controls. (unless
>>optimations turn bounds checking off)
>
>
> Not true, AREF is not guaranteed to check bounds even in "safe" code.
Is this true? I'm not a high-powered Lisp language lawyer, but the
Hyperspec's Description for AREF says "Accesses the array element
specified by the subscripts." Since out-of-bounds stuff isn't an array
element, accessing it via aref would seem to be non-conforming. As well,
15.1.1.1 (Array Indices) says "An array element is referred to by a
(possibly empty) series of indices. [...] Each index MUST BE [emphasis
mine] a non-negative fixnum less than the corresponding array dimension.
On the other hand, AREF also says "Exceptional Situations: None."
???
Cameron MacKinnon wrote:
> Florian Weimer wrote:
>
>> * John Thingstad:
>>
>>
>>> Obviously Lisp is not prone to buffer overfow controls. (unless
>>> optimations turn bounds checking off)
>>
>>
>>
>> Not true, AREF is not guaranteed to check bounds even in "safe" code.
>
>
> Is this true? I'm not a high-powered Lisp language lawyer, but the
> Hyperspec's Description for AREF says "Accesses the array element
> specified by the subscripts." Since out-of-bounds stuff isn't an array
> element, accessing it via aref would seem to be non-conforming. As well,
> 15.1.1.1 (Array Indices) says "An array element is referred to by a
> (possibly empty) series of indices. [...] Each index MUST BE [emphasis
> mine] a non-negative fixnum less than the corresponding array dimension.
>
> On the other hand, AREF also says "Exceptional Situations: None."
ELT has an exceptional situation defined when an index is not valid.
Wow.
Pascal
--
My website: http://p-cos.net
Closer to MOP & ContextL:
http://common-lisp.net/project/closer/
+ Cameron MacKinnon <··········@clearspot.net>:
| On the other hand, AREF also says "Exceptional Situations: None."
|
| ???
Which does not mean that AREF might not do anything exceptional.
CLHS 1.4.4.3 (The ``Arguments and Values'' Section of a Dictionary
Entry) says
Except as explicitly specified otherwise, the consequences are
undefined if these type restrictions are violated.
And as we know, "undefined" is the scariest word in the whole CLHS.
So, if you call AREF with subscripts that don't conform to 15.1.1.1
Array Indices, it's your own fault if the universe implodes.
--
* Harald Hanche-Olsen <URL:http://www.math.ntnu.no/~hanche/>
- Debating gives most of us much more psychological satisfaction
than thinking does: but it deprives us of whatever chance there is
of getting closer to the truth. -- C.P. Snow
Harald Hanche-Olsen wrote:
> And as we know, "undefined" is the scariest word in the whole CLHS.
> So, if you call AREF with subscripts that don't conform to 15.1.1.1
> Array Indices, it's your own fault if the universe implodes.
Well, that's Luke 12:48 (Spider-Man's motto) for you. Thanks for the
pointer.
Harald Hanche-Olsen <······@math.ntnu.no> writes:
> + Cameron MacKinnon <··········@clearspot.net>:
>
> | On the other hand, AREF also says "Exceptional Situations: None."
> |
> | ???
>
> Which does not mean that AREF might not do anything exceptional.
>
> CLHS 1.4.4.3 (The ``Arguments and Values'' Section of a Dictionary
> Entry) says
>
> Except as explicitly specified otherwise, the consequences are
> undefined if these type restrictions are violated.
>
> And as we know, "undefined" is the scariest word in the whole CLHS.
> So, if you call AREF with subscripts that don't conform to 15.1.1.1
> Array Indices, it's your own fault if the universe implodes.
Which is why it's good to use an implementation that specifies
behavior for this case, and why it's a bad idea to use Dr. Evil Common
Lisp if you're not trying to destroy the world.
--
/|_ .-----------------------.
,' .\ / | Free Mumia Abu-Jamal! |
,--' _,' | Abolish the racist |
/ / | death penalty! |
( -. | `-----------------------'
| ) |
(`-. '--.)
`. )----'
+ ···@conquest.OCF.Berkeley.EDU (Thomas F. Burdick):
| Harald Hanche-Olsen <······@math.ntnu.no> writes:
|
|> And as we know, "undefined" is the scariest word in the whole CLHS.
|> So, if you call AREF with subscripts that don't conform to 15.1.1.1
|> Array Indices, it's your own fault if the universe implodes.
|
| Which is why it's good to use an implementation that specifies
| behavior for this case,
Absolutely (but in the context, we were playing language lawyers.)
| And why it's a bad idea to use Dr. Evil Common Lisp if you're not
| trying to destroy the world.
There is such a thing? I want one! Where can I get a copy?
(Does it come with free beer? As in <http://www.voresoel.dk/>?)
--
* Harald Hanche-Olsen <URL:http://www.math.ntnu.no/~hanche/>
- Debating gives most of us much more psychological satisfaction
than thinking does: but it deprives us of whatever chance there is
of getting closer to the truth. -- C.P. Snow
Harald Hanche-Olsen <······@math.ntnu.no> writes:
> + ···@conquest.OCF.Berkeley.EDU (Thomas F. Burdick):
>
> | And why it's a bad idea to use Dr. Evil Common Lisp if you're not
> | trying to destroy the world.
>
> There is such a thing? I want one! Where can I get a copy?
You don't get a copy, it gets you. But don't worry, it's on its way.
> (Does it come with free beer? As in <http://www.voresoel.dk/>?)
(Now that is bizzare!)
--
/|_ .-----------------------.
,' .\ / | Free Mumia Abu-Jamal! |
,--' _,' | Abolish the racist |
/ / | death penalty! |
( -. | `-----------------------'
| ) |
(`-. '--.)
`. )----'