headers
John Carlson | 1 May 2004 12:36
Picon

distributed capabilities for models?

Definition:  A model is something that can be defined with the Unified 
Modeling Language
(UML) or other modeling language.

XMI is used to store (and maybe communicate) UML models.
These models can get quite complex.  Some of the model may be proprietary.

I would like to share a piece of my model with my partner company.
I don't want to share the whole thing.  What is the best way to
do this?  Copy and paste a piece of the UML drawing?  What if we
want to modify the shared piece?  How do we bring it back into
our individual proprietary systems?  Wouldn't it be better to
link the models into a single model, for maximum compatibility?
Wouldn't this be a lot better than writing a bunch of requirements
and design documents?

So where do capabilities fit in?  Here's what I see:  Each piece
of the model, whether it be a class, an object, a relationship or
a connection has one or more capabilities.  These capabilities can
be shared with your partners.  There are rules about what the
partners can do stored in the capabilities, so when a partner
employs a tool to manipulate the model, they can only do
what they were given the right to do.

What I've seen done:   Users, Groups and Roles have privileges
to do certain actions to a class of objects in a given state.  This
is stored in a single database.  I'm not even sure two databases
from the same vendor can communciate with each other (they
can incorporate and feed other databases).
(Continue reading)

Permalink | Reply | 11 comments |
headers
David Hopwood | 1 May 2004 17:51
Picon
Favicon

Re: Re: "capabilities" as data vs. as descriptors - OS security discussion, restricted access processes, etc.

Jonathan S. Shapiro (by way of Mark S. Miller <markm@...>) wrote:

> On Mon, 2004-04-26 at 23:18, Jed Donnelley wrote:
>>>>I'm not sure what you mean by the "safety problem".
>>>
>>>Harrison, Ruzzo, and Ullman 197[6].
> 
> I think it was Communications of the ACM. It's not on-line, to my
> knowledge.

It is on-line at
<http://www.cs.unibo.it/babaoglu/courses/security/documents/harrison-ruzzo-ullman.pdf>.
Essential reading.

--

-- 
David Hopwood <david.nospam.hopwood@...>
Permalink | Reply | 3 comments |
headers
David Hopwood | 1 May 2004 16:47
Picon
Favicon

Re: Re: "capabilities" as data vs. as descriptors - OS security discussion, restricted access processes, etc.

Jed Donnelley (by way of Mark S. Miller <markm@...>) wrote:
> The "capabilities as data" model that I generally have in mind when
> in a discussion such as this is something like the "Control by Public
> Key Encryption" mechanism described in:
> 
> http://www.webstart.com/jed/papers/Managing-Domains/#s13
> 
> I suggest taking a look at that section.  It is on-line and is only
> a few paragraphs along with a diagram (if the notation becomes
> confusing you may need to refer to the introduction where there
> is a note on font restrictions).
> 
> With that model the representation of a capability is unique to
> the process that holds it.

Then this is a descriptor capability system. The process-specific
representation is effectively a descriptor.

In the usual notion of a password (a.k.a. sparse) capability system,
the "passwords" are not process-specific. There can be hybrids of
password and descriptor systems, of course, but if "passwords" are
process-specific, and can only be transferred between processes with
the mediation of a TCB, then the resulting system is more like a
descriptor-based cap system than a password-based one.

Do we agree that:
  - a password capability system in which the passwords are not
    process-specific cannot support confinement, and makes it impossible
    to enumerate all capabilities held by a process;
(Continue reading)

Permalink | Reply | 596 comments |
headers
David Hopwood | 1 May 2004 18:29
Picon
Favicon

Re: Re: "capabilities" as data vs. as descriptors - OS security discussion, restricted access processes, etc.

David Hopwood wrote:
> Jed Donnelley (by way of Mark S. Miller <markm@...>) wrote:
> 
>> The "capabilities as data" model that I generally have in mind when
>> in a discussion such as this is something like the "Control by Public
>> Key Encryption" mechanism described in:
>>
>> http://www.webstart.com/jed/papers/Managing-Domains/#s13
>>
>> I suggest taking a look at that section.  It is on-line and is only
>> a few paragraphs along with a diagram (if the notation becomes
>> confusing you may need to refer to the introduction where there
>> is a note on font restrictions).
>>
>> With that model the representation of a capability is unique to
>> the process that holds it.
> 
> Then this is a descriptor capability system. The process-specific
> representation is effectively a descriptor.
> 
> In the usual notion of a password (a.k.a. sparse) capability system,
> the "passwords" are not process-specific. There can be hybrids of
> password and descriptor systems, of course, but if "passwords" are
> process-specific, and can only be transferred between processes with
> the mediation of a TCB, then the resulting system is more like a
> descriptor-based cap system than a password-based one.

For the "Control by Public Key Encryption" mechanism, I should have
added the caveat that this is only true, if the private key of each
process on a machine is only known by the TCB of that machine, and
(Continue reading)

Permalink | Reply | 0 comments |
headers
Liang Fang | 1 May 2004 18:59
Picon
Favicon

Re: distributed capabilities for models?

Hi John,

I am not sure whether there is any impl exactly what you want, but what 
you described absolutely fits the capability model. As I understand, the 
models are resources for different users to access, according to their 
assigned capabilities. What you are asking is a detailed impl plan of 
the capability model.

Considering what I have done, I would wrap up the model resource access 
as a Web service. The web service is run by the resource owner. The 
resource owner issues capabilities which contain different detailed 
accessing policies, signed with the credential of the resource owner. 
The capabilities can be distributed in any way -- copy and paste, email, 
even fax and scan :), though a seperate manager is prefered. Upon 
invoking the web service, the capability token is inserted in the SOAP 
message which is signed again with the user's credential. At the service 
side, the policy is extracted and checked for the final accessing 
decision. The capability injection and verification work is done by the 
underlying SOAP engine and thus mostly transparent to the service 
itself. As the resource owner, you can have your own groups or roles for 
the administrative convinience.

Hope it helps. For other capability gurus, correct me if I am wrong.

Liang

John Carlson wrote:

> Definition:  A model is something that can be defined with the Unified 
> Modeling Language
(Continue reading)

Permalink | Reply | 5 comments |
headers
John Carlson | 1 May 2004 23:21
Picon

Re: distributed capabilities for models?

Liang Fang wrote:

> Hi John,
>
> I am not sure whether there is any impl exactly what you want, but 
> what you described absolutely fits the capability model. As I 
> understand, the models are resources for different users to access, 
> according to their assigned capabilities. What you are asking is a 
> detailed impl plan of the capability model.
>
> Considering what I have done, I would wrap up the model resource 
> access as a Web service. The web service is run by the resource owner. 

I am not talking about a single resource.  I am talking about two (or 
more) companies sharing their resources.  They'll have
to use a high degree of collaboration to pull this off.  Each company 
owns a piece of the pie.  The flattening into XML or SOAP
is probably unavoidable at a low level (that is, it's so simple, it can 
be ignored right now).  If this is web services, then there will
probably be cross linking of capabilities within and between companies.  
If I am looking at a model, I don't want to see a bunch
of capabilities, I want to see the model, perhaps with visual effects 
showing which company owns what (different colors, logos etc).
I can see a progressive unfolding as the companies start to trust each 
other and work more closely with each other.

Here are my requirements:

An inter corporate, seamless model.
(Continue reading)

Permalink | Reply | 4 comments |
headers
Liang Fang | 2 May 2004 07:11
Picon
Favicon

Re: distributed capabilities for models?

Hi,

Replied as follows.

Liang

John Carlson wrote:

> Liang Fang wrote:
>
>> Hi John,
>>
>> I am not sure whether there is any impl exactly what you want, but 
>> what you described absolutely fits the capability model. As I 
>> understand, the models are resources for different users to access, 
>> according to their assigned capabilities. What you are asking is a 
>> detailed impl plan of the capability model.
>>
>> Considering what I have done, I would wrap up the model resource 
>> access as a Web service. The web service is run by the resource owner. 
>
>
>
> I am not talking about a single resource.  I am talking about two (or 
> more) companies sharing their resources.  They'll have
> to use a high degree of collaboration to pull this off.  Each company 
> owns a piece of the pie.  The flattening into XML or SOAP
> is probably unavoidable at a low level (that is, it's so simple, it 
> can be ignored right now).  If this is web services, then there will
> probably be cross linking of capabilities within and between
(Continue reading)

Permalink | Reply | 1 comment |
headers
John Carlson | 2 May 2004 08:04
Picon

Re: distributed capabilities for models?

Liang Fang wrote:

>
>> Here are my requirements:
>>
>> An inter corporate, seamless model.
>>
>> Each company determines who gets to see and update their piece of the 
>> model.
>>
>> Auditing of capabilities to see who shared what, who modified what etc.
>>
> The security system can find the user's info (distinguished name ...) 
> in the SOAP calls for auditing purpose.
>
>> Capabilities to the smallest detail of the model. (the attribute 
>> types, names or values).
>
>
> This is really about the policy schema or language. Since it is the 
> resource owner who issues the policies, the capability system may not 
> care what policy schema is used, as long as the issuer himself 
> understands his own policies. Even so, the capability system may 
> provide some default authorizers according to some default policy 
> schemas.

Ah, I see it as a policy model--it can be treated as a model.

>
>>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Ian Grigg | 2 May 2004 22:12

Re: Re: "capabilities" as data vs. as descriptors - OS security discussion, restricted access processes, etc.

Hi guys,

I found this part very important - the
definition of the capabilities - and
recorded it over on the FC blog (follows,
FTR of cap-talk).

iang

((((((( Financial Cryptography Update: Definition of Capabilities )))))))

                               May 02, 2004

------------------------------------------------------------------------

http://www.financialcryptography.com/mt/archives/000126.html

------------------------------------------------------------------------

There are several models of rights out there - nyms, capabilities,
bearer, account.  One observation that has been made by Jeroen van
Gelderen is that nyms (especially, SOX) as a model is a case of
capabilities.  What that means, beyond the superficial, has always been
up in the air.	The somewhat presumption was that SOX is a subset, or
implementation of capabilities.  Or, that SOX is capabilities
hard-coded, whereas E, by contrast, is capabilities in the language.

The capabilities people (them) and the nym people (us) haven't really
seen eye to eye on the lucidity of each other's documentation, so
distance remained.  Now, Jed Donnelley has broken ranks and cast his
(Continue reading)

Permalink | Reply | 7 comments |
headers
David Wagner | 3 May 2004 05:29
Picon
Favicon

Re: "capabilities" as data vs. as descriptors - OS security discussion, restricted access processes, etc.

David Hopwood writes:
>Do we agree that: [...]
>  - confinement, and the ability to enumerate capabilities held by a
>    process, are both very useful; [...]

Are they?  Can you elaborate a bit further on why they are useful?
(I don't believe bit confinement is possible in any realistic system,
and I'm not sure what I'd do with the ability to enumerate capabilities.)
Permalink | Reply | 8 comments |

Gmane