[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Authority verification

From: olafBuddenhagen
Subject: Re: Authority verification
Date: Thu, 21 May 2009 20:01:13 +0200
User-agent: Mutt/1.5.18 (2008-05-17)


On Fri, Apr 24, 2009 at 04:50:56PM +0200, Carl Fredrik Hammar wrote:
> On Fri, Apr 24, 2009 at 08:48:34AM +0200, olafBuddenhagen@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

> > 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

> 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.)


reply via email to

[Prev in Thread] Current Thread [Next in Thread]