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