I haven't really found much online about this, but I'm a little
worried about security with a current application I'm writing. This is
new territory for me, so I'd appreciate any links or insights from
others who have dealt with this before..
The basic concern I have boils down to EVAL. Let me give a quick
example that doesn't seem to have problems, ask why, and that should
give an idea of where I'm going. Let's say I created a simple web
server with LispWorks that had a simple edit box that allowed a
visitor to play with Lisp, enter an expression, click submit, and see
the results. What prevents the user from entering something akin to
(run-shell-command "format c:")?
That example (the website) is probably a little easier given that one
could make the Lisp process run as a guest and various shell commands
would be completely unavailable. But, what if it was just an end
application reading a configuration file with Lisp data for ease or
(as in my case) a server/client sending Lisp data back and forth
across the internet, where both users are most likely running as
superusers (yay for Windows)?
Anyway, any advice people have on this is much appreciated.
Thanks!
Jeff M.
On Sep 25, 12:35 pm, "Jeff M." <·······@gmail.com> wrote:
> I haven't really found much online about this, but I'm a little
> worried about security with a current application I'm writing. This is
> new territory for me, so I'd appreciate any links or insights from
> others who have dealt with this before..
>
> The basic concern I have boils down to EVAL. Let me give a quick
> example that doesn't seem to have problems, ask why, and that should
> give an idea of where I'm going. Let's say I created a simple web
> server with LispWorks that had a simple edit box that allowed a
> visitor to play with Lisp, enter an expression, click submit, and see
> the results. What prevents the user from entering something akin to
> (run-shell-command "format c:")?
>
> That example (the website) is probably a little easier given that one
> could make the Lisp process run as a guest and various shell commands
> would be completely unavailable. But, what if it was just an end
> application reading a configuration file with Lisp data for ease or
> (as in my case) a server/client sending Lisp data back and forth
> across the internet, where both users are most likely running as
> superusers (yay for Windows)?
>
> Anyway, any advice people have on this is much appreciated.
>
> Thanks!
>
> Jeff M.
How is this a lisp issue? If you put up a text box and allowed
arbitrary INTERCAL to be entered and executed, it would have exactly
the same problem, wouldn't it? And why worry about shell commands?
Do you think lisp isn't powerful enough to do damage by itself?
My very first lisp program brought down a time-sharing system, and
it was supposed to be solving the 8-queens problem.
--S
On Sep 25, 6:31 pm, smallpond <·········@juno.com> wrote:
> On Sep 25, 12:35 pm, "Jeff M." <·······@gmail.com> wrote:
>
>
>
> > I haven't really found much online about this, but I'm a little
> > worried about security with a current application I'm writing. This is
> > new territory for me, so I'd appreciate any links or insights from
> > others who have dealt with this before..
>
> > The basic concern I have boils down to EVAL. Let me give a quick
> > example that doesn't seem to have problems, ask why, and that should
> > give an idea of where I'm going. Let's say I created a simple web
> > server with LispWorks that had a simple edit box that allowed a
> > visitor to play with Lisp, enter an expression, click submit, and see
> > the results. What prevents the user from entering something akin to
> > (run-shell-command "format c:")?
>
> > That example (the website) is probably a little easier given that one
> > could make the Lisp process run as a guest and various shell commands
> > would be completely unavailable. But, what if it was just an end
> > application reading a configuration file with Lisp data for ease or
> > (as in my case) a server/client sending Lisp data back and forth
> > across the internet, where both users are most likely running as
> > superusers (yay for Windows)?
>
> > Anyway, any advice people have on this is much appreciated.
>
> > Thanks!
>
> > Jeff M.
>
> How is this a lisp issue? If you put up a text box and allowed
> arbitrary INTERCAL to be entered and executed, it would have exactly
> the same problem, wouldn't it? And why worry about shell commands?
> Do you think lisp isn't powerful enough to do damage by itself?
> My very first lisp program brought down a time-sharing system, and
> it was supposed to be solving the 8-queens problem.
>
> --S
This seems to come down to two things, I'm not sure which you want.
If you're planning on taking input and evaluating it as code, you
should try to use a white-list of allowed functions, such as + and -.
So after you read the code in using the tips from John, check whether
the list structure uses only the white-listed functions before an
eval, and set up error handling code before running the eval for
unforeseen errors like (/ 3 0).
A different point, which is more of a lisp issue, is keeping track of
tainting. I'm not sure of how to do that in CL, but the idea is
generally to make sure that any data coming from the outside world
does not contribute as input to some potentially dangerous function
you are running. For lack of code, you could possibly use hungarian
style naming convention, such as "us-input-string", where "us-" marks
the string as unsafe. You would then run your code as
(let ((safe-input (make-input-safe us-input-string)))
(unsafe-function safe-input))
On Sep 25, 6:35 pm, "Jeff M." <·······@gmail.com> wrote:
> I haven't really found much online about this, but I'm a little
> worried about security with a current application I'm writing. This is
> new territory for me, so I'd appreciate any links or insights from
> others who have dealt with this before..
Many programming languages -- as mainstream as PHP -- have such
security holes. Just today I saw a PHP webapp which lets users execute
arbitrary PHP.
Last week, I took a security course where someone found a nasty
security hole in a PHP webapp analogous to this:
(run-shell-command (format nil "chmod 755 ~A" filename))
where the filename comes straight from the user.
FAIL. ;)
As a guess, maybe you can scrub the user's environment free of
operators you don't want attackers to execute. Use a whitelist instead
of a blacklist -- specify the operators you allow people to use,
rather than ban the "bad ones". If you get the least itchy feeling
that an operator can subvert your defense (like INTERN), don't allow
it.
Make an empty read-table (with (copy-readtable nil) maybe?), and set
*READ-EVAL* to nil.
To prevent denial-of-service, you can set time and space limits. The
multiprocessing libraries probably have something which aborts a
computation which takes too long. Likewise, maybe you can do something
similar with taking too much memory.
Good securing,
Tayssir
On Sep 25, 9:14 pm, Tayssir John Gabbour <············@googlemail.com>
wrote:
> On Sep 25, 6:35 pm, "Jeff M." <·······@gmail.com> wrote:
>
> > I haven't really found much online about this, but I'm a little
> > worried about security with a current application I'm writing. This is
> > new territory for me, so I'd appreciate any links or insights from
> > others who have dealt with this before..
A bit further, you could make your own interpreter or whatever...
And you should probably tighten up on the reader further than I
mentioned... I don't use it much, so I haven't given much thought to
how attackers could exploit it, given your system. For example, you
might not want them referring to symbols from arbitrary packages.
Tayssir
P� Thu, 25 Sep 2008 18:35:41 +0200, skrev Jeff M. <·······@gmail.com>:
> I haven't really found much online about this, but I'm a little
> worried about security with a current application I'm writing. This is
> new territory for me, so I'd appreciate any links or insights from
> others who have dealt with this before..
This question comes up from time to time.
>
> The basic concern I have boils down to EVAL. Let me give a quick
> example that doesn't seem to have problems, ask why, and that should
> give an idea of where I'm going. Let's say I created a simple web
> server with LispWorks that had a simple edit box that allowed a
> visitor to play with Lisp, enter an expression, click submit, and see
> the results. What prevents the user from entering something akin to
> (run-shell-command "format c:")?
>
Nothing. And unlike Java and C# it doesn't have any way of restricting
access directly.
You can get some of the same effect by running the server with a user with
restricted privileges and by running a restricted shell.
The natural thing is of course not to export Lisp on your server to all
people on the web. As a extra gotcha be careful when using READ to get
values from forms as well. The user can still fire up the evaluator by
using read-time evaluation. (That is #.(run-shell-command "format c:")) So
set *read-eval* to nil before using read.
> That example (the website) is probably a little easier given that one
> could make the Lisp process run as a guest and various shell commands
> would be completely unavailable. But, what if it was just an end
> application reading a configuration file with Lisp data for ease or
> (as in my case) a server/client sending Lisp data back and forth
> across the internet, where both users are most likely running as
> superusers (yay for Windows)?
>
Well the golden rule for Internet communication is to be generous in what
you accept and strict in what you produce. Never the less I would check
the validity of all data you receive. Perhaps parse it with cl-ppcre or
store data using CXML and verify it with RELAX-NG. At least don't accept
generic Lisp from arbitrary users over the web. (To a unrestricted server
at least.)
--------------
John Thingstad
On 2008-09-25 18:08:34 +0100, "John Thingstad" <·······@online.no> said:
> Well the golden rule for Internet communication is to be generous in
> what you accept and strict in what you produce.
I'm not sure how "golden" is that rule, but it surely sounds
like a call for general non-compliance, "anything goes", "the
market will sort it out" amd other utter non sense we've been
all spoon fed all those years.
How do you think eveloution works? Rejection of the non-fitting.
"Do not accept what doesn't follow the rules" would make a tad
lot more sense, IMHO :-)
--
JFB
verec <·····@mac.com> writes:
> On 2008-09-25 18:08:34 +0100, "John Thingstad" <·······@online.no> said:
>
>> Well the golden rule for Internet communication is to be generous in
>> what you accept and strict in what you produce.
>
> I'm not sure how "golden" is that rule, but it surely sounds
> like a call for general non-compliance, "anything goes", "the
> market will sort it out" amd other utter non sense we've been
> all spoon fed all those years.
>
> How do you think eveloution works? Rejection of the non-fitting.
> "Do not accept what doesn't follow the rules" would make a tad
> lot more sense, IMHO :-)
Yes, but one time, the little bacterias need to stop fighting, and
start working together, to build an higher order organism.
This is what this golden rule for Internet did: let emerge an higher
order system from independant computers.
--
__Pascal Bourguignon__ http://www.informatimago.com/
ATTENTION: Despite any other listing of product contents found
herein, the consumer is advised that, in actuality, this product
consists of 99.9999999999% empty space.
P� Sun, 28 Sep 2008 21:42:37 +0200, skrev verec <·····@mac.com>:
> On 2008-09-25 18:08:34 +0100, "John Thingstad" <·······@online.no> said:
>
>> Well the golden rule for Internet communication is to be generous in
>> what you accept and strict in what you produce.
>
> I'm not sure how "golden" is that rule, but it surely sounds
> like a call for general non-compliance, "anything goes", "the
> market will sort it out" amd other utter non sense we've been
> all spoon fed all those years.
>
> How do you think eveloution works? Rejection of the non-fitting.
> "Do not accept what doesn't follow the rules" would make a tad
> lot more sense, IMHO :-)
> --
> JFB
>
Somehow I fail to see how on earth you manage to get to that conclusion
from what I wrote. By being strict in what you produce I mean adhering to
standards and assuring correctness. In being generous in what you accept I
mean allowing for that other's are not as rigorous and recovering from it.
Pretty much the opposite of what you say.
--------------
John Thingstad
On 2008-09-28 21:22:17 +0100, "John Thingstad" <·······@online.no> said:
> In being generous in what you accept I mean allowing for that other's
> are not as rigorous and recovering from it.
Yes, that's excatly what I understood you meant, and that's
also what I think is wrong!
How lenient is your C language spec? Your Pascal apec?
Your java spec? You Scheme spec? Your CL spec? Your Haskell
spec?
Not a lot, from my experience ... last time I tried
to feed "public static void main(String[] args)" to the
REPL it barked at me, which I consider a *good thing*.
Don't you?
> Pretty much the opposite of what you say.
???
--
JFB
P� Mon, 29 Sep 2008 00:06:04 +0200, skrev verec <·····@mac.com>:
>
> How lenient is your C language spec? Your Pascal apec?
> Your java spec? You Scheme spec? Your CL spec? Your Haskell
> spec?
>
Since when was a RFC standard written in a particular computer language
and since when was it so rigid it left no room for interpretation?
--------------
John Thingstad
In article <·······················@news.aaisp.net.uk>,
verec <·····@mac.com> wrote:
> On 2008-09-28 21:22:17 +0100, "John Thingstad" <·······@online.no> said:
>
> > In being generous in what you accept I mean allowing for that other's
> > are not as rigorous and recovering from it.
>
> Yes, that's excatly what I understood you meant, and that's
> also what I think is wrong!
>
> How lenient is your C language spec? Your Pascal apec?
> Your java spec? You Scheme spec? Your CL spec? Your Haskell
> spec?
The difference is that C compilers are used directly by the programmers.
If they make a mistake, they're told about it immediately, and can
correct them.
Internet servers have to deal with many different clients, and vice
versa, most of which were never tested together by the implementors. By
the time they get together, it's end users who are impacted; if there's
a problem, they generally can't do anything to correct it. In a
connected world there are often dozens of different client and server
implementations, and it's unrealistic to expect them all to get all the
details right, especially when standards evolve. So being liberal and
ignoring minor errors allows people to get work done.
Sometimes this flexibility is incorporated directly into the spec. For
instance, HTML specifically says that if you don't recognize a tag,
ignore it. This allows people to experiment with new tags and browsers
that recognize them, without losing compatibility with all the older
browsers. Of course, it's not a perfect solution; it also allows people
to write web pages that depend on Internet Explorer extensions, and they
don't work well with other browsers.
--
Barry Margolin, ······@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
*** PLEASE don't copy me on replies, I'll read them in the group ***
verec <·····@mac.com> wrote:
+---------------
| "John Thingstad" <·······@online.no> said:
| > Well the golden rule for Internet communication is to be
| > generous in what you accept and strict in what you produce.
|
| I'm not sure how "golden" is that rule...
+---------------
As John says, it is a *very* well known Internet design principle,
called the "Robustness Principle" (or less often, "Postel's Law"):
http://www.postel.org/postel.html
http://en.wikipedia.org/wiki/Robustness_Principle
It was elucidated by Internet RFC Editor Jon Postel *at least*
as far back as January 1980 in RFC 760 "Internet Protocol" (IP):
http://www.ietf.org/rfc/rfc760.txt
...
3.2. Discussion
The implementation of a protocol must be robust. Each implementation
must expect to interoperate with others created by different
individuals. While the goal of this specification is to be
explicit about the protocol there is the possibility of differing
interpretations. In general, an implementation should be conservative
in its sending behavior, and liberal in its receiving behavior.
That is, it should be careful to send well-formed datagrams, but
should accept any datagram that it can interpret (e.g., not object
to technical errors where the meaning is still clear).
By 1981, in RFC 793 "Transmission Control Protocol" (TCP), it had become
more stylized and succinct:
http://www.ietf.org/rfc/rfc793.txt
...
2.10. Robustness Principle
TCP implementations will follow a general principle of robustness:
be conservative in what you do, be liberal in what you accept from
others.
This is actually *more* generous than the Golden Rule [think it through],
and more robust than the more commonly quoted version which refers only
to protocols, as seen, say, in 1989's RFC 1122 "Requirements for Internet
Hosts -- Communication Layers" (Bob Braden, ed.):
http://www.ietf.org/rfc/rfc1122.txt
...
1.2.2 Robustness Principle
At every layer of the protocols, there is a general rule whose
application can lead to enormous benefits in robustness and
interoperability [IP:1]:
"Be liberal in what you accept,
and conservative in what you send."
This latter (or with the clauses swapped) is the version most people
would recognize.
+---------------
| ...but it surely sounds like a call for general non-compliance,
| "anything goes", "the market will sort it out" amd other utter
| non sense we've been all spoon fed all those years.
|
| How do you think eveloution works? Rejection of the non-fitting.
| "Do not accept what doesn't follow the rules" would make a tad
| lot more sense, IMHO :-)
+---------------
Well, the Internet Robustness Principle served the industry *very* well
for quite a number of years, but you do have a point, one which is
shared by others such as Marshall Rose [well known for his work in
getting several ISO applications protocols to run on top of IP/TCP].
As he noted in 2001 in RFC 3117 "On the Design of Application Protocols":
http://www.ietf.org/rfc/rfc3117.txt
...
4.5 Robustness
...
Counter-intuitively, Postel's robustness principle ("be conservative
in what you send, liberal in what you accept") often leads to
deployment problems. Why? When a new implementation is initially
fielded, it is likely that it will encounter only a subset of
existing implementations. If those implementations follow the
robustness principle, then errors in the new implementation will
likely go undetected. The new implementation then sees some, but
not widespread deployment. This process repeats for several new
implementations. Eventually, the not-quite-correct implementations
run into other implementations that are less liberal than the initial
set of implementations. The reader should be able to figure out what
happens next.
Accordingly, explicit consistency checks in a protocol are very
useful, even if they impose implementation overhead.
An even stronger argument has been made that the Robustness Principle
*encouraged* Microsoft's "embrace/extend/destroy" strategy when it came
to Web protocols, especially HTML & "the browser wars", leaving others
bending over backwards to be "liberal" enough to "accept" the non-standard
(and in many cases flat-out *broken*!) HTML produced by Windows-based
web page generation tools. Had other browsers simply refused to accept
HTML with malformed nesting of tags (say), at least some of the resulting
male bovine excrement could have been avoided.
But despite all that, the Robustness Principle still *is* thought
by many (and probably most) network engineers to be a good idea,
when not stretched beyond reasonable limits. Read the above-referenced
Wikipedia page for a more extensive discussion of the tradeoffs.
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
From: Kaz Kylheku
Subject: Re: Security concerns with Common Lisp and EVAL
Date:
Message-ID: <20080925125606.931@gmail.com>
On 2008-09-25, Jeff M. <·······@gmail.com> wrote:
> I haven't really found much online about this, but I'm a little
> worried about security with a current application I'm writing. This is
> new territory for me, so I'd appreciate any links or insights from
> others who have dealt with this before..
>
> The basic concern I have boils down to EVAL. Let me give a quick
> example that doesn't seem to have problems, ask why, and that should
> give an idea of where I'm going. Let's say I created a simple web
> server with LispWorks that had a simple edit box that allowed a
> visitor to play with Lisp, enter an expression, click submit, and see
> the results. What prevents the user from entering something akin to
> (run-shell-command "format c:")?
The way you prevent this is by writing a RESTRICTED-EVAL function and calling
that instead of EVAL.
RESTRICTED-EVAL could, for instance, recursively scan the
source code and disallow any references to symbols which do not reside in, or
are not visible through, a particular package.
Of course, RESTRICTED-EVAL could actually be called EVAL. It just wouldn't be
the COMMON-LISP::EVAL symbol.
So the RUN-SHELL-COMMAND function would simply be unavailable to programs
evaluated under this EVAL.
> That example (the website) is probably a little easier given that one
> could make the Lisp process run as a guest and various shell commands
> would be completely unavailable.
That's a valiant effort. Unfortunately, your Lisp is powerful enough that if
the attacker can pass arbitrary expressions to EVAL, he can code
his way down to making raw operating system calls. The attacker does not
require access to the shell.
> But, what if it was just an end
> application reading a configuration file with Lisp data for ease or
> (as in my case) a server/client sending Lisp data back and forth
> across the internet, where both users are most likely running as
> superusers (yay for Windows)?
A configuration file wouldn't be passed to EVAL. It could, of course, invoke
the read-time evaluation syntax (hash-dot notation). You'd guard against that
by setting *READ-EVAL* to NIL.
From: Matthias Buelow
Subject: Re: Security concerns with Common Lisp and EVAL
Date:
Message-ID: <6k42l3F5tchbU1@mid.dfncis.de>
You could make a new sandbox package, unuse-package "COMMON-LISP" (and
probably a few others, depending on your implementation) in there and
then you'll still have to modify the reader to make sure symbols get
interned/found only in the current package (that is, disabling
common-lisp:symbol references.) The latter is the hard part, I think. :)
CL should provide adequate functionality for this out of box (maybe it
does? I haven't seen it.)
From: Kaz Kylheku
Subject: Re: Security concerns with Common Lisp and EVAL
Date:
Message-ID: <20080926123313.845@gmail.com>
On 2008-09-26, Matthias Buelow <···@incubus.de> wrote:
> You could make a new sandbox package, unuse-package "COMMON-LISP" (and
> probably a few others, depending on your implementation) in there and
> then you'll still have to modify the reader to make sure symbols get
> interned/found only in the current package (that is, disabling
> common-lisp:symbol references.) The latter is the hard part, I think. :)
It's not so hard if you simply banish the colon from being a symbol
constituent. But that's a blunt way to do it.
Maybe a better idea is to walk each expression and check that it doesn't
contain references to a forbidden package.
On Sep 26, 8:36 pm, Kaz Kylheku <········@gmail.com> wrote:
> It's not so hard if you simply banish the colon from being a symbol
> constituent. But that's a blunt way to do it.
Does that work? If it does it might be a decent approach.
>
> Maybe a better idea is to walk each expression and check that it doesn't
> contain references to a forbidden package.
This (which is what I once did) does not however: it is far too late,
because the reader may already have interned things, and you need to
stop that happening except where you want it.
From: Tobias C. Rittweiler
Subject: Re: Security concerns with Common Lisp and EVAL
Date:
Message-ID: <874p40x97h.fsf@freebits.de>
Tim Bradshaw <··········@tfeb.org> writes:
> On Sep 26, 8:36�pm, Kaz Kylheku <········@gmail.com> wrote:
>
> > It's not so hard if you simply banish the colon from being a symbol
> > constituent. But that's a blunt way to do it.
>
> Does that work? If it does it might be a decent approach.
Not portably, because of the Notes section of SET-SYNTAX-FROM-CHAR and
2.1.4.2, I think.
-T.
P� Sun, 28 Sep 2008 23:13:06 +0200, skrev Tim Bradshaw
<··········@tfeb.org>:
> On Sep 26, 8:36�pm, Kaz Kylheku <········@gmail.com> wrote:
>
>> It's not so hard if you simply banish the colon from being a symbol
>> constituent. But that's a blunt way to do it.
>
> Does that work? If it does it might be a decent approach.
>
>>
>> Maybe a better idea is to walk each expression and check that it doesn't
>> contain references to a forbidden package.
>
> This (which is what I once did) does not however: it is far too late,
> because the reader may already have interned things, and you need to
> stop that happening except where you want it.
>
I must say I frown at some of the approaches suggested here. Both white
listing of commands (or black listing) and hobbling the reader suffer from
fundamental flaws. The assume a total understanding of all these command
including rarely used options. It is almost inevitable that this approach
leaves security holes. To be sure you really have to parse everything
yourself. You don't have to implement the semantics of course. This is a
lot of work. I'd feel more comfortable limiting user access at the OS
level. See Pascal's earlier post.
--------------
John Thingstad
> I must say I frown at some of the approaches suggested here. Both white
> listing of commands (or black listing) and hobbling the reader suffer from
> fundamental flaws. The assume a total understanding of all these command
> including rarely used options. It is almost inevitable that this approach
I think you need your own reader (it's just too hard to constrain the
CL reader far enough). But once you have that then I think it's not
that unreasonable use native CL functions. For anything you worry
about you should wrap them in your own known-OK version. But, say, is
it bad to call "+"? (Someone will no point out that it is).
--tim
Kaz Kylheku wrote:
> On 2008-09-26, Matthias Buelow <···@incubus.de> wrote:
>> You could make a new sandbox package, unuse-package "COMMON-LISP" (and
>> probably a few others, depending on your implementation) in there and
>> then you'll still have to modify the reader to make sure symbols get
>> interned/found only in the current package (that is, disabling
>> common-lisp:symbol references.) The latter is the hard part, I think. :)
>
> It's not so hard if you simply banish the colon from being a symbol
> constituent. But that's a blunt way to do it.
>
> Maybe a better idea is to walk each expression and check that it doesn't
> contain references to a forbidden package.
Also have to take care of read-from-string ?
-Antony
On Sep 26, 12:35 am, "Jeff M." <·······@gmail.com> wrote:
> I haven't really found much online about this, but I'm a little
> worried about security with a current application I'm writing. This is
> new territory for me, so I'd appreciate any links or insights from
> others who have dealt with this before..
>
> The basic concern I have boils down to EVAL. Let me give a quick
> example that doesn't seem to have problems, ask why, and that should
> give an idea of where I'm going. Let's say I created a simple web
> server with LispWorks that had a simple edit box that allowed a
> visitor to play with Lisp, enter an expression, click submit, and see
> the results. What prevents the user from entering something akin to
> (run-shell-command "format c:")?
>
> That example (the website) is probably a little easier given that one
> could make the Lisp process run as a guest and various shell commands
> would be completely unavailable. But, what if it was just an end
> application reading a configuration file with Lisp data for ease or
> (as in my case) a server/client sending Lisp data back and forth
> across the internet, where both users are most likely running as
> superusers (yay for Windows)?
>
> Anyway, any advice people have on this is much appreciated.
>
> Thanks!
>
> Jeff M.
Is it possible to run the lisp image in a virtual machine? The user
may enter something that will hose the virtual machine, but leave the
main application running intact.
Timbo
macoovacany <···········@gmail.com> writes:
> Is it possible to run the lisp image in a virtual machine?
Yes, it is possible.
--
__Pascal Bourguignon__ http://www.informatimago.com/
"I have challenged the entire quality assurance team to a Bat-Leth
contest. They will not concern us again."
macoovacany <···········@gmail.com> writes:
> Is it possible to run the lisp image in a virtual machine?
Yes, and by the way:
http://www.informatimago.com/linux/emacs-on-user-mode-linux.html
You can do the same with any lisp, not only with emacs.
--
__Pascal Bourguignon__ http://www.informatimago.com/
"I have challenged the entire quality assurance team to a Bat-Leth
contest. They will not concern us again."