Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
Clean ext4 deleted file traces using 'chattr +s'[workaround]
View unanswered posts
View posts from last 24 hours

 
Reply to topic    Gentoo Forums Forum Index Networking & Security
View previous topic :: View next topic  
Author Message
CaptainBlood
Veteran
Veteran


Joined: 24 Jan 2010
Posts: 1953

PostPosted: Wed Oct 21, 2020 8:57 pm    Post subject: Clean ext4 deleted file traces using 'chattr +s'[workaround] Reply with quote

AFAIK, deleting a file doesn't erase, e.g. rewrite them, but only frees the blocks it uses in the file system structure.
Seems like the name of the file can survive as well.

I read somewhere command
Code:
chattr +s
can help solving that out.
I have no experience with this command.

Maybe someone has some experience to share that matter, before I start messing things?:P

Thks 4 ur attention, interest & support.


Last edited by CaptainBlood on Thu Oct 22, 2020 1:37 pm; edited 4 times in total
Back to top
View user's profile Send private message
Etal
Veteran
Veteran


Joined: 15 Jul 2005
Posts: 1826

PostPosted: Wed Oct 21, 2020 9:10 pm    Post subject: Reply with quote

ext4 doesn't support it.

man chattr:
BUGS AND LIMITATIONS
       The  'c',  's',   and 'u' attributes are not honored by the ext2, ext3,
       and ext4 filesystems as implemented in the current mainline Linux  ker‐
       nels.   Setting  'a'  and 'i' attributes will not affect the ability to
       write to already existing file descriptors.
man ext4:
FILE ATTRIBUTES
       The ext2, ext3, and ext4 filesystems support setting the following file
       attributes on Linux systems using the chattr(1) utility:

       a - append only

       A - no atime updates

       d - no dump

       D - synchronous directory updates

       i - immutable

       S - synchronous updates

       u - undeletable

       In addition, the ext3 and ext4 filesystems support the following flag:

       j - data journaling

       Finally, the ext4 filesystem also supports the following flag:

       e - extents format

       For  descriptions  of  these  attribute  flags,  please  refer  to  the
       chattr(1) man page.
Back to top
View user's profile Send private message
CaptainBlood
Veteran
Veteran


Joined: 24 Jan 2010
Posts: 1953

PostPosted: Wed Oct 21, 2020 9:18 pm    Post subject: Reply with quote

:oops:
Serious breach in ext4 security imho.
That a real point to consider by the time I decide to go encrypted.

Thks 4 ur attention, interest & support.
Back to top
View user's profile Send private message
Goverp
l33t
l33t


Joined: 07 Mar 2007
Posts: 922

PostPosted: Thu Oct 22, 2020 10:25 am    Post subject: Reply with quote

If you want to erase the file contents and any trace of its name, use "shred -un1" instead of rm. Doesn't help in programs that have hard-coded "rm" or equivalent, of course.
_________________
Greybeard
Back to top
View user's profile Send private message
CaptainBlood
Veteran
Veteran


Joined: 24 Jan 2010
Posts: 1953

PostPosted: Thu Oct 22, 2020 10:37 am    Post subject: Reply with quote

Goverp wrote:
If you want to erase the file contents and any trace of its name, use "shred -un1" instead of rm. Doesn't help in programs that have hard-coded "rm" or equivalent, of course.
Thks 4 ur attention, interest & support.
Back to top
View user's profile Send private message
Etal
Veteran
Veteran


Joined: 15 Jul 2005
Posts: 1826

PostPosted: Thu Oct 22, 2020 2:32 pm    Post subject: Reply with quote

info shred:
   *Please note* that ‘shred’ relies on a crucial assumption: that the
file system and hardware overwrite data in place.  Although this is
common and is the traditional way to do things, but many modern file
system designs do not satisfy this assumption.  Exceptions include:

   • Log-structured or journaled file systems, such as ext3/ext4 (in
     ‘data=journal’ mode), Btrfs, NTFS, ReiserFS, XFS, ZFS, file systems
     supplied with AIX and Solaris, etc., when they are configured to
     journal data.

   • File systems that write redundant data and carry on even if some
     writes fail, such as RAID-based file systems.

   • File systems that make snapshots, such as Network Appliance’s NFS
     server.

   • File systems that cache in temporary locations, such as NFS version
     3 clients.

   • Compressed file systems.

   For ext3 and ext4 file systems, ‘shred’ is less effective when the
file system is in ‘data=journal’ mode, which journals file data in
addition to just metadata.  In both the ‘data=ordered’ (default) and
‘data=writeback’ modes, ‘shred’ works as usual.  The ext3/ext4
journaling modes can be changed by adding the ‘data=something’ option to
the mount options for a particular file system in the ‘/etc/fstab’ file,
as documented in the ‘mount’ man page (‘man mount’).  Alternatively, if
you know how large the journal is, you can shred the journal by
shredding enough file data so that the journal cycles around and fills
up with shredded data.

...
Back to top
View user's profile Send private message
NeddySeagoon
Administrator
Administrator


Joined: 05 Jul 2003
Posts: 46727
Location: 56N 3W

PostPosted: Thu Oct 22, 2020 3:32 pm    Post subject: Reply with quote

and ssds are a whole new bag of worms since by design, they cannot support overwrite in place.
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.
Back to top
View user's profile Send private message
figueroa
l33t
l33t


Joined: 14 Aug 2005
Posts: 867
Location: Lower right-hand corner USA

PostPosted: Fri Oct 23, 2020 3:14 am    Post subject: Reply with quote

CaptainBlood wrote:
Serious breach in ext4 security imho.
That a real point to consider by the time I decide to go encrypted.

Not really. It's up to users to understand how their file systems work. If this worries you, you also need to be concerned about every backup copy.
_________________
Andy Figueroa
andy@andyfigueroa.net Working with Unix since 1983.
Back to top
View user's profile Send private message
CaptainBlood
Veteran
Veteran


Joined: 24 Jan 2010
Posts: 1953

PostPosted: Fri Oct 23, 2020 9:27 am    Post subject: Reply with quote

Actually, I meant privacy, not security.
Thks 4 ur attention, interest & support.
_________________
Poor testing hurts everyone... climate included :)
Back to top
View user's profile Send private message
NeddySeagoon
Administrator
Administrator


Joined: 05 Jul 2003
Posts: 46727
Location: 56N 3W

PostPosted: Fri Oct 23, 2020 10:09 am    Post subject: Reply with quote

CaptainBlood,

Privacy is in two main areas. At rest, covered by LUKS. That encrypts whole block devices' and live, When the data is decrypted, it down to access control.

Only root can poke about in free space unless normal users have some very odd group memberships.
You have bigger problems that root looking at deleted files if you have unknown users on your system with root access.

Privacy and Security are related. Providing either starts with a threat assessment, then implementing countermeasures all the way through the system life cycle.
A room with good physical security, a cabinet with good phyiscal security ... bolted to a good solid cement floor so it can't be taken away ...

The point is, its the 'layers of an onion' approach, not ad hoc, this is a good thing.

The SSD point is that FLASH memory has two states. Written and erased, the concept of overwriting in place does not exist. the SSD firmware won't let it happen.
Privacy and Security considerations go right back to selecting hardware.
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.
Back to top
View user's profile Send private message
Anon-E-moose
Advocate
Advocate


Joined: 23 May 2008
Posts: 4998
Location: Dallas area

PostPosted: Fri Oct 23, 2020 10:41 am    Post subject: Reply with quote

If you could make an ssd overwrite in place, you'd basically disable wear-leveling, and would find lots of problems related to that.
_________________
PRIME x570-pro, 3700x, RX 550 - 5.8 zen kernel
Acer E5-575 (laptop), i3-7100u - i965 - 5.5 zen kernel
---both---
gcc 9.3.0, profile 17.1 (no-pie & modified) amd64-no-multilib, eudev, openrc, openbox, palemoon
Back to top
View user's profile Send private message
NeddySeagoon
Administrator
Administrator


Joined: 05 Jul 2003
Posts: 46727
Location: 56N 3W

PostPosted: Fri Oct 23, 2020 11:02 am    Post subject: Reply with quote

Anon-E-moose,

SSDs use an analogue storage mechanism for 1, 2, 3, or 4 bits per cell. The stored voltage can only be changed one way, hence the need for an erase cycle.
Once the erase is done, the data is gone. Attempted overwrites without the erase cycle would only lead to write errors where the stored charge needed to be changed the wrong way.
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Networking & Security All times are GMT
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum