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.
You'd have to modify OpenOffice to decrypt and re-encrypt documents,
right?
The idea was that we would capture the writes and the data and then
encrypt it ourselves so OO would not need to care.
Evan