[cap-talk] Process object -> "Subject" - the saga continues

[Jed at Webstart]

At 04:58 PM 4/6/2005, David Hopwood wrote:
>Jed at Webstart wrote:
>>There's no doubt that the "object" term encompasses things that have
>>methods and therefore engage in computation.  However, it's the very
>>generality of the "object" term that so grates for me.  Is there anything
>>that the "object" term doesn't encompass (in a computational sense)?
>
>Why is this a problem? Technical terms have to be read in context. It's
>silly to insist that they mean *exactly* the same thing in all possible
>contexts.

To me it's the above argument that is silly.  It seems to be suggesting
that in the limit we may as well go ahead and make many of our terms
meaningless and then fill in any intended meaning from the context -
as with use of a term like "thing" instead of "object".  "object" is a
tiny bit more specific in a computational context at least.  However,
I argue that "subject" is quite specific and says nearly exactly what
I intend when referring to a computational actor.  As John Carlson
notes:

 >From the dictionary definition of subject:
     Grammar. The noun, noun phrase, or pronoun in a sentence or clause
     that denotes the doer of the action or what is described by the predicate

This is of course exactly what I mean (and I assume Charlie meant?) by 
"subject"
in a computational context - whether with capabilities or not.  The doer of
the action (invoking capabilities or more generally exercising authorities).

>Note that it is not being suggested that any use of the term
>"object" implies a capability system; only that, *if* we have a capability
>system, then "object" has a specific meaning within that system (which is
>consistent with its use in OO languages).

Is this part of the confusion?  I am looking for a term that I can use to
refer to a computational actor regardless of whether it happens to be
acting in a capability system or not.  An actor whose authorities I
can refer to - e.g. when contrasting a capability system with an
ambient authority or other (e.g. more non POLA) system of access
control.

>>However, when I hear:
>>Subject Alice sent a file capability to subject Bob and subject Bob
>>invoked it.
>>I at least get a bit more specificity.  Then when it comes to more
>>nuanced discussions like:
>>When communicating a capability should the object have the right
>>to specify "do-not-delegate"?  vs.
>>When communicating a capability should the subject have the right
>>to specify "do-not-delegate"?
>>I believe clarity is on the side of the more specific term, "subject".
>
>It doesn't much matter, because in a cap system there are not distinct
>sets of subjects and objects; they are always unified.

I'm not sure whether I simply disagree with the above or just believe
it is wildly misleading.  Why didn't you respond to my question about
a file or a directory "object".  I believe those "objects" are not
subjects.  They themselves certainly do not invoke other
capabilities or in any way make an effort to exercise authorities.
They are not "doers".  That is the distinction I am trying to make.
I'm seeking a term that will allow me to make that distinction
directly - not force me to build my meaning up from context that
I surround a meaningless term like "object" or "thing" with.

>>The "object" term to me can be confused with the resource that
>>the capability provides authority (permission?) to access.
>
>In this case, if you're talking about sending a message, then the more
>specific term for what you want is "sender". The sender is of course
>an object, as well as a subject.

And would you say the "invoker"?  What would you call that which
exercises an authority?  If you have a special term for a "sender"
("object" isn't specific enough in that context?) then why not for
the more general "invoker"?  That is the "subject" term that I am
looking for - except that "invoker" would seem to suggest a
capability system unless the notion of "invoking" can be extended
to apply to any sort of authority.  Does it?  Even "invoker" I would
prefer to "object" because it at least suggests the doer, though
seemingly overloading the doer with other connotations.

>>Shap wrote:
>>  >1. Unfortunately, the term "subject" was used incorrectly in some of the
>>  >very early literature to mean "principal". Whether this is correct or
>>  >not is a matter of definition in any given paper, but it is a common
>>  >misunderstanding of the term even in expert discussions.
>>I would like to get some references on this.  Are you referring to literature
>>that is from the "process" time period?   We chose to ignore/overwrite
>>that "process" term with a new and more ambiguous "object" term,
>
>"process" is itself heavily overloaded.

I accept that.  What I want to hear is something that suggests that
the term "subject" is likely to be misunderstood in a computational
context.

>>When you say "principal" above I assume you are
>>referring to a person vs. some sort of computational "principal"?
>
>In cryptographic usage, a principal is an entity defined by knowledge
>of some secret. This may be a process, a person, or an organisation for
>example. I prefer not to use this term at all in cap systems, but if it
>is used, it should be consistent with the cryptographic meaning, since
>that is now the most common technical usage.

Would you accept a capability as a "secret"?  In a cryptographic
system it is the possession of a secret that conveys authority.
Of course a "password" capability is very little more than such a
secret that conveys authority.  It doesn't seem much of a stretch
to me to use the term "principal" to refer to that which possesses
some capabilities and thus that could exercise them.  I would even
prefer the "principal" term to the "object" term in this regard, though
I still prefer the "subject" term because:

1.  I believe it's dictionary definition and common English usage
are exactly what I mean when interpreted in a computational context, and

2.  I haven't yet heard any usage that would suggest some confusing
alternative meaning (waiting for Shap's reference).

>>> >3. In access control modeling, it proves that there is absolutely no
>>> >difference for formal analysis purposes between subjects and objects.
>>I guess I again need a reference and perhaps some clarification.  If
>>by the above you (Shap) mean that all subjects are objects - well
>>of course I accept that.  That's exactly the problem.  The "object"
>>term is so general that it has no meaning when used to convey
>>the actor that does the work in a computational transaction, specifically
>>as distinguished from the actual "object"s of their work.  However,
>>if you mean something stronger than that as seems to be implied
>>by your "absolutely no difference ... between subjects and objects"
>>then I would like to hear more about it.  Do you mean that all
>>objects are also subjects?  For example a "file" object is also a
>>subject?  If so in what sense?
>
>In the sense that it behaves exactly like a subject for all purposes.
>It may be implemented just like any other subject, or it may be implemented
>by code built into the capability system, but that's mostly irrelevant
>(and what looks like a built-in file may in fact be a wrapper object that
>is not built-in).

I think I must be missing something in the above - or perhaps you are.

I don't argue that even something as seemingly as passive (non active
and un subject like) as a file or directory in fact has some code that
services requests on it.  I simply argue that the resource itself is
in fact passive and emphatically not a "subject".  Consequently the
"subject" term adds value.  It can be used to distinguish between
two types of resources/objects - those that themselves *do*
things (invoke capabilities or otherwise exercise authorities)
and those that don't.  That's the value that I see in the "subject"
term (or the "process" term that went before) and I don't see in
the "object" term.

>This argument is a bit more stretched for stateless objects, but anyway
>there is no need to have use two separate terms "subject" and "object"
>in capability systems; one will suffice.

If one wants to distinguish between those things that act like active methods,
processes, processors (those things that execute instructions), people, etc.
and those things that do not act, then I claim two separate terms are
indeed needed and one, "object", will not suffice.

I remain unconvinced that the "object" term is adequate to indicate the
active nature of some objects or suitable to use when distinguishing
between active an inactive objects.  The "subject" term still seems to
me the best that has been offered.

--Jed http://www.webstart.com/jed/ 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.eros-os.org/pipermail/cap-talk/attachments/20050407/a5401c05/attachment-0001.html