[cap-talk] Capabilities - the rub, an account
marcus.brinkmann at ruhr-uni-bochum.de
Fri Nov 24 07:14:32 CST 2006
On Fri, 2006-11-24 at 16:17 +0800, John McCabe-Dansted wrote:
> On 11/23/06, Marc Stiegler <marcs at skyhunter.com> wrote:
> Likewise is possible as we have both suggested in this thread, to pass
> capabilities around in such a way as you have as much information as
> you do under ACL. However this is not true if you do this the
> "obvious" way. If we pass rights around by giving other users simple
> copies of the caps, all accesses will appear to come from the
> The typical cap response, is that you *can* do things like attach a
> revoking or logging proxy to the cap before passing it on.
There are two properties you are looking for here, and they can be
distinguished: One is creating a revocable copy of a capability, rather
than a co-equal copy. The other is creating a distinct capability that
is associated to a different principal at the receiving end of requests
invoked on the capability (the service).
Creating a revocable or logging proxy implements the first property, but
not the second. In fact, it can be an important property of such
systems that the service can not distinguish between different copies of
the same capability (revocable or not). To do otherwise would be to
leak information to the service that it arguably shouldn't have.
You are calling for a system where all copies of capabilities are
revealed to the service. I am not sure if you only want to transmit a
principal ID of the sender or the whole path down a mapping tree. In
either case, you are going to face a number of serious problems that are
not easily addressed, ranging from resource allocation issues to
security issues and finally performance problems in actual
Capability systems usually solve this issue by foregoing the goal of
collecting and maintaining global information about what's going on in
the system. I agree with your finer point that at some level you want
to re-establish such information at least at an intermediate level, for
example user-to-user interaction. However, it may be sufficient to
reestablish this at the application level, rather than at the capability
system level (assuming the cap system is powerful enough to allow that,
a non-trivial question IMO).
> response does not convince the ACL crowd that caps are as good or
> better than ACLs, nor do I believe that it should. We need to convince
> them that that innocent users *will not* pass rights the obvious way.
> We can not assume that non-technical staff will understand the
> difference between sending their own caps and sending a cap wrapped in
> a revoking or logging proxy. The system should make the "obvious" way
> of sharing caps between users non-obvious. Indeed, IMHO the system
> should prevent unwrapped caps from ever being sent between users by
> always rewrapping the caps.
> Further, when promoting caps we should make it clear that we intend
> for the system to ensure that transfers of caps between high-level
> entities such as users are always logged and revocable. Even if a
> buggy/malicious application conspires to automatically proxy rights
> unlogged, then it should be possible to revoke the rights by
> destroying the application, and also allow the user to monitor data
> entering or leaving their account e.g. to set up an IDS.
I think that this makes sense, and it is one reason why I consider
revocable copies an essential feature in capability systems.
Unfortunately, building a system that has unlimited (by the system)
nesting of capability wrappers and no denial-of-service threat scenario
is a big challenge (see the current L4 redesign efforts with
user-managed kernel memory).
> Even if we assume users actions are infallible there is still the case
> where they leave their terminal logged in.
If the user sessions are persistent, then logging in just means
attaching a terminal to a running session. In this case it is easy to
choose short time outs and require re-login after that. To the user,
this would appear similar to current screensaver+screenlock features.
> In the good ol' days we
> didn't give users write access to startup scripts or macros, so if
> someone found a logged in terminal they couldn't get any rights that
> lasted beyond a logout. It would be nice if we could regain this
> property, to do this we would have to require users to jump through
> hoops to grant permanent rights, either by contacting a sysadmin or
> reauthenticating like "sudo myself-admin".
In a persistent system, no start-up scripts or macros are required. In
any type of system, a proper event notification system can allow the
user to implement their own start-up script mechanism for their
In general one would want to reduce the role of the system administrator
and the system software in general in a modern operating system. The
Unix model of root on the one side and the users on the other side has
great disadvantages, both in terms of security and in terms of
More information about the cap-talk