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.
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.
--
paul moore
www.paul-moore.com