RE: On the road to replacing C++
I run a (non-Lisp) eCommerce business with a significant custom manufacturing component. Many of our vendors need to perform remote support or maintenance on their equipment in the plants and we'd had a too-loose policy when we first launched.
We've since tightened that up significantly and use http://www.xceedium.com/ devices to control access. However, it does not provide the tight level of control "within machine" that Tim contemplates in #2, but does a good job on controlling and making auditable #1. Depending on the application, that might make sense. In our case, we need/intend to limit vendor access to the devices (computers or PLCs) that they "own", but since they own them entirely, we're much less concerned with limiting or auditing their actions on the machine. We also have many such instances all at the same site and so spreading the costs of access control across all of them makes it easy to swallow.
It's all about the application and the organization's risk tolerance. Banks and military are a lot more worried than a hair salon or pet shop. :)
--Jim
PS: no connection to exceedium other than as a reasonably satisfied customer.
________________________________________
From: owner-lisp-hug@lispworks.com [owner-lisp-hug@lispworks.com] on behalf of Tim Bradshaw [tfb@cley.com]
Sent: Wednesday, February 20, 2013 8:19 PM
To: Gerry Weaver
Cc: lisp-hug@lispworks.com
Subject: Re: On the road to replacing C++
I don't know what your target is, but in the sorts of places where I work(ed), there are at least a couple of things which make this nontrivial:
(1) firewalls make it extremely unlikely that any machine on the internal network would ever be accessible from the outside, with the exceptions being systems that people would certainly not allow this sort of thing to happen on (public-facing web servers and so on). There are ways around this which involve the internal machine making some (proxied) outgoing connection to the vendor's systems, but they are laborious.
(2) No-one not completely trusted (where I'm leaving "completely" undefined, because it is not well-defined as far as I know) would be allowed to type at an internal system anyway, or at least not unless they were physically supervised by someone who was.
Some vendors did provide remote support tools, but in general they were fairly obviously too fragile to use. There needs to be some way by which is is not possible for a command to be executed without the trusted person saying so, and that is often hard to ensure: the tool I looked at mostly tried to ensure this by making it impossible for the vendor person to type return, but there are other ways of getting most Unix shells to execute things, unfortunately. I think the only reliable way of doing this is to have some thing where the vendor person types some stuff and the trusted person then takes some action which sends it to the application, and that becomes little better than some IRC-alike + cut & paste.
(This isn't military BTW: I hope that they are a whole bunch fussier than we were, though I fear they may not be.)
--tim
On 20 Feb 2013, at 20:36, Gerry Weaver wrote:
Hello All,
I have been thinking about how to provide remote REPL access to my delivered application. I am extremely interested in doing that. I’ve been toying with the idea of creating an “enable remote support” feature in the application that would connect to a server at my office over https and present me with a REPL. Once the support session was finished, the user could “disable remote support”, which would then close the connection and shutdown the “remote support” process in the image. This should provide a reasonably secure way to handle this with the added benefit of allowing the customer/user to initiate/control the session. I’m curious what y’all think about something like this.
Thanks,
Gerry
From: owner-lisp-hug@lispworks.com<mailto:owner-lisp-hug@lispworks.com> [mailto:owner-lisp-hug@lispworks.com] On Behalf Of Gerry Weaver
Sent: Wednesday, February 20, 2013 2:18 PM
To: Jeff Massung
Cc: lisp-hug@lispworks.com<mailto:lisp-hug@lispworks.com>
Subject: RE: On the road to replacing C++
Hello All,
I know I’m new to Lisp, but I agree with Jeff in the general sense. I have done this in many applications. If you want to add a little additional protection, you may want to consider zipping up the source files with password protection and/or creating a little command line utility that will zip/sign them. You could then crack open the zip and/or verify the signature before evaluating them. Just a thought.
Thanks,
Gerry
From: owner-lisp-hug@lispworks.com<mailto:owner-lisp-hug@lispworks.com> [mailto:owner-lisp-hug@lispworks.com]<mailto:[mailto:owner-lisp-hug@lispworks.com]> On Behalf Of Jeff Massung
Sent: Wednesday, February 20, 2013 2:00 PM
To: lisp-hug@lispworks.com<mailto:lisp-hug@lispworks.com> Lispworks
Subject: Re: On the road to replacing C++
Never use EVAL is silly, IMO.
The question really is, do you trust the source? For example, the LW IDE uses EVAL (well, LOAD, probably) on your ~/.lispworks file, because you're the user and what would it matter if you put a "format c:" in your ~/.lispworks file?
What is important is remembering that EVAL will do just that - evaluate. Similarly, it's always important to remember that READ is capable of calling EVAL if *READ-EVAL* is non-nil.
Sometimes I really wish that Lisp had something similar to Erlang's file:consult/1 (http://www.erlang.org/doc/man/file.html#consult-1) function. You can get pretty close, though:
(defun consult (pathname)
(let ((*read-eval* nil))
(with-open-file (s pathname)
(loop :for term := (read s nil nil) :while term :collect term))))
It's just not quite the same. But, most of the time it fits the bill perfectly.
As for having some kind of scripting language in Lisp that's somehow a subset of Lisp or something else, I used to think this would be cool, and then I come back to asking myself why? What would be the point?
If I trust the source (a user having bought a product or myself), then give them the full access. Why not? After all, then you'll have the totally awesome capability to bug fix a running system for them, send patch files, etc. In my experience, if you trust the source and don't provide full access, you'll end up sticking in a backdoor for yourself, and then once that cat's out of the bag, you'll be kicking yourself for putting tons of effort into creating a sandbox that's easily bypassed (which will happen).
And, if you don't trust the source of the "script," then you have a whole host of other problems to think about besides whether or not to use EVAL.. :-)
My 2 cents.
Jeff M.
On Wed, Feb 20, 2013 at 1:27 PM, David McClain <david@acudora.com<mailto:david@acudora.com>> wrote:
>> Anyone else have a better idea? Has to evaluate in the current
>> dynamic environment and the null lexical environment, just like EVAL.
>
> Then just use EVAL. This is the reason why EVAL is frowned upon, but if
> that's what you need then you need EVAL.
Yes, every now and again, I revisit old prescriptions... like "never use EVAL", "never use global vars", "never use goto"... I'm old enough to have been through a number of revolutions, starting with the advent of "structured programming", "object oriented programming", and so on.
There was no "C" compiler when I started -- just PL/1 and Assembly, Cobol, Snobol, and RPG... We went through some great times, but sad to say, things often get pushed beyond the point of reasonableness. C++ now looks like a pig in lipstick.
Whenever I hear a rule repeated in my head, I need to ask why? what was the context of the time? What were the reasons for believing these edicts?
Just trying to clear out old cobwebs...
- DM
_______________________________________________
Lisp Hug - the mailing list for LispWorks users
lisp-hug@lispworks.com<mailto:lisp-hug@lispworks.com>
http://www.lispworks.com/support/lisp-hug.html
_______________________________________________
Lisp Hug - the mailing list for LispWorks users
lisp-hug@lispworks.com
http://www.lispworks.com/support/lisp-hug.html