[cap-talk] Polaris tickle, POLA for Internet access, URLs

Valerio Bellizzomi devbox at selnet.org
Mon Dec 13 13:37:17 EST 2004


On 12/12/2004, at 19.48, Jed Donnelley wrote:

>At 01:19 PM 12/11/2004, David Hopwood wrote:
>>Valerio Bellizzomi wrote:
>>>Yes, the principle is clear. Programs MUST NOT have the rights of the
>user.
>
>I hope we are all in agreement on the above.  I agree that this base
>ability
>for some sort of POLA (rather than ambient user access) is so fundamental
>to achieving any sort of security in computing that we must push very
>hard to achieve this.  Without some facility along the above lines I
>despair
>of ever achieving reasonable security/integrity in computing as the
>continued
>threat from various forms of Trojan horse seem otherwise pretty
>insurmountable.
>
>However, as to:
>
>>>The fundamental approach is to grant and revoke rights to the program in
>a
>>>step-by-step manner (every program step has exactly the rights it needs
>to
>>>perform the current operation, no more, no less).
>>
>>Right, except that this can be achieved most simply by scoping mechanisms
>>(a variable holding a capability/reference goes out of scope when the
>>procedure that needed it returns) rather than explicit revocation.
>
>I personally feel the above (dynamically removing rights during a
program's
>execution as they are no longer needed), while a good general idea and
>in accordance with POLA, is more than is needed for the bulk of the
>problem.
>
>If this sort of dynamic maintenance of rights can be achieved in a natural
>way - great.  Anybody with the ability to achieve such tight control
>should do so (e.g. as David suggests by scoping mechanisms).  However,
>I feel that if this sort of dynamic removal of rights is difficult to
>achieve
>early on (e.g. the issues of knowing when a right is no longer needed,
>or the mechanisms such as revocation that might be needed to remove
>the right) then I feel we should focus on the 90% part of the problem,
>limiting rights granted to programs to POLA and work on achieving such
>dynamic revocation as time and effort allow.
>
>I note in defense of this approach that once a right is granted to a
>program, if it is going to do damage to the resource it can do it at
>that time.  I understand of course that a program may change in
>substantive ways over time (e.g. executing a relatively untrusted
>macro as was the basis for this part of this thread).  In such a case
>dynamic revocation could well be useful.  However, I believe that
>if we can achieve the ability to *grant* rights in a dynamic way
>according to POLA, I believe it will be a *huge* achievement.  If
>that much is achieved perhaps the base  mechanism for that
>success and the momentum resulting from that accomplishment
>will push things on to achieving dynamic revocation.  I certainly don't
>want to hold back any mechanism for granting rights according to
>POLA in order to achieve the ability to revoke them according to POLA.

POLA is a step-by-step mechanism. Static analysis helps us a lot.


>
>>>So, the language must provide mechanisms to grant and revoke rights, and
>>>the operating system has to understand those mechanisms, so there's the
>>>language tied with the operating system. If the hardware provides
>>>specialized features (chips) to support the capability discipline, the
>>>operating system has to be aware of those chips and use them, so there's
>>>the OS tied to the architecture.
>>
>>None of the hardware we have provides specialized features that usefully
>>support capabilities (in particular, as opposed to general security
>>mechanisms), and there's no prospect of that changing in the near future.
>
>I agree.  I don't believe any such hardware support is needed - as David
>says:
>
>>OTOH, almost any hardware *can* be used to implement a capability system
>--
>>even if its enforcement makes little or no use of hardware features
>>intended as security mechanisms, and falls entirely on the language or
>>languages.
>
>However, I think it clear that languages alone do not suffice.  The
>base operating system must provide a restricted (non 'user')
>execution environment and there must be a means of communicating
>rights to processes in such environments.  There must also be a
>means (e.g. along the lines of Polaris or Plash) to allow users to
>manage the rights given to the programs executing on their behalf.
>
>>>The whole paradigm of "user rights" is somewhat vague (it makes sense
>only
>>>inside a shell). The general paradigm should be "program rights".
>
>Amen to that!

At least the language and the OS must agree on the approach.




More information about the cap-talk mailing list