Hi, On Fri, Apr 24, 2009 at 04:50:56PM +0200, Carl Fredrik Hammar wrote: > On Fri, Apr 24, 2009 at 08:48:34AM +0200, olafbuddenha...@gmx.net > wrote:
> 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. Right: It's the reason for having the auth server, and the io_reauthenticate mechanism. I really don't understand why you are so reluctant to use the existing mechanism... My only concern was that this limits the framework to file system capabilities, and I feared you might not like such a limitation -- but on rereading the other mail, I saw that you actually suggested limiting the framework to file system objects yourself. (Well, there is also the possibility of having objects that are accessible through the file system, but in turn require capabilities that are not... But I tend to think that we should simply ignore that case.) > > 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. You have a point there; this would break the existing chroot implementation: when a chrooted process gets access to a translator outside the chroot, it could misuse the mobility framework to get access to the underlying capabilities of that translator, and thus the whole file system. I tend to dismiss that as just one more problem of the existing chroot implementation, though... I do *not* agree that this would affect partial chroots, i.e. any confinement mechanism based on proxying. A proxy can guarantee that unproxied capabilities are never leaked to the confined process. In fact, I'm more and more convinced that chroot should be reimplemented using a proxy as well. This problem raises a fundamental question though: Should an unauthenticated file system port *ever* give a process access to anything it wouldn't have access to otherwise? Intuitively, I would say it shouldn't -- but I'm not really sure that the existing chroot implementation is the only place that violates this assumption... Still, I believe it's worth a try. > My suggestion to get capabilities from the senders task port, however, > seems both extremely secure and robust. I must admit that I'm not sure I really understand what you want to do here... The way I understand it, it sounds both rather icky *and* very limited. > And naturally reflects the case where the receiver dominates the > sender. The way I understand it, it's actually the *only* case it would support... And if that it so, we could just as well go with a simplistic approach: not dominated -> no migration; dominated -> sender can just give the necessary capabilities to the receiver directly. The suggestion to use the task port as a means of showing domination, is actually a good one -- I just don't see the need for any complicated mechanism for extracting capabilities through the task port. We can just as well simply present the task port and say: "Hi, I'm your master. Give me what I ask for." BTW, this makes me realize that the question about chroot is probably moot: Unless I'm mistaken, a chrooted process can still obtain the task ports of all processes belonging to the same user. If that is indeed so, all phantasies about using the existing chroot implementation for confinement are utterly shattered anyways... (Ignoring even the other known gaping holes, like passive translators.) -antrik-
