bug-hurd
[Top][All Lists]
Advanced

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

Re: Authority verification


From: olafBuddenhagen
Subject: Re: Authority verification
Date: Fri, 24 Apr 2009 08:48:34 +0200
User-agent: Mutt/1.5.18 (2008-05-17)

Hi,

On Thu, Apr 23, 2009 at 02:46:10PM +0200, Carl Fredrik Hammar wrote:

> I guess this mail turned out to be more of a report on my findings
> rather than to start a discussion.  So I'm mostly looking for
> feedback, e.g. if what I'm saying doesn't make sense, if one of my
> assumptions are wrong, or if I have missed something.

Your analysis of the problem seems very good, but:

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

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.

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

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

AIUI, implementing revocable capabilities is one of the great unsolved
problems of capability systems...

-antrik-




reply via email to

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