Re: Authority verification

[Carl Fredrik Hammar]

Hi,

On Fri, Apr 24, 2009 at 08:48:34AM +0200, olafBuddenhagen@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