[E-Lang] MintMaker with ACLs

hal@finney.org hal@finney.org
Tue, 30 Jan 2001 09:36:01 -0800


Tyler writes:
> The way you are using the password isn't exactly like an ACL system.
> In an ACL system, the password is intrinsic to the invoker. The
> invokee is able to magically determine the invoker and check the
> authority. In your design, you are explicitly passing the password on
> each invocation. This makes it more like a capability. If you combined
> the srcAccount and password parameters into a single parameter, it
> would be a capability.

Let me try again, then, to make it more ACL-like.  Instead of passwords
I'll use UIDs.  See what you think of this one:

    // account balances, indexed by account number
    int balance[];
    // User IDs of account owners, indexed by account number
    UID ownerUID[];

    // Message requesting transfer
    int transfer (int sourceAccount, int destAccount, int amount)
    {
        // See that this user is owner of account
        if( getuid() != ownerUID[sourceAccount] )
            return ERROR_INVALIDACCESS;
        if( balance[sourceAccount] < amount )
            return ERROR_INSUFFICIENTFUNDS;
        // Proceed with transfer
        balance[sourceAccount] -= amount;
        balance[destAccount]   += amount;
        return NOERROR;
    }

Here I have introduced an operating system call, getuid(), which returns
the current user ID of the operating process.  This is used rather than a
password to access the account.  The mechanism for securely determining
the UID in a distributed computing environment is outside the scope of
this example (but might involve passwords, smartcards, biometrics etc.).

To allow some of the other features Tyler suggests, let us extend this
example with a list of UIDs which are allowed to read the balance:

    // User IDs of those allowed to read balance
    UIDlist accessUIDs[];

    // Request balance
    int getBalance (int account)
    {
        // See if this user is allowed public access
        if( ! accessUIDs[account].contains( getuid() ) )
            return ERROR_INVALIDACCESS;
        return balance[account];
    }

For other features Tyler mentioned like giving my accountant the ability
to read my account history, a similar mechanism would be used: introduce
a new UIDlist for the required permission and check that the user ID of
the requestor is in that list.

For the confused deputy example, let there be an agent which will reveal
my public balance under certain conditions.  This agent needs to be
running with its own UID and that UID is put on the accessUIDs list above.
This way I don't have to give the agent more power than he needs and the
POLA is satisfied.

Now let me give an example of a change that's easy to make with this
system.  Suppose there were some master account belonging to the bank
or the IRS which needs to be able to read all balances.  I can achieve
this by changing one line in the getBalance call above, from

        if( ! accessUIDs[account].contains( getuid() ) )
to
        if( ! accessUIDs[account].contains( getuid() ) && getuid() != MASTERUID )

Can the MintMaker at
http://www.erights.org/elib/capability/ode/ode-capabilities.html#simple-money
be modified as easily to accomodate this change?  Maybe it can, I
don't know.  Intuitively it seems like the ACL system would be more
suitable to feature like this which seems tied to identity, but perhaps
the capability system can handle this as well.

Hal