Beefy Boxes and Bandwidth Generously Provided by pair Networks
good chemistry is complicated,
and a little bit messy -LW
 
PerlMonks  

Using Capabilities?

by diotalevi (Canon)
on Dec 13, 2002 at 18:06 UTC ( #219670=perlquestion: print w/ replies, xml ) Need Help??
diotalevi has asked for the wisdom of the Perl Monks concerning the following question:

This is an application design question involving perl/PostgreSQL. I've been reading up on the Capability based security model and am at a loss for how this might play out in application code. I'll start with some links: Re (tilly) 1: Application Access Control, Capability Theory, [id://http://crit.org/http://cap-lore.com/CapTheory/ObExp.html|Objects and Facets], REST and capabilities (distributed model), Granovetter diagrams (and other stuff), E Language. I'm barely a novice at CapDesign. From the REST e-mail I picked up an initial idea on how to implement a Capability system in perl (more on that). I haven't read everything on these web sites (there's a whole heck of a lot!) but what I have hasn't been lead me to understand how to actually use Caps.

<pTo be clear, I'm going for an OO solution though I'd like to learn more on how to do Capabilities in general (in perl, obviously). The obvious caveats are that perl code itself must be trusted since it is too introspective for one part of an application to keep secrets from another (PadWalker, Devel::Pointer, unpack 'P', $address, etc (ignoring all the myriad prosaic ways to get there as well)). For my actual application I'll be doing something more conventional with ACL lists (because I can't implement Caps right now and don't understand it) so this is for the exercise and architectural insight.

The REST e-mail has an idea on how to structure a capability system. A factory is given a URL like cap://object_reference/method and that might be a node's capability. So in this model perhaps objects don't actually get references to each other and just pass URI references around. Or something. You also layer on the idea that if you know the name of something you are authorized to use it. (I don't understand how that withstands bruteforce searches for "things"). The referenced discussion was also working in a distributed computation model which for most perl (and mine) doesn't hold true. It also helps if you go back to thinking of OO programming as being a network of objects passing messages around (aka method calls). So $object->garf is an example of sending the 'garf' message to '$object'. I guess.

So... help? I'm being vague and handwavey because I don't see how any of this actually happens. I don't imagine tilly (in the PM node which originally pointed me in this direction) was recommending this without a good reason or having ideas on how to implement it.

__SIG__ use B; printf "You are here %08x\n", unpack "L!", unpack "P4", pack "L!", B::svref_2object(sub{})->OUTSIDE;

Comment on Using Capabilities?
Select or Download Code
Re: Using Capabilities?
by diotalevi (Canon) on Dec 13, 2002 at 18:15 UTC

    I forgot to mention - I'm using PostgreSQL for object persistance so it'd be nice to think of implementations that wouldn't be alien to it. But then this is a more general question so however it makes sense for you.

    __SIG__ use B; printf "You are here %08x\n", unpack "L!", unpack "P4", pack "L!", B::svref_2object(sub{})->OUTSIDE;
Re: Using Capabilities?
by valdez (Monsignor) on Dec 13, 2002 at 20:50 UTC

    If I understood correctly what I've found searching around, a capability is "an unforgeable ticket, which when presented can be taken as incontestable proof that the presenter is authorized to have access to the object named in the ticket" (1). So there is an authority that gives a capability to an object, which in turn can pass the capability to some other trusted object ("Capabilities can be delegated" and "Capabilities can be copied" (2)).

    When you need to access something, you must pass a ticket that will be verified on the other side; in other words, invoking a method is not sufficient, you need the right ticket.

    There is still something unclear to me: who will issue tickets? Will an object request a ticket or the object itself will be created with some tickets?

    HTH, Valerio

    1) http://www.cap-lore.com/CapTheory/ProtInf/
    2) http://www.eros-os.org/essays/capintro.html

Re: Using Capabilities?
by adrianh (Chancellor) on Dec 14, 2002 at 15:53 UTC

    First off, REST and capability based security are separate issues. You can have either one without the other. I like REST, but I'll ignore it from now on and just talk about capabilities.

    Let's use a hypothetical message board system to illustrate the differences in style between an access control list model and a capability based model. People can read messages, add new posts, administrators can edit them, etc.

    In a traditional Access Control List security model you would have different users, each of which has different permissions, so you'll do things like this:

    my $b = Board->fetch(board => "perl-examples"); my ($subject, $message) = $b->get_post( user => $u, post_id => 42 ) or die "$u cannot get"; $b->new_post( user => $u, subject => "hi", message => "print 'hello world'" ) or die "$u cannot new"; $b->set_post( user => $u, post_id => 42, subject => "42", message => "is the answer" ) or die "$u cannot set";

    You have a single user that has permission to do one or more operations.

    With an capability model you ask for the capability to do something - and get given an object that will let you do the operation.

    my $b = Board->fetch(board => "perl-examples"); my $get = $b->can_get or die "cannot get"; my $new = $b->can_new or die "cannot new"; my $set = $b->can_set or die "cannot set"; $get->(post_id = 42); $new->(subject => 'hi', message => "print 'hello world'"); $set->(post_id => 42, subject => "42", message => "is the answer");

    You have multiple capabilities each of which allows you to perform individual operations

    Why do it like this? Because it gives you great advantages in the granuality and scope of your security model.

    Let's do a hypothetical task with our board system - create-table-of-contents.

    We want to have a message on the board that contains a list of all the subject lines of the posts on that board. To do this we need to:

    • find-subjects (scan the posts for the subject lines)
    • update-toc (update table of contents message)

    With an ACL model you would have run our create-table-of-contents routine with a user who can both get and set messages.

    The disadvantage of this model is that the bit of code that reads the subjects doesn't need the ability to write posts. Equally, the bit of code that needs to update the table-of-contents message does not need the ability to read posts.

    If you make a mistake in your reading code (or a malicious user subverts it somehow) then you can make unwanted changes to the contents of your board.

    With a capability based model you would only give find-subjects the "get" capability object. You would only give update-toc the "set" capability object. Even if an evil user subverted find-subjects they wouldn't be able to make changes to the board since it lacks the appropriate capability object.

    Having this fine level of granuality makes tweaking your security model so much easier. For example, we might discover that our admin users wander off leaving themselves logged in - allowing nasty people to come use there account to change posts.

    With our ACL model one option is to expire the user if there has been no activity in 10 minutes. Unfortunately, this annoys our admin users since they spend most of the time doing "normal user" things and don't like to find themselves logged out all of the time.

    With our capability model we have finer control and we can expire the "set" capability object after ten minutes inactivity - leaving the users "normal" capabilities still in full affect.

    There are lots of variations on this sort of thing. Without knowing more about the particular problem you are trying to address it's hard to say whether ACLs or a Capability model would be better for you - but hopefully this makes the concept easier to get a handle on ;-)

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: perlquestion [id://219670]
Approved by RMGir
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others contemplating the Monastery: (17)
As of 2014-07-24 16:27 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    My favorite superfluous repetitious redundant duplicative phrase is:









    Results (162 votes), past polls