How to bring au_to_attr(3) back to the userland?

[Robert N. M. Watson]

Hi Mateusz:

I’m hear about your project — 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’s 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 — unfortunately, not all of the fields we require (in particular the filesystem ID) are present in the stat structure.

I’m slightly unhappy with the name vnode_au_info, as although in FreeBSD, Mac OS X, and Solaris, “vnode” is the term used, that’s not portable to Linux, where the term “inode” is used. We also want to avoid being almost but not quite API compatible with the Solaris BSM API — 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 “vnode attribute token”, but avoid confusion about function signatures / prototypes / types. I think I’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, …) 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 at FreeBSD.org> wrote:
> 
> Hello,
> 
> 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]).
> 
> 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]).
> 
> 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.
> 
> Solutions:
> 
> 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.
> 
> (See sys/security/audit/bsm_token.c[2].)
> 
> 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`.
> 
> At the moment `struct vattr` is included in sys/vnode.h but it lacks the
> interace.
> 
> (I summed up everything I know on this wiki page[3].)
> 
> 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).
> 
> Cheers,
> 
> -Mateusz
> 
> [0]: https://wiki.freebsd.org/SummerOfCode2016/NonBSMtoBSMConversionTools
> [1]: https://lists.freebsd.org/pipermail/freebsd-hackers/2016-August/049835.html
> [2]: https://github.com/freebsd/freebsd/blob/af3e10e5a78d3af8cef6088748978c6c612757f0/sys/security/audit/bsm_token.c#L1281-L1405
> [3]: https://github.com/0mp/freebsd/wiki/vattr(99://github.com/0mp/freebsd/wiki/vattr(99)
>