From owner-trustedbsd-audit@freebsd.org Sun Aug 11 14:10:56 2019 Return-Path: <owner-trustedbsd-audit@freebsd.org> Delivered-To: trustedbsd-audit@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 3488BB9D41 for <trustedbsd-audit@mailman.nyi.freebsd.org>; Sun, 11 Aug 2019 14:10:56 +0000 (UTC) (envelope-from asv@inhio.net) Received: from cz-prg-mx-01.inhio.net (mail.inhio.net [178.238.36.226]) by mx1.freebsd.org (Postfix) with ESMTP id 46619B6yV8z400S for <trustedbsd-audit@freebsd.org>; Sun, 11 Aug 2019 14:10:54 +0000 (UTC) (envelope-from asv@inhio.net) Received: from titanio (titanio.inhio.net [10.0.0.21]) by cz-prg-mx-01.inhio.net (Postfix) with ESMTPSA id 6C7FD5CDF2; Sun, 11 Aug 2019 16:10:47 +0200 (CEST) Message-ID: <0e9ca039cfc2d4cc860b08c40e2bfdbdf660e30e.camel@inhio.net> Subject: Re: Audit Pipe Drops From: ASV <asv@inhio.net> To: b <b-spam@intraversal.de>, trustedbsd-audit@freebsd.org Date: Sun, 11 Aug 2019 16:10:41 +0200 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> Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="=-L6EtKb6WNAsA40MJZlGo" X-Mailer: Evolution 3.28.5 FreeBSD GNOME Team Mime-Version: 1.0 X-Rspamd-Queue-Id: 46619B6yV8z400S X-Spamd-Bar: ------- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of asv@inhio.net designates 178.238.36.226 as permitted sender) smtp.mailfrom=asv@inhio.net X-Spamd-Result: default: False [-7.14 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; MV_CASE(0.50)[]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; DMARC_NA(0.00)[inhio.net]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-0.98)[-0.984,0]; RCPT_COUNT_TWO(0.00)[2]; SIGNED_PGP(-2.00)[]; RCVD_NO_TLS_LAST(0.10)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:24971, ipnet:178.238.32.0/20, country:CZ]; MID_RHS_MATCH_FROM(0.00)[]; IP_SCORE(-2.35)[ip: (-9.86), ipnet: 178.238.32.0/20(-4.93), asn: 24971(2.95), country: CZ(0.08)]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: trustedbsd-audit@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TrustedBSD Audit Discussion List <trustedbsd-audit.freebsd.org> List-Unsubscribe: <https://lists.freebsd.org/mailman/options/trustedbsd-audit>, <mailto:trustedbsd-audit-request@freebsd.org?subject=unsubscribe> List-Archive: <http://lists.freebsd.org/pipermail/trustedbsd-audit/> List-Post: <mailto:trustedbsd-audit@freebsd.org> List-Help: <mailto:trustedbsd-audit-request@freebsd.org?subject=help> List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/trustedbsd-audit>, <mailto:trustedbsd-audit-request@freebsd.org?subject=subscribe> X-List-Received-Date: Sun, 11 Aug 2019 14:10:56 -0000 --=-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-- From owner-trustedbsd-audit@freebsd.org Mon Aug 12 22:51:03 2019 Return-Path: <owner-trustedbsd-audit@freebsd.org> Delivered-To: trustedbsd-audit@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 60F91C3BA5 for <trustedbsd-audit@mailman.nyi.freebsd.org>; Mon, 12 Aug 2019 22:51:03 +0000 (UTC) (envelope-from dano@well.com) Received: from xmx.well.com (xmx.well.com [52.0.124.244]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "", Issuer "The WELL Group" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 466rft48Cdz46hX for <trustedbsd-audit@freebsd.org>; Mon, 12 Aug 2019 22:51:02 +0000 (UTC) (envelope-from dano@well.com) X-Date: Mon, 12 Aug 2019 15:51:01 -0700 Received: from zimbra.well.com (zimbra.well.com [172.30.1.200]) by xmx.well.com (8.14.4/8.14.3) with ESMTP id x7CMp1LT027367 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for <trustedbsd-audit@freebsd.org>; Mon, 12 Aug 2019 15:51:01 -0700 Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.well.com (Postfix) with ESMTP id 2490C100B9889 for <trustedbsd-audit@freebsd.org>; Mon, 12 Aug 2019 15:51:01 -0700 (PDT) Received: from zimbra.well.com ([127.0.0.1]) by localhost (zimbra.well.com [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id GHPdyy0fDPa2 for <trustedbsd-audit@freebsd.org>; Mon, 12 Aug 2019 15:50:59 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.well.com (Postfix) with ESMTP id 8B945100B9825 for <trustedbsd-audit@freebsd.org>; Mon, 12 Aug 2019 15:50:59 -0700 (PDT) DKIM-Filter: OpenDKIM Filter v2.9.2 zimbra.well.com 8B945100B9825 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=well.com; s=6EE067AA-1511-11E5-BE77-89F1327358AA; t=1565650259; bh=V1THyjCzovFs5WgpYwoxiv6Z5m4RjRCUJBLLMr7DsGU=; h=From:Content-Type:Mime-Version:Subject:Date:To:Message-Id; b=grO2C4Y9KinLaKDOUxNjDkaf/qc3xbvFRD2vb0uvJDzxEucryuXXlgIcGT7KlK+j4 tD4bZgl2qGHJDS7PfmlHfimkSxleWi9zXQGucFl/v49hU664gilKApLc/q50N6XCER jBbJhXgUI91TTkDXsDssGLGJECvnz13No7U5vqZ8= X-Virus-Scanned: amavisd-new at well.com Received: from zimbra.well.com ([127.0.0.1]) by localhost (zimbra.well.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id tAJIMxZODKBp for <trustedbsd-audit@freebsd.org>; Mon, 12 Aug 2019 15:50:59 -0700 (PDT) Received: from [192.168.1.7] (unknown [47.151.150.37]) by zimbra.well.com (Postfix) with ESMTPSA id 2C1B9100B9887 for <trustedbsd-audit@freebsd.org>; Mon, 12 Aug 2019 15:50:59 -0700 (PDT) From: "Dan O'Donnell" <dano@well.com> Content-Type: multipart/signed; boundary="Apple-Mail=_89CE0695-66E1-4F12-A667-81CFA56B1E76"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: Re: Audit Pipe Drops Date: Mon, 12 Aug 2019 15:50:57 -0700 References: <5247B21D-FB16-4949-85E5-9D0D8B37908C@intraversal.de> <10BE768D-32B6-4457-9A77-8144B941F566@intraversal.de> <0e9ca039cfc2d4cc860b08c40e2bfdbdf660e30e.camel@inhio.net> To: trustedbsd-audit@freebsd.org In-Reply-To: <0e9ca039cfc2d4cc860b08c40e2bfdbdf660e30e.camel@inhio.net> Message-Id: <24140A96-3C1C-4168-9AEE-B9787C9FC7A6@well.com> X-Mailer: Apple Mail (2.3445.9.1) X-Greylist: inspected by milter-greylist-4.5.12 (xmx.well.com [172.30.1.105]); Mon, 12 Aug 2019 15:51:01 -0700 (PDT) for IP:'172.30.1.200' DOMAIN:'zimbra.well.com' HELO:'zimbra.well.com' FROM:'dano@well.com' RCPT:'' X-Rspamd-Queue-Id: 466rft48Cdz46hX X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=fail (rsa verify failed) header.d=well.com header.s=6EE067AA-1511-11E5-BE77-89F1327358AA header.b=grO2C4Y9; dmarc=none; spf=pass (mx1.freebsd.org: domain of dano@well.com designates 52.0.124.244 as permitted sender) smtp.mailfrom=dano@well.com X-Spamd-Result: default: False [-4.74 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_DKIM_REJECT(1.00)[well.com:s=6EE067AA-1511-11E5-BE77-89F1327358AA]; R_SPF_ALLOW(-0.20)[+ip4:52.0.124.244]; HAS_ATTACHMENT(0.00)[]; TO_DN_NONE(0.00)[]; MV_CASE(0.50)[]; RCVD_IN_DNSWL_MED(-0.20)[244.124.0.52.list.dnswl.org : 127.0.5.2]; DKIM_TRACE(0.00)[well.com:-]; NEURAL_HAM_SHORT(-0.98)[-0.980,0]; SIGNED_PGP(-2.00)[]; FROM_EQ_ENVFROM(0.00)[]; IP_SCORE(-0.66)[asn: 14618(-3.27), country: US(-0.05)]; MIME_TRACE(0.00)[0:+,1:+,2:+,3:~,4:~]; ASN(0.00)[asn:14618, ipnet:52.0.0.0/15, country:US]; RCVD_TLS_LAST(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.20)[multipart/signed,multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[trustedbsd-audit@freebsd.org]; DMARC_NA(0.00)[well.com]; RCPT_COUNT_ONE(0.00)[1]; RCVD_COUNT_SEVEN(0.00)[7] X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: trustedbsd-audit@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TrustedBSD Audit Discussion List <trustedbsd-audit.freebsd.org> List-Unsubscribe: <https://lists.freebsd.org/mailman/options/trustedbsd-audit>, <mailto:trustedbsd-audit-request@freebsd.org?subject=unsubscribe> List-Archive: <http://lists.freebsd.org/pipermail/trustedbsd-audit/> List-Post: <mailto:trustedbsd-audit@freebsd.org> List-Help: <mailto:trustedbsd-audit-request@freebsd.org?subject=help> List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/trustedbsd-audit>, <mailto:trustedbsd-audit-request@freebsd.org?subject=subscribe> X-List-Received-Date: Mon, 12 Aug 2019 22:51:03 -0000 --Apple-Mail=_89CE0695-66E1-4F12-A667-81CFA56B1E76 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 FWIW I do not have an answer either but am also very interested in the = answer. During BSidesLV last week there was a session about fooling OSX into = giving up privileged access [1]. In the Q&A that followed the first = question was =E2=80=9Cwill BSM capture this?=E2=80=9D The speaker had no = idea what BSM is/was so hadn=E2=80=99t tested and couldn=E2=80=99t = answer, but I thought that is a really good question. And it is a really good question in light of this, the basic supposition = and question: >>> 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. [1] https://www.bsideslv.org/schedule-2/ = <https://www.bsideslv.org/schedule-2/> Day 1 / Breaking Ground / Unpacking pkgs: a look inside macOS installer = packages and common security flaws We are hackers, we won=E2=80=99t do as you expect or play by your rules, = and we certainly don=E2=80=99t trust you. JAR files are really = ZIPs=E2=80=A6unzip them! So are DOCX, XLSX, PPTX, etc. Open them up! = macOS applications (.app =E2=80=9C=E2=80=9Dfiles=E2=80=9D=E2=80=9D) are = really browsable directories?! Sweet, let=E2=80=99s do that. Less well known but similarly prevalent are Flat Package Mac OS X = Installer (.pkg) files. These are actually XAR archives containing many = plaintext files (including scripts) with plenty to examine without = installing. In this presentation I=E2=80=99ll walk through extracting the contents = of these installer packages, understanding their structure, and how they = work while highlighting where security issues can come up. To drive the = point home of what can go wrong, I=E2=80=99ll include examples of = security issues I=E2=80=99ve seen in the wild and show how they can be = exploited to elevate privileges and gain code/command execution. After this talk, .pkg files will no longer be opaque blobs to you. = You=E2=80=99ll walk away knowing tools and techniques to examine, = understand what they=E2=80=99re really doing, and a methodology for = finding bugs in them. As a final bonus, I=E2=80=99ll include a subtle = trick or two that can be used on red teams. > On Aug 11, 2019, at 7:10 AM, ASV <asv@inhio.net> wrote: >=20 > 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. >=20 > Good luck. >=20 >=20 >=20 > 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 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 >>=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" --Apple-Mail=_89CE0695-66E1-4F12-A667-81CFA56B1E76 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.2 Comment: GPGTools 2.5.1 (build 1044) - https://gpgtools.org iQIzBAEBCgAdFiEE9dMnT0tAdaBButXPLFgDC1jkEL4FAl1R7VEACgkQLFgDC1jk EL46vQ/9HrLFuIArA62W1BKO4eOjL8v6+BVBibDREGwJ5ctFV7aWd+CWntpsMzlm UnqWc4ZzoiWqlKHy0wrd/jTPn+HLw1J46KdG0etWVZ8umGG3iPJMUgPxixr+jxS9 hiPuZ57s6+n4xVn8OBZcYpEmsUO4gEwSEKB5+7Mqsiht3SxG3lETPUuX56EF/xiI VmmAJsdJgQuL+QnYTvGPV4na0Nx6R3d9GmWDLer0j7ItBnUl2IubfSvesZrig9Cd Jf9tIx116AGItgUg6985wETuL66tXbf1zmEEmQC474kvhH1NoEPjTLelqtzVvD7S I5xsk4ALnb9v0qoIMyMzvaEkKLt2C8e91j6u6CvWNrCwpjzKkjLveVvx+ldCTqkK RGlNAFtk7xC11vC6FaUhHJJ27rrFkGx6sj4KZOwwqKs8nW1NZWAD04bVRI9reNjQ 6F+nUBmZCOJgxsGCQtZShvvIwQ5niC5Gi+V9kUTi4HONNB8Yicb66ZrBxBZVTIDm 9tZxW6sgujvH9ZYpLS44LqWa2396iX72z+OWcP+Scoetq37dmY03BCYAmU2D+l4+ EFGZmThCK7UVpU056bfN8Ln5PdYjcsF1lYTeQypMZONWKiGgDMarvwESuT3+3Esy iDoHMpsLg81Gjf8ibA5qWJaR+JW1RIGae0D/x0oFJDyct7+UMCY= =cVMZ -----END PGP SIGNATURE----- --Apple-Mail=_89CE0695-66E1-4F12-A667-81CFA56B1E76--