On Mon, Nov 12, 2012 at 10:51 AM, Kat <[email protected]> wrote: > I see this topic come up a lot and I have dealt with the question from > auditors too. Unless you have full auditing enabled, the simple answer is > no. > > Think about this -- a file is writable by the owner and a group - the group > contains 1000 users. Auditd is NOT enabled. One of those 1000 users that has > the ability to modify the file and indeed they do. Unix checks the perms and > verifies that the uid or gid has permission to modify the file. It does, it > is allowed. > > No place in the inode or the directory entry is any information kept on who > modified the file. Why? Because it has to be someone that is authorized to > do it. Therefore the only way to track this data is to have another process > monitor everything users are doing - i.e. "auditd" running, in order to > track this. > > At one point I had an auditor tell me "But tripwire does this." Um, no it > does not. Tripwire shows that the file was changed and who the owner of the > file is. Based on this, auditors sometimes assume that it was the owner > changing the folder, which is not the case. > > Additionally, if a user has sudo privs to one of the UIDs or GIDs - well, > that pretty much throws it all out the window. > > Take a look at "auditd" and if you are willing to accept the load it may > present on your system, then this will solve the question you are asking. > Otherwise, you are not going to be able to do it. It is all about > understanding what information is stored in an inode and the directory > entry. (And the directory entry is minimal -- filename, inode #) > > cheers > Kat
I'm guessing the big commercial UNIXes have something similar, but auditd is a Linux daemon, right?
