ranjit@grad1.cis.upenn.edu (Ranjit Bhatnagar) (10/04/89)
So, Commodore, you're gonna put AREXX in 1.4, eh? Soon the place will be crawling with scripts, and some of them will be simple viruses or booby traps. That was one of the objections that I brought up to my idea of symbolic links to REXX scripts. Therefore I strongly suggest that you implement a SECURE mode for AREXX, in which, for any given script, 1) writing to files and "peek/poke" can be disabled 2) ADDRESS <host> can be limited to an arbitrary list of hosts 3) external commands can be filtered to limit them to harmless ones If a script attempted to violate its probation, so to speak, it would be suspended, and a requester would pop up: AREXX script "calculator" attempted to talk to SIGNUSSPELL. [[KILL IT!]] [Well, OK, just this once] [remove all protection] A good use for this facility would be in multimedia/hypertext applications like I suggested in c.s.amiga. Most scripts would not be allowed to talk to anybody except the multimedia host which invoked them. There's a lot of kinks to be worked out-- what should the default permissions for symbolic link scripts be? What if your multimedia document wants to talk to The Director or MicroFiche Filer or some such program which is mostly harmless but could be tricked into causing damage? Note that this facility is as useful for protecting against accidental problems as it is against deliberate booby traps. Similarly, perhaps developers who create applications with AREXX ports should give them 'safe' modes, in which any external request for a destructive operation would require a confirmation by the user. Even without Secure AREXX, the situation is no different from that of public domain software. Unless you have the source code and are willing and able to read it, you just have to trust that the program is not booby trapped. With AREXX you always have access to the source, at least. It's slightly more dangerous with AREXX than ordinary software, though, because a naive user may be invoking scripts all the time much more casually than he or she would invoke unknown programs - for instance, in reading multimedia mail (voicemail) or trying out the latest macro package for emacs. A Hypercard script on the Mac could easily be programmed to wipe out your hard disk; it would be nice to have a little bit of extra safety on the Amiga. I hope the Commodore folks will consider this. -ranjit "Trespassers w" ranjit@eniac.seas.upenn.edu mailrus!eecae!netnews!eniac!... "Such a brute that even his shadow breaks things." (Lorca)
peter@sugar.hackercorp.com (Peter da Silva) (10/05/89)
> So, Commodore, you're gonna put AREXX in 1.4, eh? Soon the place > will be crawling with scripts, and some of them will be simple > viruses or booby traps. That was one of the objections that I > brought up to my idea of symbolic links to REXX scripts. How does this differ from all the programs, device drivers, handlers, and libraries already crawling all over the place? -- Peter "Have you hugged your wolf today" da Silva `-_-' ...texbell!sugar!peter, or peter@sugar.hackercorp.com 'U` ``Back off dude! I'm a topologist!'' -- Andrew Molitor <amolitor@eagle.wesleyan.edu>
ranjit@grad2.cis.upenn.edu (Ranjit Bhatnagar) (10/05/89)
In article <4276@sugar.hackercorp.com> peter@sugar.hackercorp.com (Peter da Silva) writes: >> So, Commodore, you're gonna put AREXX in 1.4, eh? Soon the place >> will be crawling with scripts, and some of them will be simple >> viruses or booby traps. That was one of the objections that I >> brought up to my idea of symbolic links to REXX scripts. > >How does this differ from all the programs, device drivers, handlers, and >libraries already crawling all over the place? I brought up that point in my original article. Couldn't hurt to read the whole thing. In more depth: 1- arexx makes it possible for all sorts of things to happen without the user's direct request or knowledge, and can make the consequences of previously harmless actions be harmful or unexpected. Example: macros for DME. Before AREXX, the only way a DME macro could do any damage was to, for instance, save an empty buffer on top of a file. With AREXX, a DME macro can do anything. Joe Casual User (JCU) downloads a new set of macros from a bulletin board, thinking that at least editor macros can't be booby trapped... 2- why the heck NOT add some protection. It's possible, and not too hard. Handy for programmers too, during testing stages. 3- it's all moot, anyway. The earth is in a cloud of asteroids; one of these days we'll be blown away. "Trespassers w" ranjit@eniac.seas.upenn.edu mailrus!eecae!netnews!eniac!... "Such a brute that even his shadow breaks things." (Lorca)
FelineGrace@cup.portal.com (Dana B Bourgeois) (10/06/89)
[line eater food] OK, OK. So Ranjit is perhaps a bit paranoid. That doesn't mean that no one is trying to kill him. I think the idea he proposed of putting a limit on the ARexx Interpreter is a good idea. It deserves some thoughtfull comment. Could we see some discussion of the idea, please? Specifically, is it possible to put in limits like Ranjit proposes? Will they do what he intends? What are alternative methods? What are the drawbacks/advantages to these alternatives? Dana @ cup.portal.com PS: nobody came through with an offer of retrofittable links for 1.3, does that mean they don't exist? I still want 'em if someone has 'em(hint, hint).
esker@abaa.uucp (Lawrence Esker) (10/06/89)
In article <15071@netnews.upenn.edu> ranjit@grad1.cis.upenn.edu.UUCP (Ranjit Bhatnagar) writes: >So, Commodore, you're gonna put AREXX in 1.4, eh? Soon the place >will be crawling with scripts, and some of them will be simple >viruses or booby traps. That was one of the objections that I >brought up to my idea of symbolic links to REXX scripts. > >Therefore I strongly suggest that you implement a SECURE mode for >AREXX, in which, for any given script, > -ranjit Let me guess, you live on a deserted island with just your Amiga. Even there you built a brick and steel home with triple deadbolts on every door and window. You have guard dogs and alligator filled moats. Did I leave anything out. After all, there are thievs and murderers in this world. ;-) I don't mean to come across as attacking your post, but lets not restrict the freedom of the normal law abiding Amiga users to to help protect them from viruses. First of all, for any protection device implemented, someone can develop a virus of trojan horse that slips by. Second, protecting our computers from viruses is ultimately ones own responsibility. Just like protecting ones home, family, and persons from the criminal element. But, said protection can only go so far before it starts to look rediculuos and we must just say "What the f***, I just hope it doesn't happen to me." -- ---------- Lawrence W. Esker ---------- Modern Amish: Thou shalt not need any computer that is not IBM compatible. UseNet Path: __!mailrus!sharkey!itivax!abaa!esker == esker@abaa.UUCP
Benton_J_Elkins@cup.portal.com (10/08/89)
The ARexx manual chapter 7 Tracing & Interrupts page 73 provides for command inhibition by use of a TRACE ! which will allow testing of programs that erase files of format disks by inhibiting sending the command to the external host. Any one who doesn't test code dl'ed from a suspect source doesn't really care too much about the possibility of virii.
peter@sugar.hackercorp.com (Peter da Silva) (10/08/89)
In article <22864@cup.portal.com> Benton_J_Elkins@cup.portal.com writes: >Any one who doesn't test code dl'ed from a suspect source doesn't >really care too much about the possibility of virii. You're right, I don't care too much about the possibility of viruses. And I really doubt that anyone would bother doing a virus in AREXX. A Trojan horse program, maybe. But it'd still be more "fun" to put that sort of thing in a binary that can't be defused with a text editor! Bad guys are really much more likely to stick bogus code in binary-only distributions simply because it's so much harder to find. -- Peter "Have you hugged your wolf today" da Silva `-_-' ...texbell!sugar!peter, or peter@sugar.hackercorp.com 'U` ``Back off dude! I'm a topologist!'' -- Andrew Molitor <amolitor@eagle.wesleyan.edu>