On Monday, April 03, 2006 02:01:21 PM -0500 Nicolas Williams <[EMAIL PROTECTED]> wrote:
> On Mon, Apr 03, 2006 at 02:27:36PM -0400, Jeffrey Hutzelman wrote: >> >> Now, the issue is that when you're talking about a caching distributed >> >> filesystem, your identity affects not only what credentials are used >> >> to establish connections to fileservers on your behalf, but also what >> >> you are allowed to do with cached data and connections. For >> >> example... >> > >> > Yes, clearly, but this doesn't make PAGs a process group separation >> > feature *locally*. On the wire your PAGs look as though they were >> > different identities; locally they are not. >> >> Sure. But it turns out to be incredibly useful to have "weak" >> separation, in which you have to go to some effort to use an identity >> other than the one associated with your own PAG. When you involve >> human users or complex software build processes, the principle of least >> privilege becomes fairly important. > > I won't insist on having it both ways, and I wish you didn't either :) > > Since you've agreed that PAGs are not a session separation feature I'll > just put you firmly in that column and ignore any further protestations > that PAGs are a form of "weak separation" ;) :] Fine. It's really just about making identity selection work in a sane way. The idea is that if I start a new PAG, and get reduced or no credentials in that PAG, then ordinary file accesses actually fail when they're supposed to, rather than randomly succeeded. >> If you have multi-app PAG's, then it gets harder. > > How? A little bit of IPC to talk to the right daemon that keeps the > PAG->network-authentication-credential association doesn't seem "hard" > to me... It gets harder (a little) because I have to actually look up the association. That's not such a big deal, but... >> I just >> don't want it to be so hard that I have to do at least one upcall to >> user-mode for every vnode or file op on a file in AFS. > > Oh no, not "for every vnode or file op" -- for every authentication > attempt. Surely AFS does not do an AP exchange "for every vnode or file > op," right? Right?! > > Please tell me that it doesn't... If not I may have to laugh at AFS :) No, of course not. Actually, that's part of my point. We avoid doing that by caching established connections and indexing them by PAG, and we avoid _using_ even the cached connection on every op by also caching metadata, file contents, and access rights. But if mapping the in-kernel PAG to the identifier AFS actually uses requires an upcall, then I have to do the upcall on every vnode and file op, because that's pretty much how often I have to examine cached access rights (actually, it's not quite _that_ bad, but it's close). I'm beginning to think that maybe there is some unstated assumption here, and we are talking past each other. In your user-mode multi-app PAG world, what would you have me do to find the cached access rights that apply to a process? Maybe your answer to this will uncover the disconnect. >> Yes, you could do that. Those wouldn't be the same semantics as AFS, >> but that's not necessarily a problem. It _would_ be very similar to >> the semantics of Kerberos file ccaches, which can also be useful. > > Since you agree that PAGs are not a session separation feature I don't > see how the semantics of this "join PAGs I own" feature would be > incompatible with the semantics of AFS PAGs, but an extension. It's complicated, in part because different people have different expectations. Step out of the world of perfect security for a moment, and consider the real world. In the real world, there are people who assume that because we explicitly don't provide an interface for PAG-joining, you can't do it. Some of those people are blissfully unaware that there are ways to do it anyway. Others know full well what they're getting into, and consider it a problem to eventually work around. Personally, I happen to think that being able to join your own existing PAG's would be fine. But I _know_ there are AFS-using sites out there that feel differently. > I should correct myself here -- the right way to implement "join PAGs > one owns" in the scheme I've proposed is to find the associations of the > PAG you want to join, join new PAG instead, and then establish all those > associations for the new PAG. (To keep continuity I'd make associations > to PID before joining a new PAG -- "make before break.") Hm, so you don't get to arbitrarily change your PAG, but you do get to set existing associations. That's interesting, because it could potentially allow each application to decide whether its ID's can be joined. That might well satisfy the people who want to use PAG's for process separation. > Well, good luck. I think one should be rigorous, not "haphazard" in > designing a kernel-level extensible authorization scheme. I've not > looked at these hooks in Linux, so I'll take your word as far as their > placement. So do I. And from what I've heard, the linux-kernel folks are not too happy about the current model, and would like to see it cleaned up. As I understand it, the hooks that exist are the ones that were needed to provide just enough of a plugin-like interface to support SELinux. So its not "broken", but it's also not as fully general is it probably should be. Anyway, the point is I can see how it could be done. -- Jeff ________________________________________________ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos