> From: Stephen Smalley [mailto:stephen.smalley@xxxxxxxxx] > Sent: Friday, June 28, 2019 6:22 PM > > On Fri, Jun 28, 2019 at 5:54 PM Xing, Cedric <cedric.xing@xxxxxxxxx> > wrote: > > > > > 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? > > Better than a boot parameter but still not amenable to per-domain > permissive and still requires admins to remember and perform an extra > step before collecting denials. > > > > > > > > > - 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? > > Seems prone to user confusion and lacks precision in why the denial > occurred. > > > > > > > > > - 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? > > I'd favor never caching decisions. Alright, I'll remove the boot parameter and never cache decisions.
