Hi everyone

I need help with linux timestamps. Let me give you a brief overview of what I am trying to achieve here. I'm doing a research project which focuses on tools which can be used to make a digital forensic investigation difficult. One of these tools is Linux's touch command which can be used to manipulate file timestamps thus might make it difficult for us to know what when a file was created, modified or accessed etc.

So I am thinking of introducing some code somewhere in the kernel such that when a user tries to use the touch command to manipulate the file timestamps, the original timestamps are copied (or preserved) somewhere else first before the user actually changes the time stamps. These original timestamps can then be used by a forensic investigator when performing audits or performing event reconstruction.

So I am not sure where in the Linux Kernel I should focus on. I have been reading about the inodes,how they store file metadata. I think the manipulation should be done before the touch manipulates the timestamps. Like when a system call for file attribute change gets executed.

I would appreciate any ideas you might give me to kick-start this prospect

actually not only touch modifies those values and also the existence (any) of them are highly depending on the filesystem type. Most probably you ought to modify the drivers of the filesystem(s), and also you need to handle the saved data.

And what if a user touches a file twice in succession? Or three times? Or a hundred? Or performs some other operation that alters the timestamp? Or does it twice...

If you do not keep a complete history then keeping only the last change would add very limited forensic value.

Thanks for your suggestion pan64. What other tools are out there which can modify the values? I apologize for my rather lame question, I'm still new to the Linux kernel. I think I will have to focus on one file system type if that's the case, for example if focus on only ext4 filesystem.

Thank you very much astrogeek. You know what, I hadn't thought of that completely. That's very true. I guess I will have to inject a somewhat 'recursive' code which should be able to store history of all the changes done to the file in sequence. I was also reading about the Linux auditing system, it might also prove useful in tracking the changes. But now I need to know if my plans are really feasible.

Hm. I think you know the answer: every and each application which is able to modify/write a file.

1 members found this post helpful.

Or inode modification (changing permissions/ACLs/Security labels)...

Then there are all the backup/restore tools...

Note, some filesystems already have additional dates in addition to the standard three, though I don't think they are in active use. See https://en.wikipedia.org/wiki/Ext4 for some reasons why.

Couldn't you do this with permissions. And disable touch command.

Nope. The touch command is just one way to change dates - all it can directly change is the modification date and access date. Both can be altered by any other command:
cat - modifies access date (so can shell redirection)
vi/vim/any editor - modifies modification date (even the shell can do that by using >> redirection
inode modification dates altered by chmod..

Then there are all the backup/restore tools. They ALL can change access/modification/creation dates.

Now, there IS a way prevent all date modifications... Just mount the filesystem read only.

But at that point, the filesystem becomes mostly useless except for archive purposes.

One last point - If you did disable the date changes, how would you detect improper modification of audit files?

Thank you for your response jpollard.I think I should focus on modifying the inodes as you suggested. Then well, due to the vast number of tools that can manipulate the timestamps should I just focus on particular tools or I should find a place in the kernel(if it exists) where I can inject code to copy the timestamps before they are manipulated? By the latter I'm assuming that all of the tools use the same technique in manipulating the timestamps like for example (though I'm just assuming this) use the same system call?

About the additional dates, you're very correct. There's the the 'birth' timestamp I've read about which is the time a particular file existed on that particular file system. I think to make it not too complex, I should focus on only the MAC timestamps.

Thanks Gary for the reply. I welcome your suggestion, however I'm focusing on if tools like the touch command gets used then how can we piece together what happened? Hence I come up with the idea of copying the time stamps before the touch command manipulates the timestamps.
Your suggestion will work pretty well, in a sense that I wouldn't need to focus on the timestamps but rather on permissions.

Thanks for the response jpollard. My intention is not to prevent/disable modification of the timestamps, modification should be possible, and then from that I want to build an audit trail. Hence I would want to copy the timestamp values before they get modified. I'm not sure how I can do this. I am also reading about the Linux auditing system, it might prove handy in my prospects.

Again, what happens when it is changed multiple times? If you just replace them, then there is no difference between the "new" dates and what exists now.

As pointed out in https://en.wikipedia.org/wiki/Ext4, you would have trouble modifying all the system calls... or adding new ones. There are a good many of them, though the big one is "stat", which is used to retrieve the data. Another problem is modifying all the backup tools. Which "birth" timestamp should be there? The one created when some application puts data in the file... or the "birth" date when a restore from backup creates the file...

Again, there are so many places you have to change... and a LOT of tools as well. The filesystems (some of them anyway) already have a field for such dates... but there is no standard way of handling the dates, and so many different tools that use the date. One likely forgotten tool is bash itself. It uses the various dates to allow for scripting tests. The same applies to every interpreter - perl/python/java/javascript/lisp/bash/csh/sh/tcsh/...

The major problem is getting such changes accepted by the kernel developers. There is no consensus for what dates, where they should be stored, how should they be managed, what system calls need to be modified/added.

Personally, I have used filesystems that had the usual creation/modification/access dates, plus backup dates (first backup, current backup). For most of these it is more efficient to store the dates with the archive copies - as the online dates are not very useful if they don't keep up with changes of the file. If you want the "birth" date of a file, look at the first backup where the file was archived...

The extended dates, though useful in a few circumstances, just aren't generally useful - and that is at least part of the reason the kernel developers have resisted.

One way to get something close is by using a hierarchical storage management (HSM) within a filesystem. In addition to the standard inode/modificate/access dates you also get a migrated date (when it got archived), unmigrated date (last retrieved from long term storage), as well as possible storage management dates (last movement to new storage, replication date, archive reference dates, error recovery dates - how many depends on which HSM is being used).

Audit trails work best when they are NOT part of the same filesystem. You can also look at SELinux and what it can record about files as well.