[PATCH ghak95] audit: Do not log full CWD path on empty relative paths

[Paul Moore]

On Sat, Dec 1, 2018 at 11:50 AM Steve Grubb <sgrubb at redhat.com> 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 <omosnace at redhat.com>
> wrote:
> > > On Tue, Nov 6, 2018 at 9:19 PM Paul Moore <paul at paul-moore.com> wrote:
> > > > On Tue, Nov 6, 2018 at 3:09 AM Ondrej Mosnacek <omosnace at redhat.com>
> wrote:
> > > > > On Tue, Nov 6, 2018 at 12:30 AM Paul Moore <paul at paul-moore.com>
> 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