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

[Ondrej Mosnacek]

On Sat, Dec 1, 2018 at 5:50 PM 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?

Yes, this can happen, but even in cases where the path cannot be
determined any more, the PARENT records won't help you, because the
path in PARENT records is in fact based on the path of the child, the
code just cuts away the last component. See:
https://elixir.bootlin.com/linux/v4.19.6/source/kernel/auditsc.c#L1839

>
>
> > > > > 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.

All right, forget about the mode/context fields... I went in the wrong
direction there.

>
> > > 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. 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. If we have a
> relative path, then CWD is needed, not the parent.

The PARENT records are only emitted with syscalls that operate with
directories (i.e. open(..., O_CREAT|...), unlink(), rename(), and
friends). In this case the object being modified is actually the
containing directory (you need write permission to the dir but you
don't any permissions to the file itself). Of course from a more high
level perspective the object being moved is equally (if not more)
important so to cover both perspectives we need to log the { inode,
device, path } info for both the object and its container. At least
that is how I (now) understand the primary purpose of the PARENT
record. I think the supposed usefulness in reconstructing the path to
the child is just a red herring...

>
> 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.
>
> 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.

But are you sure that 'the object' in the case of creating/deleting a
file is not also the containing directory? The parent directory is
being modified/written to and the child is being created/deleted so
logically we should log information about both objects. (That said, I
probably expect too much logic from certifications...)

--
Ondrej Mosnacek <omosnace at redhat dot com>
Associate Software Engineer, Security Technologies
Red Hat, Inc.