Re: Auditing File Changes

> Maybe it's the way you've described it, but this sounds like a very > contrived and fickle security mechanism. I really don't understand the > purpose of your encryption, can you elaborate any? Maybe I'm just > confused with the example you gave. Further more, if you want to > restrict operations on a given a file, why reinvent the wheel, it's > already doable. Also, the audit subsystem does log events describing > "copy" events, renames, linking, unlinking, open's, close's, file > attribute modifications, etc, without the need for modifying specific > programs. Decompose the "abstract" event of cut and paste into its > system-calls and there you go. > The original idea was to prevent the user from opening the file in any text or hex editor and changing the file or the file's allowed operations, which would be stored in the file itself. However, if we can capture the open call we may not need the the encryption afterall. All of this is just a proof of concept. It will need to be refined much more before we do the actual implementation, which is why I'm here to get these comments and ideas from the community. :) We do not want to reinvent the wheel but the permissions need to go beyond the basic read-write-exec since engineers will need to modify the source code files but we may not want them to copy them to a usb drive or email them, and we want the permissions to be in place across platforms.