Auditing File Changes

[eklinger at uci.edu]

> 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