Page 2 of 2 FirstFirst 12
Results 11 to 19 of 19

Thread: Secure-delete (sfill) duration?

  1. #11
    Join Date
    Feb 2008
    Beans
    85

    Re: Secure-delete (sfill) duration?

    after completely overwrite your data once it gets super difficult to recover any data.. sfill -l does two times and should be alright. The 38x overwriting thing is a myth.

    [...]The study concludes that after a single overwrite of hard drive data, the likelihood of being able to reconstruct a single byte is 0.97 percent. The odds of recovering multiple sequential bytes of data (such as a password or document) are significantly less and would require exact knowledge of where on the hard drive the sensitive data is located.

    http://www.springerlink.com/content/408263ql11460147/



    --

    another thing, "sfill /" will erase free disk space on every mounted device, right?

    i got like a lot of drives and partitions, my home is on sdb2 and so on and need to be sure that it will work? thx

  2. #12
    Join Date
    Dec 2004
    Location
    Lisbon, Portugal
    Beans
    79
    Distro
    Kubuntu

    Re: Secure-delete (sfill) duration?

    Quote Originally Posted by desmane View Post
    after completely overwrite your data once it gets super difficult to recover any data.. sfill -l does two times and should be alright. The 38x overwriting thing is a myth.
    Yup



    Quote Originally Posted by desmane View Post
    another thing, "sfill /" will erase free disk space on every mounted device, right?

    i got like a lot of drives and partitions, my home is on sdb2 and so on and need to be sure that it will work? thx
    I assume it only works on the / partition. You'd have to run it on a directory belonging to each partition you want to wipe. Since sfill works by creating a file and writing data in it, it will fill the current partition, just like it would happen when you create any file in any partition that won't fill the space of your other partitions.

    In Windows each partition has a logical drive associated with it. In unix based OSs you can associate a file system directory to a partition, making it easier to organize your files and making it more seamless than using different logical drives (you can mount a partition under your home folder just for your photos or videos, for example).

    As an example, using zfs (or one of the new file systems coming to Linux that I haven't yet read about their features) you can add all your drives to a pool of disk space and partition that pool as needed. The kernel will manage the disk space to those partitions regarding some rules but in a transparent way to the user. In this example, using sfill on one of the virtual partitions, if it was configured to be able to allocate 100% available disk space, you'd fill all the disks in the pool seamlessly. That also makes it easier to manage disk space among partitions, and I believe it also supports mirroring or at least some kind of way to support hard drive failures, but I don't know much about it.

    Cheers!
    Last edited by bsantos; July 11th, 2009 at 01:29 PM.

  3. #13
    Join Date
    Feb 2008
    Beans
    85

    Re: Secure-delete (sfill) duration?

    I assume it only works on the / partition. You'd have to run it on a directory belonging to [...] won't fill the space of your other partitions.
    Well, that makes sense! I'll do sfill for any individual partition then. It's quite fast. Thanks for your explanation.

    zfs sounds a bit like a software raid.. sounds great. nice feature. but. well. no

  4. #14
    Join Date
    Dec 2004
    Location
    Lisbon, Portugal
    Beans
    79
    Distro
    Kubuntu

    Re: Secure-delete (sfill) duration?

    Quote Originally Posted by desmane View Post
    Well, that makes sense! I'll do sfill for any individual partition then. It's quite fast. Thanks for your explanation.

    zfs sounds a bit like a software raid.. sounds great. nice feature. but. well. no
    No problem!

    zfs is much more than that. It's a file system that works like an abstraction layer above disks. I think you can attach disks outside your machine (NAS and disk arrays using other technologies) to that pool and everything, It has performance monitoring and much more than I know about. I saw a lecture from a SUN developer some years ago about it and it is pretty cool. It must do much more by now and in a more stable way. Too bad it isn't available on Linux IIRC due too licensing or patent issues.

    Cheers!

  5. #15
    Join Date
    Nov 2007
    Location
    Houston/LA/Albuquerque
    Beans
    58
    Distro
    Ubuntu 10.04 Lucid Lynx

    Smile Re: Secure-delete (sfill) duration?

    Hey there bsantos!

    Thanks for the tip buddy.

    Can I stop the process after about 7 runs with the "killall sfill" command and still maintain the integrity of that 7-wipe process?

    Sorry.....I'm a Noob in regards to Secure-Delete sfill. Never used it before.....but I glad we have such nice programs for Ubuntu.

    Tank

  6. #16
    Join Date
    Apr 2009
    Beans
    Hidden!
    Distro
    Ubuntu 9.10 Karmic Koala

    Re: Secure-delete (sfill) duration?

    You can stop sfill with Ctrl+C and it will make a clean exit.

  7. #17
    Join Date
    Dec 2004
    Location
    Lisbon, Portugal
    Beans
    79
    Distro
    Kubuntu

    Re: Secure-delete (sfill) duration?

    Yes, using Ctrl-C is preferable, but killall sends a SIGTERM signal by default and sfill does a clean exit when receiving it. So either way will work.

  8. #18
    Join Date
    Jan 2010
    Location
    New York
    Beans
    1

    Re: Secure-delete (sfill) duration?

    Quote Originally Posted by bsantos View Post
    Yup, it dereferences the file it created for cleanup.

    When the process is all done you also get the disk space back, it just takes too long.
    That is correct, `killall' is the way to go. Here's my output:

    # sfill -v -z /
    Using /dev/urandom for random input.
    Wipe mode is secure (38 special passes)
    Wiping now ...
    Creating /oooooooo.ooo ... *
    [on another root console: # killall sfill]
    Terminated by signal. Clean exit.
    #

    After a few minutes, the huge file previously created will be all dereferenced.

  9. #19
    Join Date
    Nov 2010
    Beans
    13

    Re: Secure-delete (sfill) duration?

    Obviously, "sfill" creates a file named "oooooooo.ooo" and writes loads of "ff ff ff ..." bytes into it (you can verify this by typing "tail oooooooo.ooo | hexdump" into the shell, while "sfill" is running). However, it takes several hours of time for writing a few hundred megabytes to the disk (you can monitor the size of the "oooooooo.ooo" file using "ls -l" on the shell).

    When I do something like "dd if=/dev/urandom of=somefile" on the console, it writes about 10 gigabytes per hour on average. When the partition is empty, it starts out with about 20 gigabytes per second, but gets slower as space on the file system gets scarce and the last few gigabytes take like forever. This is on an encrypted partition, so the system will actually have to encrypt the random numbers "dd" is writing before they actually reach the disk. The "dd" method is hundreds of times faster than "sfill", but produces significantly lower hard drive activity (when using "dd", the hard drive is hardly ever working, while it will be very busy while "sfill" is working).

    Now the question is: What's so special about "sfill" and why is it that slow? Why would one need such a utility if every GNU/Linux system comes with "dd"? Is the "dd"ing method less secure than a single pass of "sfill"? If so, why? Where can I get the source code of "sfill", if I want to investigate this further?

    Thanks in advance for your information.

    EDIT: If you are using the options "oflag=dsync" and "bs=4M", your overwrite will be more secure (because of the "flag=dsync", which will cause the disk to cause an immediate write without buffering the data in a cache, so you can guarantee that data actually reaches the disk - I guess the use without dsync doesn't make it THAT much less secure since the write cache of the disk will usually be only a few KB or MB and data will eventually reach the disk, at least when the cache is full - and since it cannot hold very much data, it will usually become full very quick) and much faster (because of the "bs=4M", which will cause dd to write the data in 4 MB blocks rather than individual bytes). So now the dd method is much much faster than it already was. Where's the purpose in sfill and why is it rediculously slow?
    Last edited by no.human.being; November 25th, 2010 at 08:49 PM.

Page 2 of 2 FirstFirst 12

Tags for this Thread

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •