You can try to use auditd for logging access to files (and more), but if an attacker gains access to your machine as superuser, then it is possible that all logs and traces are wiped without any way to detect it.
One possible mitigation is to enable remote logging (over the network) or use some other hardware that allows to append data only without the ability to overwrite stuff.
If you suspect a compromise and want to investigate it, you are entering the area of forensics. Depending on the sloppiness of the attacker this may succeed or fail. Examples include forgetting to remove a .bash_history
or log files and deleting files without shredding it.
You mention "file signature", but "touch" only modifies the metadata of the file. These are stored in a filesystem-specific format on the underlying disk device. Usually unprivileged programs cannot directly modify the underlying disk device. Instead they communicate with the kernel using system calls and request modifications to the filesystem (which then propagate changes to the underlying disk). To see what system calls a program use, you can use the strace program. For example, strace touch x
gives me:
...
open("x", O_WRONLY|O_CREAT|O_NOCTTY|O_NONBLOCK, 0666) = 3
dup2(3, 0) = 0
close(3) = 0
utimensat(0, NULL, NULL, 0) = 0
...
Here you can see that the open
system call is passed a path and returns a file descriptor. Later, this filedescriptor is used in a call to the utimensat
system call which changes the file timestamp. All of these actions can be logged by the audit daemon described before and of course the results can be observed due to changes to the filesystem. If you dig deep enough, you may find evidence of this activity, but then you are really relying on the creativity of forensics.
touch
command, then no new file is created, only the metadata is modified so "undelete" is not possibly. To better understand whytouch
is (not) detectable, you must understand what thetouch
command does (see updated answer for that). – Lekensteyn Sep 19 '16 at 20:10