Re: Preferred subj= with multiple LSMs

On Mon, 22 Jul 2019 at 18:30:35 -0400, Paul Moore wrote: Does this include the restriction "the label does not include \0", which is an assumption that dbus is already relying on since I checked it in the thread around <https://marc.info/?l=linux-security-module&m=142323508321029&w=2&... Or is that restriction so fundamental that it's considered OK? (Other user-space tools like ls -Z and ps -Z also rely on that assumption by printing security contexts with %s, as far as I know.) dbus does not require a way to multiplex multiple LSMs' labels in a printable text string, so from my point of view, multiplexed labels do not necessarily have to be in what Casey calls the "Hideous" format, or in any text format at all: anything with documented rules for parsing (including the unescaping that readers are expected to apply, if there is any) would be fine. Based on the assumption of no "\0", I previously suggested a "\0"-delimited encoding similar to /proc/self/cmdline, which would not need any escaping/unescaping: "apparmor\0" <apparmor label> "\0" "selinux\0" <SELinux label> "\0" ... "\0" (or this could be omitted since it's redundant with the length) which would be fine (indeed, actually easier than the "Hideous" format) from dbus' point of view. dbus does not strictly need reading security labels for sockets or processes to be atomic, either: it would be OK if we can get the complete list of LSM labels *somehow*, possibly in O(number of LSMs) rather than O(1) syscalls (although I'd prefer O(1)). However, the getsockopt() interface only lets the kernel return one thing per socket option, and I assume the networking maintainers probably don't want to have to add SO_PEERAPPARMOR, SO_PEERSELINUX... for each LSM - so this part at least would probably be easier as a single blob in some text or binary format. smcv