Date: Tue, 16 Aug 2016 07:58:22 +0100 From: "Robert N. M. Watson" <rwatson@FreeBSD.org> To: Mateusz Piotrowski <0mp@FreeBSD.org> Cc: freebsd-hackers@freebsd.org, trustedbsd-audit@freebsd.org, trustedbsd-discuss@freebsd.org, Konrad Witaszczyk <def@freebsd.org> Subject: Re: How to bring au_to_attr(3) back to the userland? Message-ID: <09D137C4-2630-4B93-ACDC-CB3AFC86D89F@FreeBSD.org> In-Reply-To: <83CC669E-FED9-4ABE-A5A5-376E1A743AF8@FreeBSD.org> References: <83CC669E-FED9-4ABE-A5A5-376E1A743AF8@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi Mateusz: 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. 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. 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. 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. 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). Not sure you how you feel about that strategy? Robert > On 15 Aug 2016, at 23:18, Mateusz Piotrowski <0mp@FreeBSD.org> wrote: >=20 > Hello, >=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 > Cheers, >=20 > -Mateusz >=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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?09D137C4-2630-4B93-ACDC-CB3AFC86D89F>