Hi, On Fri, Apr 24, 2009 at 08:48:34AM +0200, olafbuddenha...@gmx.net wrote: > [snip] > > > Note also that it's possible for the sender to trick the receiver to > > use objects the sender itself does not have access to, in ways they > > are not expected to be used. Possibly leading to precious data being > > overwritten or sensitive data being transmitted. Thus we also need to > > make sure the sender does indeed have the access it claims to have. > > I think you are trying to do too much here. > > The problem you described is exatly what is known as the "firmlink > problem": the same situation can occur whenever an untrusted server > gives out unauthenticated ports, and the client reauthenticates them > against it's own permissions. It is a fundamental limitation of the Hurd > auth mechanism. > > While it would be nice to find a solution to this problem, this > shouldn't and in fact can't be fixed within the mobility framework. > Fixing it here doesn't help at all, if the problem is still open > elsewhere. All we need to ensure is that the mobility framework doesn't > make it worse. > > You have considered this stuff very thoroughly, and it's quite possible > that you might be able to find a generic solution to this issue. But it > is orthogonal to the mobility framework.
Well, you're right, I shouldn't try to fix the firmlink problem. I'm actually confused as to why I included that paragraph in the first place, since the firmlink problem isn't really relevant. :-( What would have been a more appropriate problem to describe, would have been that if equality test were to be done in the sender (or the receiver for that matter), the sender could make the receiver send capabilities to it that it didn't have access to before. Really, it's the same reason we have an auth server and don't send auth ports directly to the server during authentication. I think I managed to confuse the two problems at the time. Sorry about that. > Anyways, this consideration made me realize that most probably we should > just do *exacly* what is done for authentication in general: Let the > sender give out unauthenticated capabilities for the dependencies, and > the receiver reauthenticate them. I'm pretty sure this is the most > useful approach: It is straigtforward; uses existing mechanisms; is > guaranteed to align with the rest of the system design; the security > implications are known. Ignoring that this would undermine confinement of processes through chroot and (partial) sub-Hurds. (Your suggestion makes it seem as if you're fine with that.) There is no way to know that the reauthenticated object is equal to the original, in particular, we can't determine that it permits the same operations. My suggestion to get capabilities from the senders task port, however, seems both extremely secure and robust. And naturally reflects the case where the receiver dominates the sender. The only downside being that it's a much stricter requirement. > In general, I fear that you are a bit too ambitious with this project... > You are trying to consider things in a too general, too abstract way. > This requires too much consideration; opens a field that is too wide -- > I don't think it can be finished in any useful time frame. I strongly > suggest you try to focus more on specific situations. It's not realistic > nor useful, trying to be more generic than the rest of the existing > system design is... > > I already hinted at this in various other discussions (not only with > you): I'm generally of the opinion that it's better to start with > specifics, and generalize later, than trying to think about all possible > implications up front. Same reason I was always sceptical about the > ngHurd stuff... I agree with your critique. I'm planning to refocus my effort, but perhaps not in the way you'd want ;-). However, this will be the topic of another mail. I do believe I've come to a simple and robust means to do authority verification. Even if I didn't really set out to do it initially and only after I realized that what I initially wanted was impossible (with out modification through out the Hurd, which I consider to be out of the question). > > Another possibility which I have considered, is ports that are > > considered safe for sending directly. For instance, libstore does > > this when a store is opened read-write and the entire underlying > > device is used. The reasoning being that accessing the store remotely > > still makes it possible to access the entire store. > [...] > > Second, it would no longer be possible to revoke the access to the > > underlying device provided by the store by killing the store > > translator. > > This is a general problem of object mobility though, not just the > specific authentication approach, isn't it?. No, if the client has access to the underlying store independent of the server, then the server can't revoke that access. >From a transparency point of view you are correct. There is a question whether a object copy should destroy itself if the original object is destroyed. Should we choose to do this we can rely on the server giving up access voluntarily, because we couldn't stop it even if we wanted to. > AIUI, implementing revocable capabilities is one of the great unsolved > problems of capability systems... Yes, and the common work around is making a proxy that can be disabled. Which happens to be the case here. ;-) Regards, Fredrik
