Brand spoofing

From Erights

(Difference between revisions)
Jump to: navigation, search
m (bit of wikilinking)
(record design discussion)
Line 3: Line 3:
All timestamps are in EDT, UTC-4.
All timestamps are in EDT, UTC-4.
   
   
-
* [17:43] kpreid: Speaking of which, [[makeBrandPair|s/u]] brands have a problem.
+
* [17:43] kpreid: Speaking of which, s/u brands have a problem.
* [17:43] MarkM_: ?
* [17:43] MarkM_: ?
* [17:44] MarkM_: I'm redoing them in terms of newTable(true) btw.
* [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: Consider in E this: def object implements Auditor1, Auditor2 {
-
* [17:44] kpreid:  to [[Miranda optSealedDispatch|__optSealedDispatch]](brand) { ... }
+
* [17:44] kpreid:  to __optSealedDispatch(brand) { ... }
* [17:44] kpreid: }
* [17:44] kpreid: }
* [17:44] kpreid: Suppose that both of those auditors want the object to have a particular optSealedDispatch behavior.
* [17:44] kpreid: Suppose that both of those auditors want the object to have a particular optSealedDispatch behavior.
Line 23: Line 23:
* [17:47] kpreid: More generally, even without the auditors:
* [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: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: 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 [[Sealer]]s which do not spoof their brands :)
+
* [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: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] kpreid: Anyway, I have no idea what to do about this.
* [17:49] MarkM_: and if you already know sealer1 != sealer2
* [17:49] MarkM_: and if you already know sealer1 != sealer2

Revision as of 22:13, 15 August 2009

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