From mboxrd@z Thu Jan 1 00:00:00 1970 From: Paul Moore Subject: Re: [PATCH ghak95] audit: Do not log full CWD path on empty relative paths Date: Tue, 13 Nov 2018 11:30:55 -0500 Message-ID: References: <20180802114436.1209-1-omosnace@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mx1.redhat.com (ext-mx20.extmail.prod.ext.phx2.redhat.com [10.5.110.49]) by smtp.corp.redhat.com (Postfix) with ESMTPS id B2871608FA for ; Tue, 13 Nov 2018 16:31:10 +0000 (UTC) Received: from mail-lf1-f49.google.com (mail-lf1-f49.google.com [209.85.167.49]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 1BAB8307CDE6 for ; Tue, 13 Nov 2018 16:31:09 +0000 (UTC) Received: by mail-lf1-f49.google.com with SMTP id n18so9291406lfh.6 for ; Tue, 13 Nov 2018 08:31:09 -0800 (PST) In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-audit-bounces@redhat.com Errors-To: linux-audit-bounces@redhat.com To: omosnace@redhat.com Cc: linux-audit@redhat.com List-Id: linux-audit@redhat.com On Tue, Nov 13, 2018 at 10:25 AM Ondrej Mosnacek wrote: > On Tue, Nov 6, 2018 at 9:19 PM Paul Moore wrote: > > On Tue, Nov 6, 2018 at 3:09 AM Ondrej Mosnacek wrote: > > > On Tue, Nov 6, 2018 at 12:30 AM Paul Moore wrote: > > > > Let's reset this discussion a bit ... if we abolish relative paths and > > > > make everything absolute, is there even a need to log PARENT? > > > > > > If there ever was such need, then this won't change when we switch to > > > absolute paths. The PATH records contain some fields (inode, dev, obj, > > > ...) that can be different for the child and parent and I would say > > > these are the only new information that the PARENT records provide > > > over the corresponding CREATE/DELETE records. > > > > Sigh. Of course the inode information is going to be different > > between the object in question and the parent, they are different > > filesystem objects. Ask your self the bigger question: does the > > PARENT record provide me any security relevant information related to > > the filesystem object that is being accessed? > > I would say it does. Consider e.g. the "mode" and "obj" fields. When > you move (rename) a file from one directory to another (which is the > main, if not the only, case when a PARENT record is emitted), then you > are usually more interested in the values for the parent directory > than the file itself (that's what determines if you can move the > file). I disagree on the importance of the mode/obj of the parent in a rename operation. From my perspective I really only care about the filesystem object that is being moved and if it succeeded or not. The idea that you care more about the parent than the object being moved makes no sense to me at all. > For example, assume you have a rule that logs whenever some sensitive > file gets moved. You do not expect that to happen because you set the > file/directory permissions and labels so that it can't be done by > anyone unauthorized. But something goes wrong, the permissions/labels > get changed somehow ... In which case you should be watching for changes to the filesystem metadata which affect access rights. That is how you should catch changes to permissions on a filesystem object as it gives you information about the change as well as the subject information of the user/process which made the change. > ... and a bad actor leverages the situation to move > the file. Then later you want to investigate this security incident > and as part of it you want to know what permissions were set on the > directories involved that had allowed the file to be moved, because > this may give you a useful lead. With PARENT records, you get such > information, without them you don't. If you only have that information in the parent record then you are missing half the story, and it may be the important half as the interesting bit of information in this example is the identity of the user/process which was able to change permissions to enable the rename to take place. Unless Steve provides evidence of some compelling certification requirement which necessitates the need for a parent record, I see no reason to keep it. -- paul moore www.paul-moore.com