Auditing File Changes

[Timothy R. Chavez]

On Mon, 2006-07-10 at 14:11 -0700, eklinger at uci.edu wrote:
> > On Mon, 2006-07-10 at 15:42 -0400, Valdis.Kletnieks at 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