Friday, November 13, 2020

Re: System auditing and logging

So you want to ktrace your entire system, with a limited set of
monitors.

I've played with this before, to identify specific behaviours
when developing pledge. It required a large number of hacks,
and the performance was dismal.

Based upon my experience, I predict it will not work for your usage
case at all.



James <james@jmp-e.com> wrote:

> Thanks. I have enabled system accounting.
>
> acct(5) seems to be limited by the fact that it is triggered on process
> exit, doesn't contain the process ID or parent process ID and can only
> store 10 characters for the command name.
>
> ktrace could work but it's far too slow without limiting syscalls
> recorded to a specific subset.
>
> Is there any interest in modifying ktrace to allow for specifying
> individual names of syscalls to trace?
>
> e.g. ktrace -t c -u execve,sendmsg
>
> On Fri, Nov 13, 2020 at 07:57:54AM -0700, Theo de Raadt wrote:
> >man accton
> >
> >James <james@jmp-e.com> wrote:
> >
> >> Recently a machine running OpenBSD 6.8 had its configuration changed and I
> >> believe it to have been subject to a malicious attack.
> >>
> >> This change is completely unexplainable, compromised security, and would
> >> have required root access.
> >>
> >> The log files reveal nothing out of the ordinary except for wtmp
> >> indicating 0 users are logged in:
> >>
> >> -bash-5.0# who
> >> -bash-5.0# w
> >> 1:49PM up 2:21, 0 users, load averages: 1.35, 1.38, 1.50
> >> USER TTY FROM LOGIN@ IDLE WHAT
> >> -bash-5.0#
> >>
> >>
> >> I would like to be able to log every exec syscall with the details of the
> >> current timestamp, calling PID, program path, arguments, and new PID.
> >>
> >> Ideally this would be implemented in the kernel. Are there any
> >> existing solutions?
> >>
> >> Thanks,
> >>
> >

No comments:

Post a Comment