Brand spoofing

From Erights

Jump to: navigation, search

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.
Personal tools
more tools