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: Mon, 3 Dec 2018 19:17:34 -0500 Message-ID: References: <20180802114436.1209-1-omosnace@redhat.com> <1788887.BxGTRfZV6P@x2> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mx1.redhat.com (ext-mx06.extmail.prod.ext.phx2.redhat.com [10.5.110.30]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 6F8E9601A6 for ; Tue, 4 Dec 2018 00:17:49 +0000 (UTC) Received: from mail-lf1-f54.google.com (mail-lf1-f54.google.com [209.85.167.54]) (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 E87C93680F for ; Tue, 4 Dec 2018 00:17:47 +0000 (UTC) Received: by mail-lf1-f54.google.com with SMTP id f23so10575787lfc.13 for ; Mon, 03 Dec 2018 16:17:47 -0800 (PST) In-Reply-To: <1788887.BxGTRfZV6P@x2> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-audit-bounces@redhat.com Errors-To: linux-audit-bounces@redhat.com To: sgrubb@redhat.com, omosnace@redhat.com Cc: rgb@redhat.com, linux-audit@redhat.com List-Id: linux-audit@redhat.com On Sat, Dec 1, 2018 at 11:50 AM Steve Grubb wrote: > On Tuesday, November 13, 2018 11:30:55 AM EST Paul Moore wrote: > > 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? > > I believe that Al Viro has said that sometime paths are not resolvable in the > future. For example process A opens a file. It passes the descriptor to > another process using scm rights. Directory tree is deleted. Process B > receives the descriptor. Process A exits. Process B is now accessing what? The window is even more narrow than that, in theory the file path could change before the thread returns from open/openat/etc. The only time a path is valid for any given file is when is is being resolved; this is why we have to go through all the pain that we do when auditing path names, you can't get them after opening the file. > > > > > 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. > > The mode is really not important. > > > > 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. > > Right. You would watch for attribute changes on a directory. > > > > > ... 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. > > Certification does not care about parent records. What is cares about is being > able to say what the object was that is acted upon. So, that would be device > and inode. ... which we track in the PATH record, so we should be okay on this point ... > But that is not nice for people. So, we would also like to know > the path name. If parent record are necessary because of the *at syscalls, > then that may be the only purpose. And they do not need to be emitted each > time. If we also have a full path, then they are not needed. ... that is what I was thinking, and why I suggested we can get rid of them if we get rid of relative paths. > If we have a relative path, then CWD is needed, not the parent. > > I also understand that at times full path resolution may not work out due to > directory permissions blocking access at a deeper level of the directory > tree. In those cases, we probably do want a PARENT record for the failed > access attempt. I think that discussion may have prompted creation of PARENT > records a long time ago. But at the same time, I also mentioned that the path > was passed as an arguement and we could always emit that...but we do not have > any other information such as mode or security label. I wonder what we log now in this case? > In summary, certification does not say we need PARENT directories of the > object. We need the object. And we only need help when its not clear what the > object was. -- paul moore www.paul-moore.com