Re: Auditing File Changes
On Mon, 2006-07-10 at 14:11 -0700, eklinger(a)uci.edu wrote:
> On Mon, 2006-07-10 at 15:42 -0400, Valdis.Kletnieks(a)vt.edu
wrote:
> ...
>>
>> Probably depends on what actual problem he's trying to solve by
>> recording
>> all the changes.
>
> Most likely the same one I have been working on all my career:
>
Actually I'm trying to prevent certain files from leaving the computer,
specifically source code. However, that means I need to watch for file
copies, renames, cut and pastes, emails, etc. The idea was to encapsulate
the actual file data in an encrypted wrapper that would have to be
opened/decrypted by our program. The wrapper would also contain the
allowed operations on the file data itself, which is where auditing would
come in so that we can see what the user is attempting to do with the
file. After we decrypt the file and remove the wrapper, the raw data would
be opened in the appropriate application on the system (e.g.
OpenOffice.org). However, at the save we would want to add that wrapper
back in so they could not simply circumvent the wrapper protection
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.
. Of
course, we don't want to have to modify any of the user level applications
to achieve this functionality.
You'd have to modify OpenOffice to decrypt and re-encrypt documents,
right?
-tim