The <a href=index.html>Capsicum paper</a> mentioned a security bug reported <a href=http://www.securityfocus.com/bid/1322>here</a> which is instructive for some consequences of security intersection policies.
The application behaved correctly in the system for which the app was designed.
On a system with more restrictions, the app misbehaved so as to grant illegitimate authority!
It made a system call to reduce its authority, passing as parameter a bit map that described what it assumed to be a subset of its current authority.
That assumption was correct for the system for which it had been designed.
The new policy had reduced the app’s authority thus invalidating the assumption.
The kernel observed the discrepancy and since it could not provide the new requested authority it nullified the call and returned an error code leaving the higher authority as it was.
The app the proceeds to give control to code that was then able to exploit authority it should not have had.
<p>General rules are good and perhaps the general rule that a request of the kernel should be nullified when parameters are invalid is a good one.
In this particular case, however, it would have been better for the kernel to set privileges to the intersection of requested authority and current authority.
<p>The Keykos capability invocation mechanism provides an option to receive the return code, and if this option is not taken and the real return code is not zero, then the domain ceases to obey the program.
The program can code the easiest invocation and not accept the return code when there is nothing to do upon failure.
In such a case, nothing is indeed done.
The domain keeper does get notified which can produce a generalized vague failure notification.