Most modern Linux file systems support extended attributes. +s is secure deletion which ensures (at least intends) that the data in a file is overwritten with zeros when the file is deleted. Some file systems, NFS for example, do not yet support this feature, but they produce errors if you try to apply the attribute to their files or directories.

It has just come to my attention that certain underlying mechanisms, such as RAID controllers, SAN appliances or mechanical drives with SSD caches, might give a false sense of security by caching writes and possibly writing to different sectors without the logical file system having any visibility into the relocation.

  1. Is this concern real? Are there real world devices that create this vulnerability?
  2. Assuming such devices exist, do they perform in this manner all the time, or is it a statistical event that occurs occasionally, or is it a fluke that is only seen under special circumstances?
  • If you read the man page of chattr, it includes this: "The c', 's', and u' attributes are not honored by the ext2 and ext3 filesystems as implemented in the current mainline Linux kernels." Do you have any reference that says that chattr is honored in ext4, or any other filesystems? I don't recall this as a feature, but I could be wrong. Oct 27 '15 at 20:23
  • Yes, this concern is real but IMHO one should never rely on this feature to begin with, in basically all cases full encryption is the better way to go. I guess this feature would only be reliable if it was part of some more low-level protocol (like ATA) and hardware would honour it, but since there is encryption this is really not worth it.
    – phk
    Oct 28 '15 at 0:49
  • @SteveSether It is not honored by ext4.
    – forest
    Mar 29 '18 at 5:55

That is correct.

There is no guarantee that the setting of the attribute will cause the complete zeroing of all bytes in all relinquished sectors for all kernel-driver-firmware-hardware combinations. There is also no guarantee that the cases where it is not guaranteed will be reported to the terminal when the attribute is set.

The +s attribute is a reasonably good idea that may or may not eventually see universal or near universal coverage.

Note that on a correctly configured system, only root has access to the raw device to acquire intact or partially intact sectors that may contain fragments of deleted files. How much of a concern physical access to the disk or breach of root access is for your particular system plays into the decision making regarding security of these sectors.

For highly critical data where people or organizations may pay for advanced and continuous attack, the use of encryption within the context of a proven effective security protocol is preferable to than relying on chains and layers of software to cooperate to zero all relinquished sectors.

Statistical results from an adequate sample size would be required to answer your second question. I doubt if an authoritative answer will emerge, simply because it would require a large investment of both time and money to produce the raw data to analyze.

  • 1
    Additionally, with the advent of copy-on-write behavior on various levels (including the file system: ZFS, Btrfs; and physical storage: SSDs doing wear leveling, SSHDs doing caching), even if software attempts to overwrite everything, there could very easily be remnants left elsewhere on disk. As a consequence, a flag like chattr +s should be considered a request, not a guarantee.
    – user
    Jan 30 '17 at 6:58
  • @MichaelKjörling, I agree. Jan 30 '17 at 7:16

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.