[PATCH v14 22/23] LSM: Add /proc attr entry for full LSM context

[Casey Schaufler]

On 2/4/2020 5:37 AM, Stephen Smalley wrote:
> 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. 

An user-space that makes invalid assumptions about an interface
can't implicitly define the behavior of that interface. You can't
declare that "current" is defined to be a string just because a
developer looked at how one security module uses it and coded the
application accordingly. You can't declare that "current" will
always be a SELinux context. That horse left the barn in 2007,
and there are still people writing code assuming that is what
they're getting.

If the sub-system maintainer, James Morris, is willing to state that
"current" must have a particular format that would be different.

> 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.

Yup. And so far no security module has been foolish enough to export
a binary blob in a /proc/.../attr interface. That doesn't mean that
the interface is defined as a string. It's certainly the convention,
but nowhere is it documented as a requirement.

That's why I'm putting in the effort to define the format for "context"
and SO_PEERCONTEXT. Interfaces at the LSM level need to be defined so as
to allow the underlying security modules to provide the information they
want in a way that is unambiguous and application non-hostile. The help
I've gotten from you and the rest of the reviewers over the life of this
effort has been extremely helpful, if not always easy to swallow.

>
>> 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".
>
>