home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / comp / org / eff / talk / 8506 < prev    next >
Encoding:
Internet Message Format  |  1993-01-09  |  6.1 KB

  1. Path: sparky!uunet!haven.umd.edu!darwin.sura.net!gatech!concert!rutgers!cmcl2!panix!rpowers
  2. From: rpowers@panix.com (Richard Powers)
  3. Newsgroups: comp.org.eff.talk
  4. Subject: Re: Beneficial Virus?
  5. Message-ID: <C0Ky6z.HsB@panix.com>
  6. Date: 9 Jan 93 09:25:47 GMT
  7. References: <C0GIA7.4Fz@panix.com> <1993Jan7.152339.25886@nastar.uucp> <C0IDMu.By5@panix.com> <1993Jan8.151721.29014@nastar.uucp>
  8. Organization: PANIX Public Access Unix, NYC
  9. Lines: 128
  10.  
  11. (I'm going to split this follow-up into two messages, as I think there
  12. are two separate issues being discussed.)
  13.  
  14. In <1993Jan8.151721.29014@nastar.uucp> phardie@nastar.uucp (Pete Hardie) writes:
  15. >In article <C0IDMu.By5@panix.com> rpowers@panix.com (Richard Powers) writes:
  16. >>In <1993Jan7.152339.25886@nastar.uucp> phardie@nastar.uucp (Pete Hardie) writes:
  17. >>How would you not know it is in place?  You would have had to place it
  18. >>there yourself.  Or at very least placed the marker file.
  19.  
  20. ><sigh>
  21.  
  22. >It's a *multi-user* system.  Another user could have installed it.  I might
  23. >NOT be the owner.
  24.  
  25. Ok, I should have been a little clearer on this.  _Someone_ had to
  26. introduce the BCV to the multi-user system.  I am assuming that the
  27. user that does this only has write permissions for files s/he owns.
  28. The BCV will, of course, have the same privileges(sp?) as the owning
  29. user.  If this user wants to transfer an executable file to another
  30. user (or make it available to other users), then s/he should take the
  31. exact same precautions as would an owner of a single-user system who
  32. is transferring a file to a separate system without the BCV.
  33.  
  34. Is it clear how (IMO) a multi-user system does not have to be taken
  35. into account as a separate case?
  36.  
  37. >Does the sysadmin at your school/business always tell you when s/he installs
  38. >something new?  Swaps out one disk for another?  etc, etc.
  39.  
  40. You imply that a sysadmin would place a BCV on his system without
  41. informing his users.  Either there is no reason for him/her to inform
  42. his/her users, in which case; fine, no reason to worry.  Or else there
  43. is a reason for the sysadmin to inform her/his users.  In that case
  44. s/he should do so.  If the sysadmin fails to do so, it is the fault of
  45. the sysadmin, not something inherent in the BCV.
  46.  
  47. >If I am a user on a multi-user system, and the admin has installed this BCV
  48. >several years ago, I do not necessarily get *any* information about it or
  49. >its presence onthe system.
  50.  
  51. (IMO this should not happen.  But anyway...)  Either one of two things
  52. will occur.  (1) You never notice it is on the system.  It works fine,
  53. and you never had a reason to edit an executable, etc.  In this case,
  54. whats the difference?  (2) _Something_ that you didn't expect happens.
  55. You noticed _some_ type of effect of the presence of the BCV.  Here
  56. you ask a question of the sysadmin, and s/he says "Oh yeah.  Forgot to
  57. tell you about that.  Heres how it works...".
  58.  
  59. >>IMO _if_ the existence of the virus will have any impact on the users,
  60. >>the admin has an obligation to notify those users.  This is not the
  61. >>same as a device driver.  With a device driver the effects should be
  62. >>totally transparent to the user.  And again, if it is _not_
  63. >>transparent, then the users should know.
  64.  
  65. >From the descriptions of the BCV, if the marker file is present, it *IS*
  66. >totally transparent.
  67.  
  68. You can't have it both ways!  If it *IS* *totally* transparent, (AS
  69. TRANSPARENT AS A DEVICE DRIVER), then there is no reason for the users
  70. to know of its existence.  If there _are_, on the other hand, things
  71. the user should be aware of, then the sysadmin should make the user
  72. aware!  
  73.  
  74. >How will I know, if I arrive after the installation
  75. >of the BCV, that it is in place?
  76.  
  77. See above.
  78.  
  79. >>>>(1) Remove itself.  The BCV would decompress the file and then save it
  80.  
  81. >>>This would be the only ethical option for a 'beneficial virus', IMHO.
  82.  
  83. >>Not this method alone, IMHO.  If you have so much of your usable disk
  84. >>space compressed that not everything will fit uncompressed, then this
  85. >>method alone would be disastrous.
  86.  
  87. >If the marker file is gone, the re-compression code is gone, right?  Every
  88. >executable will be decompressed over time, leading to this very state.
  89.  
  90. No, wait a minute.  This would happen if method (1), and only method
  91. (1), was used when the BCV could not find the marker file.  That is
  92. why I argued against your "...only ethical option.." statement.
  93.  
  94. _If_ the compression code is only in the marker file, and _if_ you no
  95. longer have a backup or any other way of restoring the marker file,
  96. then, yes your files will decompress if you told them to.  (I
  97. advocated that the BCV ask the user what to do when the marker is not
  98. found.  The user in this case would _not_ tell _every_ BCV-bearing
  99. file to decompress until more/another storage media is found.)
  100.  
  101. [Deleted.  Replied to seperately.]
  102.  
  103. >>>It also makes it possible for a user to infect a system without the
  104. >>>owner's knowledge.
  105.  
  106. >>I assume you are referring to method (4)?  I covered that above.  Read
  107. >>the underlined again.
  108.  
  109. >No.  I meant that Joe User could install the virus and marker file on the
  110. >multi-user system run by Mary Sysadmin.
  111.  
  112. But so what if he did?  If Joe User can write to anything other than
  113. his own files, then Mary Sysadmin has more problems than someone
  114. trying to compress executable files!  If he can't, then what is the
  115. problem? 
  116.  
  117. >>The whole idea has involved from the original to deal with a lot of
  118. >>nitpicking problems.  The original context was a hypothetical concept
  119. >>to refute the idea that a beneficial virus is inherently _impossible_.
  120.  
  121. >Define beneficial.  Now get 100 people to agree with you.
  122.  
  123. >That's the problem with a beneficial virus - we don't all agree that
  124. >X action is always beneficial.
  125.  
  126. Aaaaargh!  It is irrelevant!  The only characteristic which a virus
  127. exhibits that makes it different from other programs is
  128. self-replication.  If everything else is equal, why should this factor
  129. make the program suddenly evil?
  130.  
  131. (I know you disagree that "virus"=="self-replicating program".  I find
  132. it hard to see your side on this.  Please read my post entitled "Virus
  133. Definition".) 
  134.  
  135. -- 
  136. )                    )  I am more than this...  )               )
  137. ) rpowers@panix.com  )                          )   Apathy...   )
  138. )                    )      Continue...?        )               )
  139.