Brand spoofing

Date: 2009-08-15

All timestamps are in EDT, UTC-4. to __optSealedDispatch(brand) { return [ sealer1.getBrand => fn{sealer1.seal(...)}, sealer1.getBrand => fn{sealer1.seal(...)} ] } If they conflict, map will refuse to build and we'll be safely fail-stop. ...
 * [17:43] kpreid: Speaking of which, s/u brands have a problem.
 * [17:43] MarkM_: ?
 * [17:44] MarkM_: I'm redoing them in terms of newTable(true) btw.
 * [17:44] kpreid: Consider in E this: def object implements Auditor1, Auditor2 {
 * [17:44] kpreid:  to __optSealedDispatch(brand) { ... }
 * [17:44] kpreid: }
 * [17:44] kpreid: Suppose that both of those auditors want the object to have a particular optSealedDispatch behavior.
 * [17:44] MarkM_: ok
 * [17:45] kpreid: So, naturally, each one provides a sealer (which has an accompanying brand).
 * [17:45] MarkM_: ok
 * [17:45] kpreid: to __optSealedDispatch(brand) { return switch (brand) {
 * [17:45] kpreid:  match ==(sealer1.getBrand) { sealer1.seal(...) }
 * [17:45] kpreid:  match ==(sealer2.getBrand) { sealer2.seal(...) }
 * [17:45] kpreid: }}
 * [17:46] MarkM_: ok
 * [17:46] MarkM_: hmmm
 * [17:46] MarkM_: right. How does auditor2 know that sealer1.getBrand isn't its brand?
 * [17:46] kpreid: Right.
 * [17:47] kpreid: More generally, even without the auditors:
 * [17:47] kpreid: how does the object know that sealer1 isn't misbehaving to prevent its proper interaction with the clients using #2?
 * [17:48] kpreid: Now, in E-on-Java in the local case, this is actually not a problem...
 * [17:48] kpreid: because the Java type system doesn't let you use anything but the builtin Brands, which only come from builtin Sealers which do not spoof their brands :)
 * [17:48] kpreid: (That only holds if you guard sealer1 :Sealer though)
 * [17:49] kpreid: Anyway, I have no idea what to do about this.
 * [17:49] MarkM_: and if you already know sealer1 != sealer2
 * [17:49] kpreid: Ah.
 * [17:50] kpreid: Dunno if that's an actual hazard case.
 * [17:51] kpreid: Oh, yeah, it is: malicious protocol#1 subsystem (which has sealer2 to participate in sealer2's protocol itself) hands out sealer2 as its sealer1
 * [17:51] kpreid: Thought: The root problem here is this:
 * [17:52] kpreid: The sealed-dispatch-using module is *telling* the constructor of our object "Please respond to this sealed-dispatch request in this way."
 * [17:54] lisppaste2: MarkM_ pasted "safely auditable __optSealedDispatch pattern" at http://paste.lisp.org/display/85456
 * [17:54] kpreid: OK, a local way to fix this is for the object to act like the unsealers-and-box-share-a-variable sealer/unsealer implementation. optSealedDispatch means "Put your stuff in all the boxes you know about"
 * [17:54] kpreid: But that's quite hazardous wrt composition.
 * [17:55] kpreid: Hm, that works.
 * [17:55] MarkM_: cool
 * [17:55] kpreid: Well, for fail-stop.
 * [17:56] MarkM_: I'm happy with fail-stop
 * [17:56] MarkM_: sealer1.getBrand could always infinite loop anyway.
 * [18:09] kpreid: Oh. I missed those ending parens in your sealed dispatch example. Did you mean ...][brand] ?
 * [18:10] kpreid: MarkM_:
 * [18:11] MarkM_: yes
 * [18:11] MarkM_: ..][brand]
 * [18:11] kpreid: Er, right.
 * [18:12] kpreid: Can do the same check before construction, of course.
 * [18:12] kpreid: (though telling auditors you've done that would be tricky.)
 * [18:12] MarkM_: I wouldn't bother.