Date: Mon, 24 Jun 2019 10:09:53 +0200 From: b <b-spam@intraversal.de> To: trustedbsd-audit@freebsd.org Subject: Re: Audit Pipe Drops Message-ID: <10BE768D-32B6-4457-9A77-8144B941F566@intraversal.de> In-Reply-To: <5247B21D-FB16-4949-85E5-9D0D8B37908C@intraversal.de> References: <5247B21D-FB16-4949-85E5-9D0D8B37908C@intraversal.de>
next in thread | previous in thread | raw e-mail | index | archive | help
Hello again, Could someone please comment on the following? > The FreeBSD Handbook has the notion that =E2=80=9Eaudit event classes = may be customized by modifying the audit_class and audit_event = configuration files=E2=80=9C. I assume this could also mean adding = custom audit classes and associating them with the event types of = interest. How can this be done programmatically for local audit trails? = Are there any code examples available? I am aware that this list is very low traffic. Unfortunately I have been = unsuccessful in finding another place to discuss bsm. If there are other = places, please let me know. Thank you, Benjamin > Am 06.06.2019 um 13:37 schrieb b via Darwin-dev = <darwin-dev@lists.apple.com>: >=20 > Hello everyone, >=20 > I am crossposting this message to the darwin dev list and the = trustedbsd-audit list since relevant knowledge might be shared among = members of both lists and I was not really sure how to properly present = the issue to both lists separately. Also, my post is quite long as it = bundles the outcome of several days of debugging. Please excuse. >=20 > I am currently reading a cloned bsm audit pipe from a user space = client on macOS to retrieve information about process creation and = operations on the system (pc|ex). In the future I want to add other = audit classes as well. I am currently looking at bsmtrace as a reference = implementation of the read loop. >=20 > There is one major issue, though, that took me a while to become aware = of. The audit pipe is allowed to drop audit records in the kernel, which = eventually is technically inevitable of course. The issue I am facing is = finding a reliable solution to avoid this. >=20 > Drops can occur only in audit_pipe_append (audit_pipe.c) under two = conditions, (1) the queue is full or (2) the kernel was not able to = allocate memory without blocking. >=20 > (1) can generally be managed in user space client code. There is only = one scenario I found (up to now) where even the maximum audit pipe = length is insufficient and that is system wake up procedure. Even before = the system emits kIOMessageSystemWillPowerOn there are lots and lots of = audit events that eventually max out the audit pipe. >=20 > (2) can=E2=80=99t be influenced from a user space client, at least not = that I am aware of. This happens sporadically but reproducibly when the = system is under a lot of stress, e.g. when a lot of processes are = spawned at a time and start executing some audited code. >=20 > All this leads to several questions of which I am not sure if they = qualify as potential bug reports or enhancement requests. I would be = more than happy if someone with a better understanding of things could = comment on them or even suggest possible solution approaches. >=20 > - (1) could clearly be solved by increasing the allowed maximum audit = pipe length which currently is 1024. This maximum value is probably = several years old by now and I could imagine that in the meantime the = xnu kernel has become a lot more =E2=80=9Etalkative=E2=80=9C. Is there = some technical limitation that would prevent an increase? >=20 > - I am wondering how the global audit trail that is written to disk is = able to perform better, i.e. does not drop (seemingly), than the cloned = audit pipe purely in memory? Is there some penalty associated with = passing memory from the kernel to user space? How does the global audit = trail not struggle with the M_NOWAIT policy? >=20 > - Since the audit pipe tries to acquire memory by calling malloc with = the M_NOWAIT flag, which I assume happens for a reason, is there some = strategy or configuration available from user space to ease the = restraint on kernel memory allocation =E2=80=93 or am I simply out of = luck here? >=20 > - I am surely not an expert on memory allocation and even less so in = kernel space. With that said, I imagine that allocating only one block = of memory for both, pointer (ape) and memory blob (ape->ape_record), = instead of two separate memory allocations would half the potential for = M_NOWAIT failure. >=20 > - Potential for both (1) and (2) could at least be reduced by further = filtering events in the kernel. I am not interested in each and every = audit event type. The FreeBSD Handbook has the notion that =E2=80=9Eaudit = event classes may be customized by modifying the audit_class and = audit_event configuration files=E2=80=9C. I assume this could also mean = adding custom audit classes and associating them with the event types of = interest. How can this be done programmatically for local audit trails? = Are there any code examples available? >=20 > I hope this does not come across (too) snarky but my expectation = towards a security mechanism is first and foremost reliability. = Information loss is definitely not supportive in that. Therefore I = either hope for a viable existing solution for my problem or am very = eager for a fix to the issues at hand. >=20 > Thanks, > Benjamin > _______________________________________________ > Do not post admin requests to the list. They will be ignored. > Darwin-dev mailing list (Darwin-dev@lists.apple.com) > Help/Unsubscribe/Update your Subscription: > = https://lists.apple.com/mailman/options/darwin-dev/b-spam%40intraversal.de= >=20 > This email sent to b-spam@intraversal.de
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?10BE768D-32B6-4457-9A77-8144B941F566>