home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #20 / NN_1992_20.iso / spool / comp / unix / wizards / 3870 < prev    next >
Encoding:
Internet Message Format  |  1992-09-09  |  2.7 KB
  1. Path: sparky!uunet!usc!rpi!think.com!barmar
  2. From: barmar@think.com (Barry Margolin)
  3. Newsgroups: comp.unix.wizards
  4. Subject: Re: /bin/rm security issue(s)
  5. Date: 10 Sep 1992 05:25:43 GMT
  6. Organization: Thinking Machines Corporation, Cambridge MA, USA
  7. Lines: 44
  8. Message-ID: <18mm8nINNfmc@early-bird.think.com>
  9. References: <1992Sep10.015705.7210@morwyn.uucp>
  10. NNTP-Posting-Host: gandalf.think.com
  11.  
  12. In article <1992Sep10.015705.7210@morwyn.uucp> forrie@morwyn.uucp (Forrie Aldrich) writes:
  13. >However:  I'm concerned about being able really _eradicate_ a file,
  14. >for various reasons including security.
  15. >
  16. >Does anyone have a program that will do this?  A friend suggested that 
  17. >I get a program that will open the file and write 'zeros' or something
  18. >to the end of it and then close it. _Then_ /bin/rm the file.
  19.  
  20. I don't know whether Unix guarantees that writing to a file will overwrite
  21. the existing blocks rather than allocate new blocks and free the old ones.
  22. However, I believe most existing Unix implementations will do what you
  23. expect.
  24.  
  25. >I could see adding this 'feature' to /bin/rm or perhaps writing a
  26. >program called /bin/rrm (_really-remove_) to do this.  Hmmm... I wonder
  27. >how government contracts manage this issue...
  28.  
  29. This won't help in the case of files deleted in other ways, e.g. by mv(1),
  30. or by applications that call unlink(2).  Perhaps you should replace
  31. unlink(2) in libc with one that really eradicates (if you have dynamic
  32. libraries, this change will affect all dynamically-linked programs).
  33.  
  34. I don't think this is a problem for government contracts.  The Orange Book
  35. only requires that newly-created files not contain data from old files,
  36. which Unix implements.  Anyone who can access the raw disk is effectively
  37. bypassing the system security.  On Unix, if you can do this it generally
  38. means that you also have access to replace or patch /bin/rrm so that it
  39. doesn't really eradicate, either.  In general, I think that a contract that
  40. required this kind of security would probably not be met by Unix.  On the
  41. other hand, Multics deletes files similarly to Unix, and that wasn't an
  42. obstacle to getting a B2 rating.
  43.  
  44. The only government requirement for really eradicating data comes into play
  45. when disks or tapes are being thrown out.  If the media ever contained data
  46. above a particular security classification, it has to be thoroughly wiped;
  47. this generally involves writing lots of 1's, 0's, and random patterns over
  48. it several times, then degaussing it.  At some really high levels, you have
  49. to grind it up into a fine powder, and then incinerate it; but first you
  50. have to erase it as described above!
  51. -- 
  52. Barry Margolin
  53. System Manager, Thinking Machines Corp.
  54.  
  55. barmar@think.com          {uunet,harvard}!think!barmar
  56.