[PATCH 00/97] LSM: Complete module stacking

[Casey Schaufler]

On 3/1/2019 6:17 AM, Stephen Smalley wrote:
> On 2/28/19 5:17 PM, Casey Schaufler wrote:
>> This is a preliminary version of the complete stacking
>> implementation. The patches need to be cleaned up, and
>> several are not strictly necessary. There is likely to
>> be work required in the audit sub-system. It does address
>> all the shared data, including CIPSO headers. It should
>> handle CALIPSO once Smack supports it. I will be revising
>> the set after 5.1.
>>
>> Complete the transition from module based blob management
>> to infrastructure based blob management. This includes
>> the socket, superblock and key blobs.
>>
>> Change the LSM infrastructure from exposing secids to
>> exposing an opaque "lsm_export" structure that can contain
>> information for multiple active security modules. Update
>> all of the security modules to use information from the
>> lsm_export structure. Update the LSM interfaces that expose
>> secids for more than one module to use the export structure.
>> Update all the users of these interfaces.
>>
>> Change the LSM infrastructure from using a string/size pair
>> for security "contexts" to a "lsm_context" structure that
>> can represent information for multiple modules. This contains
>> information that allows the "context" to be properly freed
>> regardless of where it is allocated and where it is used.
>>
>> Add an interface to identify which security module data
>> should be presented with SO_PEERSEC. /proc/.../attr/display
>> will set and report the name of the LSM for which the
>> security_secid_to_secctx() will use to translate to text.
>> If it is not explicitly set, the first security module that
>> supplies secid (now lsm_export) interfaces will be used.
>> To ensure consistency, a set of module hooks dealing with
>> the secid/context processing is maintained with each process
>> that explicitly sets it.
>>
>> Before sending a network packet verify that all interested
>> security modules agree on the labeling. Fail if the labeling
>> cannot be reconciled. This requires a new Netlabel interface
>> to compare proposed labels, and a change to the return values
>> from the existing netlabel attribute setting functions.
>
> Have you run any benchmarks to assess the performance impact of these 
> changes?

Nothing I can publish. Benchmarking is getting close
to the top of the list.