On Fri, Jul 4, 2014 at 4:37 PM, Jonathan S. Shapiro <[email protected]> wrote: > The part that's important is getting it into the programmer's head that > choosing the interface specifications in a way that yields the right > transitive reflexive closure of reachable operations is the essence of > interface-based security. Since that TRC is (by definition) the difference > between permission and authority, yes, it's an important thing to consider.
OK, I like that. But really, what the programmer must know is that authority is transitive and reflexive. They don't need to know what it's the transitive reflexive closure of. Whenever you know you can exercise A (somehow) to get B, and exercise B (somehow) to get C, you can exercise A (by doing both) to get C. At no point does that require knowing which operations are the atomic building blocks of security-relevant operations, as long as you know which operations under consideration are security-relevant. I'd say it's anti-compositional to worry about permission (in addition to authority). > And yes, it's a static approximation to controls you might do with more > general semantic techniques, but my experience is that the more general > techniques are both hard to explain and hard to understand. In the right > place, sure. But the simplest answers to manage are going to be the > conservative ones, because they are simpler to explain. I didn't mean to promote any particular approach, just to point out that there are different ways of building up the same authority structure from primitives, so the primitive permissions are not part of the essence of the system. I'm all for useful fictions about what the primitive operations are; that's what abstraction's all about. _______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
