Date: Wed, 17 Aug 2016 01:18:10 +0200 From: Mateusz Piotrowski <0mp@FreeBSD.org> To: "Robert N. M. Watson" <rwatson@FreeBSD.org> Cc: freebsd-hackers@freebsd.org, trustedbsd-discuss@freebsd.org, trustedbsd-audit@freebsd.org, Konrad Witaszczyk <def@freebsd.org> Subject: Re: How to bring au_to_attr(3) back to the userland? Message-ID: <C3FCD083-9DB0-43CA-8C68-A4CCE3BB6636@FreeBSD.org> In-Reply-To: <09D137C4-2630-4B93-ACDC-CB3AFC86D89F@FreeBSD.org> References: <83CC669E-FED9-4ABE-A5A5-376E1A743AF8@FreeBSD.org> <09D137C4-2630-4B93-ACDC-CB3AFC86D89F@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Hello, On 16 Aug 2016, at 08:58, Robert N. M. Watson <rwatson@FreeBSD.org> = 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=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?C3FCD083-9DB0-43CA-8C68-A4CCE3BB6636>