From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Timothy R. Chavez" Subject: Re: Auditing File Changes Date: Mon, 10 Jul 2006 16:37:43 -0500 Message-ID: <1152567463.18406.48.camel@localhost.localdomain> References: <20060710193214.95422.qmail@web36606.mail.mud.yahoo.com> <200607101942.k6AJgUo2016221@turing-police.cc.vt.edu> <1152561408.4275.17.camel@fryspc> <2504.216.231.24.46.1152565902.squirrel@webmail.uci.edu> Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Return-path: Received: from mx1.redhat.com (mx1.redhat.com [172.16.48.31]) by int-mx1.corp.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k6ALbo4v014767 for ; Mon, 10 Jul 2006 17:37:50 -0400 Received: from e32.co.us.ibm.com (e32.co.us.ibm.com [32.97.110.150]) by mx1.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k6ALbnGT008367 for ; Mon, 10 Jul 2006 17:37:50 -0400 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e32.co.us.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id k6ALbi5n022916 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Mon, 10 Jul 2006 17:37:44 -0400 Received: from d03av04.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170]) by westrelay02.boulder.ibm.com (8.13.6/NCO/VER7.0) with ESMTP id k6ALbifJ308400 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 10 Jul 2006 15:37:44 -0600 Received: from d03av04.boulder.ibm.com (loopback [127.0.0.1]) by d03av04.boulder.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id k6ALbhLS010944 for ; Mon, 10 Jul 2006 15:37:44 -0600 In-Reply-To: <2504.216.231.24.46.1152565902.squirrel@webmail.uci.edu> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-audit-bounces@redhat.com Errors-To: linux-audit-bounces@redhat.com To: eklinger@uci.edu Cc: linux-audit@redhat.com List-Id: linux-audit@redhat.com On Mon, 2006-07-10 at 14:11 -0700, eklinger@uci.edu wrote: > > On Mon, 2006-07-10 at 15:42 -0400, Valdis.Kletnieks@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