home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / comp / org / eff / talk / 8406 < prev    next >
Encoding:
Text File  |  1993-01-07  |  4.7 KB  |  109 lines
  1. Newsgroups: comp.org.eff.talk
  2. Path: sparky!uunet!zaphod.mps.ohio-state.edu!swrinde!gatech!emory!nastar!phardie
  3. From: phardie@nastar.uucp (Pete Hardie)
  4. Subject: Re: Beneficial Virus?
  5. Message-ID: <1993Jan7.152339.25886@nastar.uucp>
  6. Organization: Digital Transmission Systems, Duluth, GA.
  7. References: <C0EJAu.HuI@panix.com> <1993Jan6.152243.22472@nastar.uucp> <C0GIA7.4Fz@panix.com>
  8. Date: Thu, 7 Jan 1993 15:23:39 GMT
  9. Lines: 98
  10.  
  11. In article <C0GIA7.4Fz@panix.com> rpowers@panix.com (Richard Powers) writes:
  12. >>>In <1993Jan5.153018.18935@nastar.uucp> phardie@nastar.uucp (Pete Hardie) writes:
  13. >
  14. >>Consider a multi-user system where another user installed the virus, and I
  15. >>want to transfer a file to my home system, and need to transfer the marker
  16. >>file, but I do not know which file it is.
  17. >
  18. >A multi-user system can be treated exactly like several single-user
  19. >systems.  If you want to transfer a file (or make available to other
  20. >users) to another user on the same _or_ to a different system you can:
  21. >
  22. >(1) remove the virus first
  23. >    or
  24. >(2) also transfer (make available) the permission file.
  25.  
  26. If I do not know the virus is in place on the multi0user system (and if it
  27. deserves the name 'virus', I shouldn't know unless I really poke around), I
  28. cannot be aware of the necessity of transferring the marker file, and I also
  29. do not know how to remove the virus before transferring the file.
  30.  
  31. >If you're talking about a multi-user system where a super-user has
  32. >installed the virus (ie: the virus has permission to spread to _any_
  33. >users files), then I would certainly hope that the super-user would
  34. >have informed all other users that this is the case.  I don't think it
  35. >would be ethical otherwise, since the person would be changing people's
  36. >files without consent.
  37.  
  38. Not necessarily.  Some systems operate user accounts under suffrance - you
  39. get only what the admins allow.  Others allow privacy, but do not guarantee
  40. anything else.  The raw format of the data is not usually guaranteed, like
  41. the position of files on a disk is not guaranteed.
  42.  
  43. An admin who installed a device driver that compressed all files would
  44. be doing the same thing, in essence, and would not be likely to tell the
  45. users, except as bragging about the regained disk space :-)
  46.  
  47. >This really was discussed already.  Upon failing to find the marker
  48. >file (which may contain some of the code the virus uses to
  49. >compress/spread), it could do several things:
  50.  
  51. I missed this in the discussion.  But it does bring up a point for later,
  52. about the definition of virus.
  53.  
  54. >(1) Remove itself.  The BCV would decompress the file and then save it
  55. >back to disk in its original state.  Uncompressed and w/out virus
  56. >code.
  57.  
  58. This would be the only ethical option for a 'beneficial virus', IMHO.
  59.  
  60. >(2) Decompress as usual.  It would get the file running as usual, and
  61. >then just quit.  Letting the host file continue.  *** I _don't_ think
  62. >this is the way it should be implemented. ***
  63.  
  64. Ok, so noted.
  65.  
  66. >(3) Notify the user.  Tell the user it exists.  This could (should) be
  67. >combined with other methods.
  68.  
  69. I would say *must* be combined with other methods.
  70.  
  71. >(4) Create a marker file.  Give itself permission to spread.  *** I do
  72. >_not_ think this should be implemented by itself.  It defeats the
  73. >pupose of the marker file.  ***
  74.  
  75. This would make the virus unremovable.  Major unethical for a beneficial
  76. virus.
  77.  
  78. >(5) Ask the user.  Give the user a menu of choices for what it should
  79. >do.  This is the only context I see (4) being appropriate.  (3) is, of
  80. >course, not applicable.   ***  I prefer this method over all.  If (1)
  81. >were implemented and the marker file was lost w/out my knowledge, I
  82. >wouldn't want my files to mysteriously decompress. ***
  83.  
  84. This starts to make the program less of a virus, since it becomes more of
  85. a system utility.  It also makes it possible for a user to infect a system
  86. without the owner's knowledge.
  87.  
  88. >Now, I also mentioned having a list in the permission file of files
  89. >the BCV was not allowed to infect.  You could just add the name of the
  90. >file you wanted to transfer to this list and the BCV would use method
  91. >(1) above.
  92. >
  93. >I would probably also have one or more BCV maintenance tools.  To
  94. >check up on how it is performing, to create/update/change the
  95. >permission file, and to remove the BCV from specific files.
  96.  
  97. This, along with the marker file having the compression code, makes this into
  98. something other than a virus, IMHO.  It is not self-contained anymore.  It
  99. becomes a disk compression utility that could be installed as a hook in the
  100. drive access instead of a free-floating infectious program.
  101.  
  102.  
  103.  
  104. -- 
  105. Pete Hardie:  phardie@nastar  (voice) (404) 497-0101
  106. Digital Transmission Systems, Inc., Duluth GA
  107. Member, DTS Dart Team           |  cat * | egrep -v "signature virus|infection" 
  108. Position:  Goalie               |
  109.