[PATCH 25/27] NET: Add SO_PEERCONTEXT for multiple LSMs

[Casey Schaufler]

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