Brand spoofing

From Erights

Date: 2009-08-15

All timestamps are in EDT, UTC-4.

• [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

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: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.