Re: Avoiding IBAC

You are on the verge of re-inventing Voluntary Oblivious Compliance (VOC), which is something Alan Karp devised years ago to get as close to your goal as is actually possible.

Alice can always share a file with anyone she wants by sending it in email, by taking a screenshot with her phone, etcetera. It seems from your email that you already understand this, but just to be clearly, understand that your goal is only to prevent Alice from accidentally sharing with someone outside the realm of people to be trusted with the file (and think more flexibly than just in terms of inside-versus-outside the company, that particular separator is interesting, but neither the only separator nor even in some cases the most interesting. The separator between "people inside HR" versus "outside HR" may often be more relevant from a legal perspective for private employee data, for example, and "inside the cross-corporate supersecret team" versus "outside the supersecret team" is an
 other one).

Anyway, since Alice can always dodge your access enforcement, her compliance is Voluntary. Since the policy about which files fall into which policies may be complex, you want it to be Oblivious. And of course you want her to achieve Compliance.

Once you have accepted that compliance is Voluntary (as you seem to have done, demonstrating rare insight :-), the sensible strategy is somewhat different. You do not want to make a strict prohibition. Rather, you want to enable people to get their work done by doing unlikely things in unlikely situations, but with awareness that they are violating policy. So you would warn the user, change the affordance add a step in the UI to do the sharing, and then maintain full accountability tracking.

To see an example of a sharing system that is just a tweak away from implementing VOC using ocaps, take a look at PubShare on YouTube at https://www.youtube.com/watch?v=LJ8FPM1_uTA. When you delegate in PubShare, you can either type in the email address of a person to whom to send the webkey, or you can pick the person off a drop-down list of possible recipients. Now, suppose that the drop-down list is not merely a convenience but is rather a VOC mechanism, and the people  in the drop-down list are the only pre-authorized recipients. In your sample situation, the dropdown would contain all company employees. So, if you pick someone from the list and Delegate, the delegation just happens. But if you type in the name of someone who is not on the list, it opens a small window saying, "this au
 thority is not supposed to be shared outside the list of people in the dropdown box. If you want to share it anyway, please enter a justification here." If the person fills out a justificat!
 ion and clicks "Yes, share outside the pre-authorized possible recipients", then it sends the delegate webkey like normal.

A more general way of describing this is, the key moment in managing VOC with ocaps is the moment when you are making the grant. If the user interface supplies sufficient support for the operation of making/delivering the grant, you have a place to stand and assess whether the user is following policy, and offer guidance.

BTW, this winds up looking a lot like the military's rules of both putting things in compartments and then also requiring Need to Know. The compartment is represented in the above example by the drop-down list, and the need-to-know is represented by the act of delegating.

--marcs

-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of Neal H. Walfield
Sent: Tuesday, October 14, 2014 1:20 PM
To: [email protected]
Subject: [cap-talk] Avoiding IBAC

Hi,

I was recently talking to some OwnCloud people.  They are building a DropBox-like service for companies.  One access control policy that they want to support appears to require IBAC: they want to allow certain files to be shared with people in the same company, but not people from outside the company.  Concretely, Alice should be able to share a file with her co-worker Bob, but not be able to share it with her colleague Carol at another company.  (Note: in this scenario, Alice is not malicious.  The goal is to stop her from making a
mistake.)  I was trying to figure out how to do this with capabilities, but I haven't come up with a solution.  Or perhaps, the policy needs to be rephrased.

Thoughts?

Thanks,

Neal
_______________________________________________
cap-talk mailing list
[email protected]
http://www.eros-os.org/mailman/listinfo/cap-talk