Re: Avoiding IBAC
Domenico Rotondi <[email protected]>
| Newsgroups | gmane.comp.capabilities.general |
|---|---|
| Message-ID | <[email protected]> |
On 14 Oct 2014 at 22:28, Karp, Alan H wrote: Hi, a possibility is to use capabilities with "conditional constraints" in them, like the Google Macaroons approach that supports the embedding of "constraints" that can limit the "firing" of a capability. Among the "conditions" there could be also some that make possible to violate the general policy in specific conditions (or on explicit Alice request). Ciao Domenico > The key point OwnCloud is missing is the fact that there are often good reasons to violate policy. Which is more likely to get you fired, violating a security policy or losing an important customer? If you don't give people a safe way to violate policy when they must, such as VOC, they will use unsafe mechanisms, such as sharing credentials. At any rate, if OwnCloud insists on implementing this policy, there are any number of Data Loss Prevention systems they can buy. > > Of course, that doesn't answer your question, does it? The approach used by PubShare does. Each object supports a delegate method that takes a reference to the delegatee as an argument. All the delegate method needs is the policy to enforce, e.g., a way to distinguish people inside the company from people outside. The nice thing about this approach is that the easy way is the secure way, so there's no incentive for people to find a workaround. > > ________________________ > Alan Karp > Principal Scientist > Enterprise Services, Office of the CTO > Hewlett-Packard Company > 1501 Page Mill Road > Palo Alto, CA 94304 > 1 (650) 386-4568 > http://www.hpl.hp.com/personal/Alan_Karp > > > _______________________________________________ > cap-talk mailing list > [email protected] > http://www.eros-os.org/mailman/listinfo/cap-talk