On Tue, Nov 6, 2018 at 9:19 PM Paul Moore <[email protected]> wrote: > On Tue, Nov 6, 2018 at 3:09 AM Ondrej Mosnacek <[email protected]> wrote: > > On Tue, Nov 6, 2018 at 12:30 AM Paul Moore <[email protected]> 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 <omosnace at redhat dot com> Associate Software Engineer, Security Technologies Red Hat, Inc. -- Linux-audit mailing list [email protected] https://www.redhat.com/mailman/listinfo/linux-audit
