On 7/29/2019 6:00 AM, Simon McVittie wrote:
> On Fri, 26 Jul 2019 at 16:39:21 -0700, Casey Schaufler wrote:
>> A new option SO_PEERCONTEXT is added to report the
>> security "context" of multiple modules using a "compound" format
>>
>> lsm1\0value\0lsm2\0value\0
>> + /*
>> + * A compound context, in the form lsm='value'[,lsm='value']...
>> + */
> Presumably the commit message (and the implementation) means the comment
> is out of date?
Yup. The curse of incremental development.
>> + /*
>> + * Don't propogate trailing nul bytes.
>> + */
>> + clen = strnlen(cp, clen) + 1;
>> + tlen = llen + clen;
> ...
>> + memcpy(tp + finallen + llen, cp, clen);
> This assumes that cp points to a '\0'-terminated string, with the '\0'
> either inside the span of memory cp[clen]..cp[clen-1], or at cp[clen]
> (which is just outside the range that is obviously safe to access).
> Is that assumption robust?
James Morris, the security subsystem maintainer, says:
"Security labels are strings, so this is implied."
> If an LSM that worked with length-counted
> ("Pascal") strings internally would be allowed to fill the buffer with
> nonzero bytes and not place a '\0' immediately after it, then it would
> be necessary to insert the NUL explicitly:
True enough. I could use an embedded length format:
[<lsmname\0><valuesize-u16><value>]...
but as James is willing to assert that security labels are strings
I don't think we need to go that far.
>
> clen = strnlen(cp, clen);
> tlen = llen + clen + 1;
> ...
> memcpy(tp + finallen + llen, cp, clen);
> tp[finallen + llen + clen] = '\0';
>
> Thanks,
> smcv
