File creation times

Posted Jul 29, 2010 19:04 UTC (Thu) by butlerm (subscriber, #13312)
Parent article: File creation times

Creation times are a great idea. The idea that a creation time should not be changeable is an extraordinarily bad one. Backup software, copy commands with the preserve attribute option specified, and any application that does file replacement with a write / fsync / rename sequence need that ability. Otherwise it is borderline useless, telling you something much more akin to the time of last modification than when the file was created.

to post comments

File creation times

Posted Jul 29, 2010 19:31 UTC (Thu) by hppnq (guest, #14462) [Link] (5 responses)

The idea that a creation time should not be changeable is an extraordinarily bad one.

Not really. It allows you to easily verify whether a file has been tempered with by an attacker.

File creation times

Posted Jul 29, 2010 20:45 UTC (Thu) by sync (guest, #39669) [Link] (4 responses)

No. When the attacker overwrites (not replace) the file the creation time doesn't change.

File creation times

Posted Jul 29, 2010 21:10 UTC (Thu) by tialaramex (subscriber, #21167) [Link] (3 responses)

Worse, the attacker is not obliged to obey your conventions.

Just because _you_ don't want to change the create time, doesn't prevent the attacker from doing so. "Oh," you say "but there will be no syscall". Again, this is a problem for you, the legitimate user, but not for the attacker, he can just force the relevant blocks out to disk, scribble on the raw disk, and let them be read back in again - voila!

File creation times

Posted Jul 30, 2010 7:14 UTC (Fri) by hppnq (guest, #14462) [Link] (2 responses)

It's quite likely that you can't use ctime to verify that a file has NOT been tempered with. If someone is able to scribble something poetic on a raw device, it makes no sense to worry about the ctime on /bin/ls. This should not be trivial for an attacker, of course.

But obviously, if a ctime has changed unexpectedly, there's no doubt someone messed with the file, or the kernel.

File creation times

Posted Jul 30, 2010 11:50 UTC (Fri) by sync (guest, #39669) [Link] (1 responses)

Now you are talking about change time (ctime) not creation time.

And ctime changes doesn't means that someone messed the file. There are a lot of false positives:
selinux relables the file
backup program resets atime
...

And of course ctime should not be user changeable. But not for security reasons.

File creation times

Posted Jul 30, 2010 16:49 UTC (Fri) by hppnq (guest, #14462) [Link]

Now you are talking about change time (ctime) not creation time.

Ah, I assumed indeed that the original comment was about ctime. I was never talking about creation time. Sorry for the confusion.

And ctime changes doesn't means that someone messed the file.

Of course not.

And of course ctime should not be user changeable. But not for security reasons.

Look up some real-world examples of intrusions and how they were detected, or delve deeper into forensic discovery with The Coroner's Toolkit or its successor The Sleuth Kit. Fascinating stuff.

File creation times

Posted Aug 9, 2010 11:41 UTC (Mon) by dgm (subscriber, #49227) [Link] (2 responses)

Also creation times may come from outside. For example, I would love to be able to list all my pictures in a directory by the time I created (shoot) them. That would be impossible without the ability to modify the creation time, because it would not be the time provided by the camera, but the one stamped by the kernel when the pictures were copied from it, which is far less useful for me.

File creation times

Posted Sep 29, 2010 13:36 UTC (Wed) by misiu_mp (guest, #41936) [Link] (1 responses)

Photo creation time is usually written in the exif data. I dont know if the camera can be trusted with setting file creation time for the files on the sdcard correctly. Not to mention they are stored on a removable fat system which means they could be modified by multitude systems with other oses.

File creation times

Posted Sep 29, 2010 16:43 UTC (Wed) by bronson (guest, #4806) [Link]

Most cameras that I've seen (especially idiot boxes) can't be trusted to have their clocks set to the current month, much less the correct time zone.

There's a photographer that I know who often cares about the exact time a picture was taken (professional building shots, relying on sun angles). He first takes a picture of his GPS so, if things look weird, he can figure out the correction.

Anyhow point is, unless the camera is running NTP or a GPS receiver, I wouldn't put much weight in EXIF data!