Darwin-kernel

Download

darwin-kernel@lists.apple.com

June 2019

1 participants
1 discussions

Audit Pipe Drops
by b via Darwin-kernel 24 Jun '19

24 Jun '19

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com Hello everyone, I posted the following to the darwin-dev list a couple of weeks ago but haven’t received any responses yet. There is quite some kernel specifics involved, so I am trying my luck here as well. Thanks, Benjamin > Anfang der weitergeleiteten Nachricht: > > Von: b via Darwin-dev <darwin-dev(a)lists.apple.com> > Betreff: Audit Pipe Drops > Datum: 6. Juni 2019 um 13:37:22 MESZ > An: darwin-dev(a)lists.apple.com, trustedbsd-audit(a)freebsd.org > Antwort an: b <b-spam(a)intraversal.de> > > Hello everyone, > > 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. > > 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. > > 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. > > 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. > > (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. > > (2) can’t 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. > > 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. > > - (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 „talkative“. Is there some technical limitation that would prevent > an increase? > > - 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? > > - 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 – or am I simply out of luck here? > > - 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. > > - 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 „audit event classes may > be customized by modifying the audit_class and audit_event configuration > files“. 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 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. > > Thanks, > Benjamin > _______________________________________________ > Do not post admin requests to the list. They will be ignored. > Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) > Help/Unsubscribe/Update your Subscription: > https://lists.apple.com/mailman/options/darwin-dev/b-spam%40intraversal.de > > This email sent to b-spam(a)intraversal.de _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists… This email sent to site_archiver(a)lists.apple.com

1 0