Perf Data on LSM in v5.3

[Stephen Smalley]

On 1/15/20 10:56 AM, Wenhui Zhang wrote:
> 
> 
> On Wed, Jan 15, 2020 at 10:33 AM Stephen Smalley <sds at tycho.nsa.gov 
> <mailto:sds at tycho.nsa.gov>> wrote:
>     Could be bottleneck changes, could be the fact that your kernel config
>     changes aren't limited to CONFIG_SECURITY* (e.g. PTI introduces
>     non-trivial overheads), could be changes to LSM since that time (e.g.
>     stacking support, moving security_ calls out-of-line, more hooks, ...),
>     could be that running SELinux w/o policy is flooding the system logs
>     with warnings or other messages since it wasn't really designed to be
>     used that way past initialization.  Lots of options, can't tell without
>     more info on your details.
> 
<snip>
> 
> Yup, seems like there used to be 29 hooks back 20 years ago, and now we 
> have 214 hooks with more placement locations for each.
> I am still struggling with the white-list based stacking logic, please 
> correct me if my understanding is wrong.

I don't think that's entirely accurate, since I believe the benchmarking 
performed for that paper was done using the LSM kernel patch (which was 
still out-of-tree at the time) which had a larger set of hooks than just 
29.  The hooks were incrementally merged to mainline but that wasn't the 
basis for the benchmarks IIRC. It is true however that the set of hooks 
and their callers has grown over time.

> I thought black-list  (i.e. firewall alike) logic might be easier to 
> understand and reasoning about the performance.
> By adding an off-line policy conflict/shadowing/redundant checker (i.e. 
> FIREMAN alike) should solve the rest of the issue.

Not sure I follow, but blacklisting is not a good approach for enforcing 
MAC security goals.