File timestamps
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. |
Quote:
|
Quote:
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. |
Quote:
|
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? |
Quote:
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. |
Quote:
Your suggestion will work pretty well, in a sense that I wouldn't need to focus on the timestamps but rather on permissions. |
Quote:
|
Quote:
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). |
Quote:
|
All times are GMT -5. The time now is 12:28 AM. |