From owner-freebsd-hackers@freebsd.org Tue Aug 16 23:18:21 2016 Return-Path: Delivered-To: freebsd-hackers@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 90640BBCBF3; Tue, 16 Aug 2016 23:18:21 +0000 (UTC) (envelope-from mpp302@gmail.com) Received: from mail-wm0-f68.google.com (mail-wm0-f68.google.com [74.125.82.68]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 32C601C9A; Tue, 16 Aug 2016 23:18:20 +0000 (UTC) (envelope-from mpp302@gmail.com) Received: by mail-wm0-f68.google.com with SMTP id i138so18986171wmf.3; Tue, 16 Aug 2016 16:18:20 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=l87CpPKi8pUuB4kp8x3duVb6TRRFyH2CiF12sRrcdFA=; b=Ufo/Pa8xbGIOjzfdu7JQeZ/glqHewuTc6F13E44MIg9WUFPKEK3jokMtBKuF5eCl11 U6o49fpyfneVUrN3Q0lfTQypoxp4/kV/J/bHd0NGwDu6bCGKtI3qIx8EjPdw9cQaB+LE MC7U79U6KVX/1y7ObrE6EH5teuORyz9I7ftlC0VMX+0UfVkDXklPlVkNqzqG8aTsWsd8 BCPdjsixCk5/xlbSXayPr47Qd5sn3deUJo73osGq1jPlfSlw4XUNA1wqm9HG5AL7r5Uq 0UwvGIgGYNT9I6EE1cINhom+jc/HBxr1q+ZxmggskxebgPVQmmbsy+EoUsIJHEFUf8Ao 7nPg== X-Gm-Message-State: AEkoouvA1sVYIROr3N9+os3XnDJuHpH22CItsojD1T+8j8YHg3t/oyo3QZc/rVaarD5eqA== X-Received: by 10.25.210.75 with SMTP id j72mr6165112lfg.4.1471389492594; Tue, 16 Aug 2016 16:18:12 -0700 (PDT) Received: from [192.168.0.15] (87-207-152-10.dynamic.chello.pl. [87.207.152.10]) by smtp.gmail.com with ESMTPSA id 206sm1145084ljj.4.2016.08.16.16.18.11 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 16 Aug 2016 16:18:11 -0700 (PDT) Content-Type: text/plain; charset=utf-8 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: Mateusz Piotrowski <0mp@FreeBSD.org> In-Reply-To: <09D137C4-2630-4B93-ACDC-CB3AFC86D89F@FreeBSD.org> Date: Wed, 17 Aug 2016 01:18:10 +0200 Cc: freebsd-hackers@freebsd.org, trustedbsd-discuss@freebsd.org, trustedbsd-audit@freebsd.org, Konrad Witaszczyk Content-Transfer-Encoding: quoted-printable Message-Id: References: <83CC669E-FED9-4ABE-A5A5-376E1A743AF8@FreeBSD.org> <09D137C4-2630-4B93-ACDC-CB3AFC86D89F@FreeBSD.org> To: "Robert N. M. Watson" X-Mailer: Apple Mail (2.3124) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Aug 2016 23:18:21 -0000 Hello, On 16 Aug 2016, at 08:58, Robert N. M. Watson = wrote: >> On 15 Aug 2016, at 23:18, Mateusz Piotrowski <0mp@FreeBSD.org> wrote: >>=20 >> I participate in Google Summer of Code at FreeBSD this year. My = project is about >> converting Linux Audit logs to the BSM format (see my wiki[0]). >>=20 >> Recently, I've come across a problem with the libbsm(3) API. I'd like = to be able >> to generate an attribute token. Unfortunatelly, au_to_attr which = generates those >> tokens is not available in the userland (I email FreeBSD-hackers at = FreeBSD >> about this issue[1]). >>=20 >> Together with my mentor we came up with a few possible solutions to = this problem >> but we are not sure which one is the best. This is why I'd like to = dicuss the >> pros and cons. >>=20 >> Solutions: >>=20 >> 1. The first idea is to add a userland version of the au_to_attr = function. The >> implementation would be similar to the one of the au_to_exec_* = functions. >>=20 >> (See sys/security/audit/bsm_token.c[2].) >>=20 >> 2. The second idea is to bring back the vattr structure. At the = moment >> au_to_attr has one paramter of type `struct vnode_au_info`. = Historically, >> au_to_attr used `struct vattr`. A possible solution is to bring vattr = to the >> userland and change the parameter of au_to_attr back to `struct = vattr`. >>=20 >> At the moment `struct vattr` is included in sys/vnode.h but it lacks = the >> interace. >>=20 >> (I summed up everything I know on this wiki page[3].) >>=20 >> 3. The last idea is to make `struct vnode_au_info` and `au_to_attr` = accessible >> from the userland (by simply unwrapping the prototypes from the = KERNEL/_KERNEL >> conditional compilation macros). >>=20 >> [0]: = https://wiki.freebsd.org/SummerOfCode2016/NonBSMtoBSMConversionTools >> [1]: = https://lists.freebsd.org/pipermail/freebsd-hackers/2016-August/049835.htm= l >> [2]: = https://github.com/freebsd/freebsd/blob/af3e10e5a78d3af8cef6088748978c6c61= 2757f0/sys/security/audit/bsm_token.c#L1281-L1405 >> [3]: = https://github.com/0mp/freebsd/wiki/vattr(99://github.com/0mp/freebsd/wiki= /vattr(99) >>=20 >=20 > I=E2=80=99m hear about your project =E2=80=94 a way to import Linux = audit records would be extremely useful to the community of BSM users = and tool writers. Thank you. It is really motivating to hear that after a couple of weeks = of starting=20 implementing the conversion over and over again. > My memory is a bit hazy, but I believe the reason we did not stick = with Solaris=E2=80=99s API in this instance is that, in both Mac OS X = and FreeBSD, struct vattr is an in-kernel data structure that = incorporates kernel-internal data types, and is subject to (moderately = frequent) changes in a way that would disrupt the userspace ABI. In more = recent versions of Mac OS X, struct vattr has been replaced with struct = vfs_attr. >=20 > The ideal choice would be to take the existing public data structure = describing file attributes (struct stat) and use that =E2=80=94 = unfortunately, not all of the fields we require (in particular the = filesystem ID) are present in the stat structure. This sounds like the best temporarily idea although the "au_vattr" plan = seems to be much=20 more reasonable to me. > I=E2=80=99m slightly unhappy with the name vnode_au_info, as although = in FreeBSD, Mac OS X, and Solaris, =E2=80=9Cvnode=E2=80=9D is the term = used, that=E2=80=99s not portable to Linux, where the term =E2=80=9Cinode=E2= =80=9D is used. We also want to avoid being almost but not quite API = compatible with the Solaris BSM API =E2=80=94 e.g., having an = au_to_attr(3) that takes a different pointer type is likely a recipe for = trouble. >=20 > As a result, I feel a bit conflicted on the topic, but suspect the = easiest path is to rename vnode_au_info to struct au_vattr, and add a = new API au_to_vattr(3) that accepts a pointer to a new struct au_vattr = pointer. We would continue to not provide an au_to_attr symbol in the = OpenBSM libbsm. This would align us with the Solaris model, accepting = that it is a =E2=80=9Cvnode attribute token=E2=80=9D, but avoid = confusion about function signatures / prototypes / types. I think I=E2=80=99= d also re-craft struct au_vattr a bit to use the same types that are = present in the underlying token (e.g., uint32_t, =E2=80=A6) rather than = OS-local types (e.g., dev_t), in order to force consumers of the API to = cast to the BSM type, rather than having that occur transparently within = OpenBSM, which could cause information loss invisible to the caller = (they should do the information loss for us). >=20 > Not sure you how you feel about that strategy? 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 = underlying=20 attribute token. I am not sure if I understand this properly; do we want to simply rename=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 = vnode_au_info=20 cause compatibility problems and potentially break someone's software? 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 integrating = my work into auditdistd, I hope to apply the solutions we discuss here sometime = later. -Mateusz=