[cap-talk] Definition of Authentication on wiki.erights.org

[Rob Meijer]

On Fri, September 11, 2009 07:48, Matej Kosik wrote:
> Rob Meijer wrote:
>> On Tue, September 8, 2009 10:48, Matej Kosik wrote:
>>> Rob Meijer wrote:
>>>> I fail to see any concrete difference between subjects and principles
>>>> in
>>>> that your definition of a principle seems to align with what I would
>>>> consider a subject.
>>> The term `subject' already has one meaning. There is no confusion. For
>>> our context, I have tried to recapture it here:
>>>
>>> http://wiki.erights.org/wiki/Subject%2C_object%2C_operation_and_permission
>>
>> I fully agree with this definition here, sounds much like how
>> David-Sarah
>> describes a principle though.
>>
>>> If you run a Linux machine, you are a principal (or in fact several
>>> principals). The processes that run on your behalf are subjects. Files
>>> are objects. There are few principals here but quite many subjects.
>>
>> So if I understand correctly, principles only exist at a very course
>> granularity, and it is just the granularity that determines if an active
>> object is a subject or a principle?
>
> This will be a dumb question: why do you use word `principle' when I
> used `principal' ?

The reason for that is that I tend to make worse spelling mistakes in
English with a spell checker than without one :-(

> For me, the difference between the two terms:
> - subject
> - principal
> is simple. It does not make sense to try to authenticate subjects but it
> makes sense to authenticate principals.
>
> Although I would not reject immediately an idea that `principals' are
> special case of `subjects'.
>
> Does this make sense to you?

So principals are the special case of subjects for what authentication
makes sense?  Wouldn't this be the same subset  as the special case of
subjects for what access control makes sense on an individual basis plus
the special case of subjects for what accountability makes sense?

If so, I feel this may not at all be a special case. For example it may
make perfect sense to be able to know what class of your program is
accountable for some problem in your system. Its just a matter of applying
the same concepts to a different level of granularity.

Seems to me that subjects at one level of granularity per definition would
be principals at a granularity one or two levels finer. So if something is
a subject or a principal is just a matter of at what granularity you are
looking at it. A principal becomes a mere subject when looking at a
courser granularity abstraction and a subject becomes a principal when
zooming in to the finer levels of granularity. Does this observation match
yours?


>
> My viewpoint does not cover well situations where designers are
> forcefully trying to convert all subjects to (authenticable) principals
> because otherwise they are unable to enforce security policies over them
> due to their wish to use IBAC at fine level. I do not consider this a as
> a problem if our vocabulary does not cover that because that is a broken
> approach. It is good to be aware of it but our (my) vocabulary should
> not attract us (me) to that way of thinking.

In my view there are two types of IBAC, pure ACL style IBAC, and the type
of IBAC/ABAC hybrid that I do feel is quite usable that uses 'delegation
on authentication'. In MinorFs I implemented two filesystems, MinorViewFs
and MinorCapFs. MinorCapFs uses ABAC, while MinorViewFs uses 'delegation
on authentication'. In MinorViewFs it is the process (in both its form as
a non persistent Unix process and in the abstraction of the pseudo
persistent process that MinorFs helps to implement) as basic level of
granularity for access control. Given that MinorViewFs authenticates the
subject (the pseudo persistent process) prior to delegating it its private
share of the filesystem, and the process thus is a subject for what
authentication makes sense, would you:
1) consider the process to be a principal in this example?
2) consider my design for MinorFs to be a 'broken approach' not worth
   considering in our vocabulary?
3) Not consider MinorViewFs its authentication of processes as an example
   of what we should consider authentication?
4) Feel that 1,2,3 and me are all completely missing the point?


Rob