home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / comp / org / eff / talk / 8610 < prev    next >
Encoding:
Text File  |  1993-01-11  |  5.2 KB  |  119 lines
  1. Newsgroups: comp.org.eff.talk
  2. Path: sparky!uunet!psinntp!panix!rpowers
  3. From: rpowers@panix.com (Richard Powers)
  4. Subject: Re: Beneficial Virus?
  5. Message-ID: <C0psLo.KLx@panix.com>
  6. Organization: PANIX Public Access Unix, NYC
  7. References: <C0IDMu.By5@panix.com> <1993Jan8.151721.29014@nastar.uucp> <C0Ky6z.HsB@panix.com> <1993Jan11.163720.6604@nastar.uucp>
  8. Date: Tue, 12 Jan 1993 00:12:59 GMT
  9. Lines: 108
  10.  
  11. In <1993Jan11.163720.6604@nastar.uucp> phardie@nastar.uucp (Pete Hardie) writes:
  12. >In article <C0Ky6z.HsB@panix.com> rpowers@panix.com (Richard Powers) writes:
  13.  
  14. >Certainly, if the sysadmin was the installer.  But if Mary User was
  15. >the installer, and Joe Public gets his files compressed, and can't uncompress
  16. >them, or is concerned when the "Warning:  VIRUSOK.MK not found.  Install?"
  17. >message appears on his home machine when a copied executable is run, how
  18. >does the info get to Joe?
  19.  
  20. The BCV would need to use _some_ method to search for files to infect.
  21. It would be trivial to restrict this to searching only what belongs to
  22. the user who placed it on the multi-user system.
  23.  
  24. I don't really see the BCV as being usefull to an individual user on a
  25. multi-user system.  Users usually don't own their own executables, for
  26. one thing.
  27.  
  28. >>You can't have it both ways!  If it *IS* *totally* transparent, (AS
  29. >>TRANSPARENT AS A DEVICE DRIVER), then there is no reason for the users
  30. >>to know of its existence.  If there _are_, on the other hand, things
  31. >>the user should be aware of, then the sysadmin should make the user
  32. >>aware!  
  33.  
  34. >Yes, *should*;  not *WILL*.
  35.  
  36. >Since the BCV only takes effect on execution, I can copy a file that is
  37. >compressed to another machine.  A device driver would uncompress during
  38. >the copy off the hard drive, and not on the write to floppy (or perhaps it
  39. >would re-compress....)
  40.  
  41. >Again, if we are talking about use on one system, the BCV is not a problem
  42. >for the installer, and almost never a problem for anyone else.  
  43.  
  44. Exactly!  These *are* the circumstances which I had in mind when
  45. proposing this.
  46.  
  47. >Once we are
  48. >discussing 2+ machines, it *can become* a problem for the other users, since
  49. >they suddenly find a section of code *that they did not write* residing in
  50. >their executables, and asking them questions about a file *they may know
  51. >nothing about*.
  52.  
  53. But I contend that all that is necessary is for the BCV to be used
  54. responsibly.  The design should make it easier for this to be so (the
  55. marker file, etc.), and minimize any problems that could occur.
  56.  
  57. >>>How will I know, if I arrive after the installation
  58. >>>of the BCV, that it is in place?
  59.  
  60. >>See above.
  61.  
  62. >I'm not clear on this.  If the marker file is present, and I do not have
  63. >any executables from before, how do I know?  
  64.  
  65. You are talking about a multi-user system in this case, yes?  "See
  66. above."  Refers to my discussion of the sysadmins responsibility to
  67. inform his/her users of the presence of the BCV.
  68.  
  69. >>>No.  I meant that Joe User could install the virus and marker file on the
  70. >>>multi-user system run by Mary Sysadmin.
  71. >>
  72. >>But so what if he did?  If Joe User can write to anything other than
  73. >>his own files, then Mary Sysadmin has more problems than someone
  74. >>trying to compress executable files!  If he can't, then what is the
  75. >>problem? 
  76.  
  77. >You are assuming that every user can (and should) have all his/her files
  78. >locked up tighter than a drum, on a multi-user system.  The first is possible,
  79. >but the second is debatable.
  80.  
  81. But the BCV could (and should) be made to restrict itself to the
  82. owning users files.
  83.  
  84. >>>That's the problem with a beneficial virus - we don't all agree that
  85. >>>X action is always beneficial.
  86. >>
  87. >>Aaaaargh!  It is irrelevant!  The only characteristic which a virus
  88. >>exhibits that makes it different from other programs is
  89. >>self-replication.  If everything else is equal, why should this factor
  90. >>make the program suddenly evil?
  91.  
  92. >You miss my point.  That the BCV is a virus (or could be one), is not the
  93. >issue - the issue is "Is it *beneficial*?"  Since it is a virus, is will
  94. >infect other files (and systems) without the owner's knowledge, and they
  95. >may not agree that the compression is a benefit.  They might consider it
  96. >a harmful act.
  97.  
  98. No, I understand what you are saying.  I still don't think _you_ get
  99. my point.  Just because the program exhibits behavior that is right
  100. now exclusively(?) used by programs which exist only as a nuisance (at
  101. best), or are actually dangerous, does not mean that this should
  102. reflect on _every_ program which has _some_ similar characteristics.
  103. The particular methods any program uses can be debated for and
  104. against.  (Is it a bug or is it a feature?)  What I'm saying is that
  105. the characteristics which we say typify(sp?) as virus charecteristics
  106. do _not_ prohibit a program from being beneficial.
  107.  
  108. >It is the assumption that you (or the virus writer) know better than I what
  109. >is beneficial to my system/files that is the problem.
  110.  
  111. I don't understand why you think anyone is assuming this.  This is no
  112. more the case with the virus writer (beneficial type) than with any
  113. other programmer whose programs are used on systems other than his
  114. own.
  115. -- 
  116. )                    )  I am more than this...  )               )
  117. ) rpowers@panix.com  )                          )   Apathy...   )
  118. )                    )      Continue...?        )               )
  119.