On 2/3/20 4:39 PM, Casey Schaufler wrote:
On 2/3/2020 11:37 AM, Stephen Smalley wrote:
BTW, I think the above guarantees with the exception of no trailing whitespace and whether the NUL byte is included or excluded from length are in reality also required for "current" (and SO_PEERSEC) or existing userspace will break.
The behavior of interfaces (e.g. "current", "exec") that are module defined
is only of concern with respect to to "display" behavior. If a security module
wants to provide a variable size binary blob in "current" I would object on
principle, but policy as I understand it has long been that if the authors want
to do that, it's their call.
Doing so would break existing userspace (not just LSM-specific
userspace), so I think it would be a deal breaker even for new security
modules to move away from those guarantees for "current" at least.
procps-ng (and I think procps before it) directly reads
/proc/pid/attr/current and truncates at the first unprintable character.
systemd's sd-bus reads /proc/pid/attr/current directly and treats \n,
\r, or \0 byte as terminators and truncated on first occurrence. A
variety of userspace code uses the value obtained from
/proc/pid/attr/current and/or SO_PEERSEC as something that it can pass
to printf-like functions using a %s specifier for inclusion in logs and
audit messages.
The "context" has a defined format, and it would
be up to the authors to come up with a printable ASCII representation of the
binary blob. If they care. They're not required to provide a "context".
