Re: [RFC PATCH ghak9 0/3] audit: Record the path of FDs passed to *at(2) syscalls
On Wed, Jul 18, 2018 at 10:41 PM Paul Moore <paul(a)paul-moore.com> wrote:
On Thu, Jul 12, 2018 at 7:36 AM Ondrej Mosnacek
<omosnace(a)redhat.com> wrote:
> This patchset is a prototype implementation of the feature requested in GHAK issue
#9 [1]. I decided for a simple auxiliary record with just 2 fields (fd and path) that is
emitted whenever we want to record the full path for a file descriptor passed to a syscall
(e.g. the dirfd argument of openat(2)). I choose this approach because for some syscalls
there is more than one file descriptor we might be interested in (a good example is the
renameat(2) syscall).
>
> The motivation for this feature (as I understand it) is to avoid the need to
reconstruct the paths corresponding to the file descriptors passed to syscalls, as this
might be difficult and time consuming or even impossible in case not all of the right
sycalls are being logged. Note that it is always possible to disable these records by
simply adding an exclude filter rule matching all records of type FD_PATH.
>
> At this moment I only implement logging for a single syscall (openat(2)) to keep it
simple. In the final version I plan to add support for other similar syscalls ()mkdirat,
mknodeat, fchownat, ...).
>
> Please let me know if the general approach and the proposed record format make sense
to you so I can improve/complete the solution.
>
> Thanks,
> Ondrej
>
> [1] https://github.com/linux-audit/audit-kernel/issues/9
While I recognize that the GH issue did raise the idea of possibly
creating a new record type, looking at these patches I'm not sure a
new record type is justified, I think reusing the existing PATH record
type would be more beneficial. I recognize that this proposed FD_PATH
record also contains the file descriptor number, but that information
should also be contained in the associated SYSCALL record and arguably
the fd number is only useful if you are logging the SYSCALL
information.
To be honest, I'm not sure what is the exact semantic of the PATH
record... Is it simply "log information about files that the syscall
somehow touched"? Or "log information about any string syscall
argument that represents a file path"? In the PATH record samples I
have seen, the name=... field sometimes contains just the last segment
of the path, other times it contains the full path (huh?). When we log
the full path in PATH, then I guess the FD_PATH record would be
(almost) redundant, but it seems that whenever openat(2) is called
with dirfd != AT_FDCWD, PATH name=... contains just the relative path
supplied to the syscall (thus FD_PATH actually provides the missing
directory path).
So... assuming we would want to provide the missing information in the
existing PATH record, how should it look like? Should the name=...
field simply always contain the full path? Should there be another
PATH record for the directory? If so, how do we indicate the
association between the two PATH records?
Can you explain what advantage the FS_PATH record type has over
reusing the existing PATH record? I know you mention multiple
fd/paths as in the case of renameat(2), but we already have to deal
with this in the non-at rename(2) case.
As I said above, I don't fully understand the PATH record so I can't
compare them right now. Multiple fd arguments was meant as more of a
justification for the presence of the fd=... field in the new FD_PATH
record.
--
Ondrej Mosnacek <omosnace at redhat dot com>
Associate Software Engineer, Security Technologies
Red Hat, Inc.