> From: linux-sgx-owner@xxxxxxxxxxxxxxx [mailto:linux-sgx- > owner@xxxxxxxxxxxxxxx] On Behalf Of Stephen Smalley > Sent: Friday, June 28, 2019 9:37 AM > > > lsm.ema.cache_decisions is on by default and > > could be turned off by appending “lsm.ema.cache_decisions=0” or > > “lsm.ema.cache_decisions=off” to the kernel command line. > > This seems problematic on a few fronts: > > - Specifying it as a boot parameter requires teaching admins / policy > developers to do something in addition to what they are already doing > when they want to create policy, > > - Limiting it to a boot parameter requires a reboot to change the mode > of operation, whereas SELinux offers runtime toggling of permissive mode > and even per-process (domain) permissive mode (and so does AppArmor), How about making a variable tunable via sysctl? > > - In the cache_decisions=1 case, do we get any auditing at all? If not, > that's a problem. We want auditing not only when we are > generating/learning policy but also in operation. Currently it doesn't generate audit log, but I could add it, except it couldn't point to the exact file. But I can use the sigstruct file instead so administrators can at least tell which enclave violates the policy. Do you think it acceptable? > > - There is the potential for inconsistencies to arise between the > enforcement applied with different cache_decisions values. The enforcement will be consistent. The difference only lies in the logs. > > I would suggest that we just never cache the decision and accept the > cost if we are going to take this approach. This will also be a viable option. I don't think any enclaves would be comprised of a large number of files anyway. When SGX2 comes up, I think most enclaves will be instantiated from only one file and defer loading libraries at runtime. So in practice we are looking to keeping only one file open per enclave, which seems totally acceptable. Stephen (and everyone having an opinion on this), which way do you prefer? sysctl variable? Or never cache decisions?
