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

[Casey Schaufler]

On 2/11/2020 9:58 AM, John Johansen wrote:
> On 2/11/20 7:59 AM, Stephen Smalley wrote:
>> On 2/10/20 2:00 PM, John Johansen wrote:
>>> On 2/10/20 10:32 AM, Casey Schaufler wrote:
>>>> Because attr/context (and later, SO_PEERCONTEXT) are new interfaces
>>>> there is no need to exactly duplicate what is in attr/current (later
>>>> SO_PEERSEC). I already plan to omit the "mode" component of the
>>>> AppArmor data in the AppArmor hook, as was discussed earlier. I would
>>>> prefer ASCII, but if AppArmor needs bytestrings, that's what we'll
>>>> have to do.
>>>>
>>>
>>> sadly, to not break userspace its a byte string because that is what the path based profile names are. AppArmor does support a more limited non path based profile name but I can't guarantee that is what userspace is using in policy.
>>
>> Ok, so /proc/pid/attr/context and SO_PEERCONTEXT have to be defined as returning bytestrings.
>>
>> So far we've talked about having AppArmor drop the trailing newline, be consistent with regard to whether the terminating NUL is included or excluded, and drop the mode field from what it returns for /proc/pid/attr/context and SO_PEERCONTEXT versus the current /proc/pid/attr/current and SO_PEERSEC.  Is that correct?
>>
>> How do we envision a liblsm processing the value returned from /proc/pid/attr/context or SO_PEEERCONTEXT?  

There hasn't been any serious thought put into liblsm. To date
there hasn't been an LSM level interface to worry about except
for /sys/kernel/security/lsm. My notions of what a liblsm ought
provide would seem archaic to most of the people here. I can make
proposals if there's a notion that liblsm makes sense.


>> It can certainly split it up per LSM.  But can it then take the apparmor portion of the context and pass that to existing libapparmor interfaces without breakage?  Or will the changes to the format described above create issues there?
>>
>>
> libapparmor can handle the changes. It does not require the mode string, currently anything unconfined does not include it, and we have already done experiments with dropping it in other cases. The trailing '\n' is handled conditionally so only if its there; this is well tested as the currently out of upstream af_unix socket mediation that is used by dbus does not include a trailing '\n' on the SO_PEERSEC.

So it doesn't seem that there would be significant difficulties
switching from "current" to "context". It won't be transparent,
but we're providing "display" to address that.