From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ondrej Mosnacek Subject: Re: [PATCH ghak95] audit: Do not log full CWD path on empty relative paths Date: Tue, 13 Nov 2018 16:25:39 +0100 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-mx17.extmail.prod.ext.phx2.redhat.com [10.5.110.46]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 603345D9D6 for ; Tue, 13 Nov 2018 15:25:52 +0000 (UTC) Received: from mail-ot1-f70.google.com (mail-ot1-f70.google.com [209.85.210.70]) (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 C4AE031256A4 for ; Tue, 13 Nov 2018 15:25:52 +0000 (UTC) Received: by mail-ot1-f70.google.com with SMTP id j15so8724841ota.17 for ; Tue, 13 Nov 2018 07:25:52 -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: Paul Moore Cc: Linux-Audit Mailing List List-Id: linux-audit@redhat.com 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). 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 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. > > With the messed up state of path name auditing, the PARENT records are > useful when trying to recreate the full path used by the process to > access a given filesystem object (transient as it may be, the path > name can still be useful after the fact). If we switch to always > recording absolute path names, why do we care about recording the > PARENT filesystem object at all (both the path and the inode > information)? I disagree with your assumption that the PARENT record somehow helps to determine the full path of the (child) filesystem object, in the sense that it provides more information than what is already contained in the corresponding CREATE/DELETE record. (Please correct me if that's not what you were trying to say.) When we log the paths as we do now, you either get a relative path in both PARENT and CREATE/DELETE records (the PARENT path just being one element shorter) or you get a full path in both records (again both will be the same except the PARENT path will have the last component stripped), depending on whether the user passed a relative or absolute path to the syscall [*]. If we switch to always logging full paths, we simply eliminate the first case (both paths will be always absolute). Whether we switch to always logging absolute paths or not, the value of the "path" field of the PARENT record is somewhat redundant (but I don't see that as a problem). [*] Disregarding the occasional glitch of getting the (full) path of current directory as PARENT path when the child path is relative with just a single component, a.k.a. GHAK #95... -- Ondrej Mosnacek Associate Software Engineer, Security Technologies Red Hat, Inc.