On 1/15/20 10:56 AM, Wenhui Zhang wrote:
On Wed, Jan 15, 2020 at 10:33 AM Stephen Smalley <sds@xxxxxxxxxxxxx <mailto:sds@xxxxxxxxxxxxx>> 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.
