LinuxQuestions.org
Welcome to the most active Linux Forum on the web.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Newbie
User Name
Password
Linux - Newbie This Linux forum is for members that are new to Linux.
Just starting out and have a question? If it is not in the man pages or the how-to's this is the place!

Notices


Reply
  Search this Thread
Old 02-15-2016, 02:31 AM   #1
sheu89
LQ Newbie
 
Registered: Feb 2016
Location: South Africa
Distribution: Linux Mint
Posts: 6

Rep: Reputation: Disabled
Question 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
 
Old 02-15-2016, 03:10 AM   #2
pan64
LQ Guru
 
Registered: Mar 2012
Location: Hungary
Distribution: debian/ubuntu/suse ...
Posts: 9,785

Rep: Reputation: 2888Reputation: 2888Reputation: 2888Reputation: 2888Reputation: 2888Reputation: 2888Reputation: 2888Reputation: 2888Reputation: 2888Reputation: 2888Reputation: 2888
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.

Last edited by pan64; 02-15-2016 at 03:30 AM.
 
Old 02-15-2016, 03:28 AM   #3
astrogeek
Moderator
 
Registered: Oct 2008
Distribution: Slackware [64]-X.{0|1|2|37|-current} ::12<=X<=14, FreeBSD_10{.0|.1|.2}
Posts: 4,506
Blog Entries: 6

Rep: Reputation: 2421Reputation: 2421Reputation: 2421Reputation: 2421Reputation: 2421Reputation: 2421Reputation: 2421Reputation: 2421Reputation: 2421Reputation: 2421Reputation: 2421
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.
 
Old 02-15-2016, 04:13 AM   #4
sheu89
LQ Newbie
 
Registered: Feb 2016
Location: South Africa
Distribution: Linux Mint
Posts: 6

Original Poster
Rep: Reputation: Disabled
Smile

Quote:
Originally Posted by pan64 View Post
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.
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.
 
Old 02-15-2016, 04:21 AM   #5
sheu89
LQ Newbie
 
Registered: Feb 2016
Location: South Africa
Distribution: Linux Mint
Posts: 6

Original Poster
Rep: Reputation: Disabled
Quote:
Originally Posted by astrogeek View Post
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.

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.
 
Old 02-15-2016, 04:24 AM   #6
pan64
LQ Guru
 
Registered: Mar 2012
Location: Hungary
Distribution: debian/ubuntu/suse ...
Posts: 9,785

Rep: Reputation: 2888Reputation: 2888Reputation: 2888Reputation: 2888Reputation: 2888Reputation: 2888Reputation: 2888Reputation: 2888Reputation: 2888Reputation: 2888Reputation: 2888
Quote:
Originally Posted by sheu89 View Post
What other tools are out there which can modify the values?
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.
Old 02-15-2016, 06:09 AM   #7
jpollard
Senior Member
 
Registered: Dec 2012
Location: Washington DC area
Distribution: Fedora, CentOS, Slackware
Posts: 4,713

Rep: Reputation: 1279Reputation: 1279Reputation: 1279Reputation: 1279Reputation: 1279Reputation: 1279Reputation: 1279Reputation: 1279Reputation: 1279
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.

Last edited by jpollard; 02-15-2016 at 06:14 AM.
 
Old 02-15-2016, 06:48 AM   #8
Gary Baker
Member
 
Registered: Mar 2007
Location: Whitsett,NC
Distribution: Slackware 14.1 and MINT 17.1
Posts: 105

Rep: Reputation: 3
Couldn't you do this with permissions. And disable touch command.
 
Old 02-15-2016, 07:17 AM   #9
jpollard
Senior Member
 
Registered: Dec 2012
Location: Washington DC area
Distribution: Fedora, CentOS, Slackware
Posts: 4,713

Rep: Reputation: 1279Reputation: 1279Reputation: 1279Reputation: 1279Reputation: 1279Reputation: 1279Reputation: 1279Reputation: 1279Reputation: 1279
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?

Last edited by jpollard; 02-15-2016 at 08:04 AM.
 
Old 02-15-2016, 09:00 AM   #10
sheu89
LQ Newbie
 
Registered: Feb 2016
Location: South Africa
Distribution: Linux Mint
Posts: 6

Original Poster
Rep: Reputation: Disabled
Thumbs up

Quote:
Originally Posted by jpollard View Post
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.
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.
 
Old 02-15-2016, 09:07 AM   #11
sheu89
LQ Newbie
 
Registered: Feb 2016
Location: South Africa
Distribution: Linux Mint
Posts: 6

Original Poster
Rep: Reputation: Disabled
Thumbs up

Quote:
Originally Posted by Gary Baker View Post
Couldn't you do this with permissions. And disable touch command.
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.
 
Old 02-15-2016, 09:15 AM   #12
sheu89
LQ Newbie
 
Registered: Feb 2016
Location: South Africa
Distribution: Linux Mint
Posts: 6

Original Poster
Rep: Reputation: Disabled
Thumbs up

Quote:
Originally Posted by jpollard View Post
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?
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.
 
Old 02-15-2016, 09:22 AM   #13
jpollard
Senior Member
 
Registered: Dec 2012
Location: Washington DC area
Distribution: Fedora, CentOS, Slackware
Posts: 4,713

Rep: Reputation: 1279Reputation: 1279Reputation: 1279Reputation: 1279Reputation: 1279Reputation: 1279Reputation: 1279Reputation: 1279Reputation: 1279
Quote:
Originally Posted by sheu89 View Post
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.
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).

Last edited by jpollard; 02-15-2016 at 09:31 AM.
 
Old 02-15-2016, 09:33 AM   #14
jpollard
Senior Member
 
Registered: Dec 2012
Location: Washington DC area
Distribution: Fedora, CentOS, Slackware
Posts: 4,713

Rep: Reputation: 1279Reputation: 1279Reputation: 1279Reputation: 1279Reputation: 1279Reputation: 1279Reputation: 1279Reputation: 1279Reputation: 1279
Quote:
Originally Posted by sheu89 View Post
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.
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.
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
[SOLVED] Log file issue: timestamps Annielover Linux - General 3 08-06-2011 08:43 AM
unable to change timestamps on a file aus9 Linux - Security 2 01-18-2008 05:41 AM
Getting file timestamps from a shell script sidra Programming 9 05-15-2007 09:55 AM
VSFTPD and file timestamps t3___ Linux - Newbie 4 01-21-2004 03:26 PM
converting log file timestamps mrtwice Linux - Software 3 09-22-2003 10:45 AM

LinuxQuestions.org > Forums > Linux Forums > Linux - Newbie

All times are GMT -5. The time now is 09:40 AM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration