On Thu, 30 Jan 2003 16:02, Jesse Pollard wrote: > > Question for Casey & other Orange Book folk: the above proposal > > *assumes* that it is C2 compliant to do checks in this order: > > > > 1. error checks (no audit records if they fail) > > 2. DAC checks (audit records) > > 3. MAC checks (audit records) > > > > Does this assumption hold? > > I though it would switch 2 and 3: > 1. error checks (no audit records if they fail) > This refers to the request error (improper buffer, request out of range, > ...) 2. MAC checks (audit records) > Because some MAC checks can immediately deny access > 3. DAC checks (audit records) > The usual stuff. > > Note: there is still the problem of capabilities overriding evaluations of > 2 and 3 results. How can capabilities override MAC checks? We have DAC_OVERRIDE capability but no MAC_OVERRIDE... > The practical choice of order would likely depend on the frequency of > failure. It is faster to abort an operation as early as possible, with the In which case MAC should be done first. For my systems I believe that the vast majority of permission denied results from system calls concern /proc which has little protection in DAC but lots of protection in SE Linux. Every time "ps", "top", or "lsof" are run many operations are denied. > cautionary note that if the MAC checks are done second, then it is possible > to determine what the DAC values existing on an object without violating > MAC, and hence providing a data leak. What exactly do you mean by this? -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page _______________________________________________ linux-security-module mailing list linux-security-moduleat_private http://mail.wirex.com/mailman/listinfo/linux-security-module
This archive was generated by hypermail 2b30 : Thu Jan 30 2003 - 07:17:41 PST