From owner-trustedbsd-discuss@freebsd.org Fri Sep 23 10:09:36 2016 Return-Path: Delivered-To: trustedbsd-discuss@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D1F14BE5A6F; Fri, 23 Sep 2016 10:09:36 +0000 (UTC) (envelope-from def@FreeBSD.org) Received: from troz.pl (troz.pl [37.187.125.115]) by mx1.freebsd.org (Postfix) with ESMTP id 87BE9B53; Fri, 23 Sep 2016 10:09:35 +0000 (UTC) (envelope-from def@FreeBSD.org) Received: from [192.168.81.123] (unknown [109.111.229.194]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by troz.pl (Postfix) with ESMTPSA id 9D22B409; Fri, 23 Sep 2016 12:09:34 +0200 (CEST) Subject: Re: How to bring au_to_attr(3) back to the userland? To: "Robert N. M. Watson" , Mateusz Piotrowski <0mp@FreeBSD.org> References: <83CC669E-FED9-4ABE-A5A5-376E1A743AF8@FreeBSD.org> <09D137C4-2630-4B93-ACDC-CB3AFC86D89F@FreeBSD.org> <93122C2D-A660-4A47-A780-44E8309E4377@FreeBSD.org> Cc: freebsd-hackers@freebsd.org, trustedbsd-discuss@freebsd.org, trustedbsd-audit@freebsd.org From: Konrad Witaszczyk Message-ID: <08154690-df05-9314-702e-4e0cdd661f04@FreeBSD.org> Date: Fri, 23 Sep 2016 12:09:30 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <93122C2D-A660-4A47-A780-44E8309E4377@FreeBSD.org> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="tqie9SOJmMNO0r42m8w0uJ24GwhGngFil" X-BeenThere: trustedbsd-discuss@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: TrustedBSD General Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Sep 2016 10:09:36 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --tqie9SOJmMNO0r42m8w0uJ24GwhGngFil Content-Type: multipart/mixed; boundary="QhWplOJG4rl41lSBCn4LIBfPPjGLtLTmM"; protected-headers="v1" From: Konrad Witaszczyk To: "Robert N. M. Watson" , Mateusz Piotrowski <0mp@FreeBSD.org> Cc: freebsd-hackers@freebsd.org, trustedbsd-discuss@freebsd.org, trustedbsd-audit@freebsd.org Message-ID: <08154690-df05-9314-702e-4e0cdd661f04@FreeBSD.org> Subject: Re: How to bring au_to_attr(3) back to the userland? References: <83CC669E-FED9-4ABE-A5A5-376E1A743AF8@FreeBSD.org> <09D137C4-2630-4B93-ACDC-CB3AFC86D89F@FreeBSD.org> <93122C2D-A660-4A47-A780-44E8309E4377@FreeBSD.org> In-Reply-To: <93122C2D-A660-4A47-A780-44E8309E4377@FreeBSD.org> --QhWplOJG4rl41lSBCn4LIBfPPjGLtLTmM Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 08/17/2016 08:47, Robert N. M. Watson wrote: > On 17 Aug 2016, at 00:18, Mateusz Piotrowski <0mp@FreeBSD.org> wrote: > >> To sum it up. The idea is to: >> >> 1. Rename vnode_au_info to au_vattr. >> 2. Keep au_to_attr away from the userland. >> 3. Add au_to_vattr (the parameter of which is struct au_vattr) to the = libbsm >> API and make it available to the userland. >> 4. Re-craft au_vattr to use the same types that are present in the und= erlying=20 >> attribute token. >> >> I am not sure if I understand this properly; do we want to simply rena= me=20 >> vnode_au_info to au_vattr and make it available in the userland after = a couple=20 >> of modifications? If so then it sounds like a good idea to me as long = as I don't=20 >> break something accidentally. Wouldn't renaming and modifying struct v= node_au_info=20 >> cause compatibility problems and potentially break someone's software?= > I guess you have two choices: > > (1) Retain existing KPIs to slightly ease merging to FreeBSD and Mac OS= X; they can adopt the new in-kernel interfaces when ready. I think it won't be hard to adopt the changes in the FreeBSD kernel toget= her with the changes in libbsm. Would you still consider it as an issue becau= se of macOS if we fix it in FreeBSD? I don't know how important it is to their developers to stick with the current OpenBSM implementation. > (2) Simply remove the old KPIs and consider it a feature. > > The former probably does marginally ease merging the new OpenBSM versio= n (one fewer kernel changes for FreeBSD and Mac OS X at the point of merg= e), so I see no harm in retaining it. However, as it=E2=80=99s ifdef=E2=80= =99d _KERNEL || KERNEL in the OpenBSM header, it has not been exposed to = user applications, just the kernel. > > Remember that changes in these structures don=E2=80=99t affect the layo= ut and interpretation of the tokens at all =E2=80=94 it=E2=80=99s really = just on the producer side that a KPI changes =E2=80=94 and the informatio= n we=E2=80=99re able to expose. > > The existing vnode_au_info isn=E2=80=99t really an appropriate public i= nterface, so do make sure not to remove the ifdefs preventing its use =E2= =80=94 instead, we should focus on a new interface that is appropriate to= be public by virtue of (a) having an appropriate struct type argument th= at has both the fields we require and is as non-OS-specific as possible; = (b) doesn=E2=80=99t conflict with the current interface on FreeBSD/Mac OS= X; and (c) doesn=E2=80=99t conflict with the current interface on Solari= s. > >> Apart from that it sounds like a reasonable solution. >> >> Thank you very much for the detailed introduction to the complexity of= this problem. >> Although the GSoC is coming to an end and I plan to focus on integrati= ng my work >> into auditdistd, I hope to apply the solutions we discuss here sometim= e later. > The problems are all about compatibility, and I think we have a reasona= ble path here that does what we need without too much work. > > Robert > --QhWplOJG4rl41lSBCn4LIBfPPjGLtLTmM-- --tqie9SOJmMNO0r42m8w0uJ24GwhGngFil Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQJ8BAEBCgBmBQJX5P9bXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRGREI1MzAxNjZGNTBCM0NCRUQ5QjZGNzdF MUMxMjI1QjBCMjZBNEYwAAoJEOHBIlsLJqTwzEIQAKAf2csdzjrIBYmEejXXoUxA 1e1mSyxeDQDNrWvk2xBpfkDsGgJubR7WCpJhm8u7T85D/Dg34e4YYHsuCevMdOEt DVg+cPskSSv/ZE16VYelcUI6lZCJqhB7rsi6E4nislXMVhqUzh4+CxnpOwCrNc5b xaTSYkex/rUFQJosMDM0bHHSep3Nc9a9sBSIaTnZpUemIQYKZPBRYd9TvOlrTWqd 60sMZJBdqyiVPus3boe29kPjrJLRL+LOdJxLyP8/a8/LQUT0DFjn/SHj10UDyWtw jS8LB+eDku0ckMNJtZ9RC8mQ/z0Lp6tDjdPfVwINgtpi82pcUafLgwno5gk4oujE 1/AQWIhKbTdcahA3WivS0AJqYaxk9JZAfTSLyPicmKWCY5Qugt/x3sjfDpjjoNQ6 xE1Ahs4GZTZy8T2bEWB4ZjqxzNBYX3+KvGNvAI+2HhTRWod9XOLZasutgj+zBNGi 8p4zTOTqTWMXPYnDr6Xfw1PwCslLiZVVpWNx75wvuQNss3kUCI9/52iVQZ/9TPAm Mo7R0Egu5Dz6VfwkarxE8bjKiHbqzTbjxSiDuaoUUzbLnYMlQwRWgFwKNyUTvTRD raIgjDAGQQ+ZGbZHUgSRdgy+qR8NBzOa0g2uRicxhZRDrss/sbNEwFTQyOwBGDp4 M7AEV/WF4xdXH9ksejng =NKx4 -----END PGP SIGNATURE----- --tqie9SOJmMNO0r42m8w0uJ24GwhGngFil-- From owner-trustedbsd-discuss@freebsd.org Fri Sep 23 10:19:29 2016 Return-Path: Delivered-To: trustedbsd-discuss@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CDA77BE5F61; Fri, 23 Sep 2016 10:19:29 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [198.74.231.69]) by mx1.freebsd.org (Postfix) with ESMTP id 8ACD4FD6; Fri, 23 Sep 2016 10:19:29 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from [192.168.81.201] (unknown [212.163.6.23]) by cyrus.watson.org (Postfix) with ESMTPSA id ABE2446CF5; Fri, 23 Sep 2016 06:19:27 -0400 (EDT) Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: How to bring au_to_attr(3) back to the userland? From: "Robert N. M. Watson" In-Reply-To: <08154690-df05-9314-702e-4e0cdd661f04@FreeBSD.org> Date: Fri, 23 Sep 2016 11:19:26 +0100 Cc: Mateusz Piotrowski <0mp@FreeBSD.org>, freebsd-hackers@freebsd.org, trustedbsd-discuss@freebsd.org, trustedbsd-audit@freebsd.org Message-Id: References: <83CC669E-FED9-4ABE-A5A5-376E1A743AF8@FreeBSD.org> <09D137C4-2630-4B93-ACDC-CB3AFC86D89F@FreeBSD.org> <93122C2D-A660-4A47-A780-44E8309E4377@FreeBSD.org> <08154690-df05-9314-702e-4e0cdd661f04@FreeBSD.org> To: Konrad Witaszczyk X-Mailer: Apple Mail (2.3124) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: trustedbsd-discuss@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: TrustedBSD General Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Sep 2016 10:19:29 -0000 On 23 Sep 2016, at 11:09, Konrad Witaszczyk wrote: >> I guess you have two choices: >>=20 >> (1) Retain existing KPIs to slightly ease merging to FreeBSD and Mac = OS X; they can adopt the new in-kernel interfaces when ready. >=20 > I think it won't be hard to adopt the changes in the FreeBSD kernel = together > with the changes in libbsm. Would you still consider it as an issue = because of > macOS if we fix it in FreeBSD? I don't know how important it is to = their > developers to stick with the current OpenBSM implementation. While the kernel and userspace share code from OpenBSM in both FreeBSD = and Mac OS X, it=E2=80=99s useful to be able to upgrade userspace = without necessarily changing kernel code =E2=80=94 e.g., if security = patches are required in parsing, etc. I think it would be best to = differentiate the new programming interface by giving it a new name, and = keeping the existing interface, but marked to be removed at a future = date. We could even discourage its use by making if #ifdef = OPENBSM_DEPRECATED or such, requiring that it be explicitly enabled to = be available to hint to those doing merges that it=E2=80=99s time to = move to the new KPI. Robert=