5

The command lsblk returns the following output that lists 4 partitions.

sda      8:0    0 931.5G  0 disk 
├─sda1   8:1    0     8M  0 part 
├─sda2   8:2    0    40G  0 part /
├─sda3   8:3    0 883.8G  0 part /home
└─sda4   8:4    0   7.7G  0 part [SWAP]

When executing one or more of the following commands, is the necessary to delete the partitions prior?

If no, why and if yes, why?

If partitions are not deleted prior to the commands below being run, what is the risk of data remanence?

When executing one or more of the commands below, the partitions are not deleted. 

dd if=/dev/urandom of=/dev/sda bs=2MB conv=fsync
hdparm --user-master u --security-erase password /dev/sda
pv /dev/urandom > /dev/sda
Motivated
  • 1,493
  • 1
  • 14
  • 25
  • 1
    Are you sure the partitions aren't deleted? How did you check? Maybe take a look at `partprobe`? – AndrolGenhald Dec 26 '18 at 20:21
  • According to [this answer](https://superuser.com/a/1370585/490703) you should long-format the drive anyway. And that will remove any partitions anyway AFAIK. – User42 Dec 27 '18 at 12:34

2 Answers2

4

What you are seeing is a cached view of the previous partitions.

If they appear to persist even after a wipe, this is a result of the kernel caching the last known partition table in memory. It does this because it does not expect the layout to change at runtime, so rather than re-read the table each time the partition layout is queried, it reads it once at boot. If you want to force it to re-read the partition table, you can run a command like partprobe, reconnect the drive, or reboot.

The partitioning information is contained in the partition table, which is a small (64 bytes) section of the drive that specifies the location, type, and length of each partition. MBR partitions keep this table at the very beginning of the drive. GPT partitions keep an additional backup at the end of the drive and add support for more features. When you overwrite an entire block device, the partition table is also wiped.

As another answer mentions, the partition layout itself is unimportant and contains no sensitive data. They contain essentially nothing other than the bare minimum of information required to split a disk up into multiple partitions. You can see exactly what is stored for both MBR and GPT tables:

forest
  • 64,616
  • 20
  • 206
  • 257
2

As far as data security is concerned, the partitions are almost meaningless. If you're trying to prevent forensics from reading your data, then it won't matter. If you've run a proper multi-pass shredder over the data, then the partitions will only matter if you named them something telling.

Addendum: I've obviously hit someone's sore spot by suggesting a multi-pass shredder, so I'll be more specific. A single pass of random data will prevent the drive itself from reading the overwritten data. Unless you're hiding data that's worth five figures or someone's life, you're good stopping there.

There are enlightened papers out there that state that a single pass of random values will make reading each byte slightly better than a coin-flip, but those papers are currently behind pay walls, so I cannot make a statement regarding the reliability of their methodology.

For older drives, the lack of precision of the mechanism can result in a single pass leaving traces that expensive forensics can still read. I suggest whacking longitudinally with a sledge hammer and baking at 350 degrees until brown.

Robert Rapplean
  • 182
  • 3
  • And to @robert's comment on proper multi-pass, a simple /dev/urandom is NOT a proper multi-pass and many like myself would argue /dev/urandom is not terribly secure for your stated needs as it will NOT lock on entropy depletion hence there is a chance a forensics look post wipe could still retrieve DATA from the partitions themselves. – linuxdev2013 Dec 27 '18 at 00:18
  • 6
    @linuxdev2013 That's a myth. A single zero or one pass is likely sufficient, and `/dev/urandom` is certainly good enough. "Entropy depletion" from `/dev/urandom` [is a myth](https://www.2uo.de/myths-about-urandom/), the only real concern is lack of entropy on startup. And good luck wiping it with `/dev/random` unless you have a hardware random number generator. – AndrolGenhald Dec 27 '18 at 00:39
  • -1 because doing multi-pass is completely useless. You do **not** need to wipe multiple times. – forest Dec 27 '18 at 02:38
  • 1
    Your edit is incorrect as well. There are old, incorrect, retracted papers trying to identify data remanence. However, the reality is that a single overwrite on any modern, high-density drive is effectively equivalent to a 10000x overwrite. Think about it: Even wiped data on old audio tapes from watergate can't be recovered... – forest Dec 28 '18 at 02:53
  • @forest - How does a single overwrite affect older devices? – Motivated Dec 28 '18 at 07:37
  • @Motivated For _extremely_ old devices like MFT (back when hard drive capacities were measured in megabytes and the physical geometry of the drive was relevant), it's possible that _certain_ methods of overwrite might not be ideal. But even then it's highly theoretical. – forest Dec 28 '18 at 07:39
  • @forest - Can these be identified in any particular manner? If yes, it would be helpful to include this in the answer for future reference? – Motivated Dec 28 '18 at 07:41
  • 1
    @Motivated The drives are too old to be relevant. This was long before ATA Secure Erase was a thing. I think there are other answers here which already explain overwriting ancient MFM and RLL drives, though. – forest Dec 28 '18 at 07:44
  • @forest, do you have a reference to a publicly available research paper (preferably with results reproduced by a third party) that describes these findings? We all recognize the problem with accepting security precautions based on old, discredited research, but this doesn't mean we should discard security precautions based on someone's energetic insistence. Without such a thing, "I cannot make a statement" is absolutely the correct answer. – Robert Rapplean Dec 28 '18 at 18:37
  • @RobertRapplean As I mentioned in my previous comment, there are other answers here which do link to such papers. I do not have a list of them on me right now. – forest Dec 29 '18 at 04:47