Date: Sun, 11 Aug 2019 16:10:41 +0200 From: ASV <asv@inhio.net> To: b <b-spam@intraversal.de>, trustedbsd-audit@freebsd.org Subject: Re: Audit Pipe Drops Message-ID: <0e9ca039cfc2d4cc860b08c40e2bfdbdf660e30e.camel@inhio.net> In-Reply-To: <10BE768D-32B6-4457-9A77-8144B941F566@intraversal.de> References: <5247B21D-FB16-4949-85E5-9D0D8B37908C@intraversal.de> <10BE768D-32B6-4457-9A77-8144B941F566@intraversal.de>
next in thread | previous in thread | raw e-mail | index | archive | help
--=-L6EtKb6WNAsA40MJZlGo Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, I personally don't know the answer to your question; I've never tried to do that. But I'd like to inform you that since 2016 only 2 emails got a reply on this list. Just for you to know better what to expect here. Good luck. On Mon, 2019-06-24 at 10:09 +0200, b wrote: > Hello again, >=20 > Could someone please comment on the following? >=20 >=20 > > The FreeBSD Handbook has the notion that =E2=80=9Eaudit event classes m= ay > > be customized by modifying the audit_class and audit_event > > configuration files=E2=80=9C. I assume this could also mean adding cust= om > > 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 >=20 > 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. >=20 >=20 > Thank you, > Benjamin >=20 >=20 >=20 >=20 > > 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: > >=20 https://lists.apple.com/mailman/options/darwin-dev/b-spam%40intraversal.de > >=20 > > This email sent to b-spam@intraversal.de >=20 > _______________________________________________ > trustedbsd-audit@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/trustedbsd-audit > To unsubscribe, send any mail to " > trustedbsd-audit-unsubscribe@freebsd.org" --=-L6EtKb6WNAsA40MJZlGo Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- iQEzBAABCgAdFiEE5dE8BwbhhcQw2TsezaQsUNd+zIkFAl1QIeIACgkQzaQsUNd+ zIlLkggApXRuiMUODgMOoK/Fkl0iT9CAXjQcQPNK/eY8+RD4Vo0hAu+GhoDuOgLU PqY0imRe17YwtiBJNgKqsZSzhHMXE9mQ9OU1Lbxjiyy29/0Kwh4kmzngMdn6HgZE dJ1CLqG6mvpwL0CnBIh7J7ISl1YznjuivmVfcTRndk4SRKxjl9l1yelDVTwzuo/r w0bIMbmU/7m21hPbo2IYEOhpZW77rkFoXqd406S8rp9/raziF8QqftC0ESXk2tkm WTSJ+dzq6ourcL7VhrlFqjA1GO6PsjEJ15rLtyY0XdG3NEC9vGMBOYVpg8IhemMp jd+IYXtmXy8euWkAb3ifzzgBc9zsdQ== =Yhbi -----END PGP SIGNATURE----- --=-L6EtKb6WNAsA40MJZlGo--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?0e9ca039cfc2d4cc860b08c40e2bfdbdf660e30e.camel>