Translate

Image of XSLT 2.0 and XPath 2.0 Programmer's Reference (Programmer to Programmer)
Image of Operating System Concepts
Image of Beginning Google Maps API 3
Image of Android Wireless Application Development

RHEL7 XFS Is A Step Backwards Forensically

Red Hat changed the default filesystem in Red Hat Enterprise Linux 7 (RHEL 7) to XFS. In RHEL 6, the default filesystem was EXT4. The rational for this change, according Denise Dumas, Director of Software Engineering for Red Hat was because “it is a better match for our enterprise customers”.

I agree with this position, which incidentally is the position SUSE have maintained for a long time, except that forensically it is somewhat of a step backwards.

You can examine a XFS file’s metadata using xfs_db but it is much easier to use the xfs_io utility. Just like xfs_db, xfs_io is an XFS filesystem debugging tool, but it’s focus is on supporting regular file I/O paths rather than the raw XFS volume itself.

# xfs_io
xfs_io> open /home/fpm/test
xfs_io> stat
fd.path = "/home/fpm/test"
fd.flags = non-sync,non-direct,read-write
stat.ino = 71265538
stat.type = regular file
stat.size = 13644
stat.blocks = 32
fsxattr.xflags = 0x80000000 [--------------]
fsxattr.projid = 0
fsxattr.extsize = 0
fsxattr.nextents = 1
fsxattr.naextents = 0
dioattr.mem = 0x200
dioattr.miniosz = 512
dioattr.maxiosz = 2147483136

xfs_io> statfs
fd.path = "/home/fpm/test"
statfs.f_bsize = 4096
statfs.f_blocks = 4587008
statfs.f_bavail = 3751604
statfs.f_files = 18358272
statfs.f_ffree = 18227530
geom.bsize = 4096
geom.agcount = 4
geom.agblocks = 1147392
geom.datablocks = 4589568
geom.rtblocks = 0
geom.rtextents = 0
geom.rtextsize = 1
geom.sunit = 0
geom.swidth = 0
counts.freedata = 3751604
counts.freertx = 0
counts.freeino = 202
counts.allocino = 130944

xfs_io> stat -v
fd.path = "/home/fpm/test"
fd.flags = non-sync,non-direct,read-write
stat.ino = 71265538
stat.type = regular file
stat.size = 13644
stat.blocks = 32
stat.atime = Fri Jun 13 19:03:06 2014
stat.mtime = Fri Jun 13 19:03:03 2014
stat.ctime = Fri Jun 13 19:03:03 2014
fsxattr.xflags = 0x80000000 []
fsxattr.projid = 0
fsxattr.extsize = 0
fsxattr.nextents = 1
fsxattr.naextents = 0
dioattr.mem = 0x200
dioattr.miniosz = 512
dioattr.maxiosz = 2147483136
xfs_io>quit
#


As you can see from the above xfs_io output, XFS only supports the three classical Unix filesystem timestamps for files, i.e. atime, mtime and atime. It does not support an immutable file creation timestamp like the EXT4, NTFS, ZFS or BTRFS filesystems do.

Here, for example, is the output from the stat utility on RHEL 6.4 for a file, helloworld, that is on an EXT4 filesystem:

# stat helloworld
  File: `helloworld'
  Size: 6470      	Blocks: 16         IO Block: 4096   regular file
Device: 803h/2051d	Inode: 396942      Links: 1
Access: (0775/-rwxrwxr-x)  Uid: (  500/    fpm)   Gid: (  500/    fpm)
Access: 2014-05-14 06:30:45.107878096 -0700
Modify: 2014-05-14 06:30:36.337878203 -0700
Change: 2014-05-14 06:30:36.337878203 -0700


As you can see, the creation timestamp was not displayed.

However, it is easy to retrieve the file creation timestamp on an EXT4 filesystem using the debufgfs utility as I show below:

# debugfs
debugfs 1.41.12 (17-May-2010)
debugfs:  open /dev/sda3
debugfs:  cd home/fpm
debugfs:  stat helloworld
Inode: 396942   Type: regular    Mode:  0775   Flags: 0x80000
Generation: 1850782189    Version: 0x00000000:00000001
User:   500   Group:   500   Size: 6470
File ACL: 0    Directory ACL: 0
Links: 1   Blockcount: 16
Fragment:  Address: 0    Number: 0    Size: 0
 ctime: 0x53736ffc:508e72ec -- Wed May 14 06:30:36 2014
 atime: 0x53737005:19b85b40 -- Wed May 14 06:30:45 2014
 mtime: 0x53736ffc:508e72ec -- Wed May 14 06:30:36 2014
crtime: 0x53736ffc:38b6eee4 -- Wed May 14 06:30:36 2014
Size of extra inode fields: 28
Extended attributes stored in inode body: 
  selinux = "unconfined_u:object_r:user_home_t:s0\000" (37)
EXTENTS:
(0-1): 1620740-1620741


Here, the file creation time is labeled crtime.

Note, not having a file creation timestamp is not the end of the world. After all, the EXT2 and EXT3 filesystems did not have one. However, it does complicate things somewhat, and does add an element of uncertainty to a forensics examination of a system.