Authorization vs. Authentication

It seems to many that access decisions must be grounded on who is asking for access. This involves identifying a person; can I authenticate this request? Since people are not ‘in’ the computer this ‘who’ quality is generally replaced by ‘principle’ which tries to capture on whose behalf a program is running, and by extension who will get the result of the computation. This seems to be the inspiration of the Unix permission bits kept in the file directory. I argue here that ‘principle’ is a flawed foundation for security and integrity mechanisms.

If you pass me a RO capability for a memory segment so that I can read it to help you solve your problem then I have access to that data. Note that ‘I’ here refers to a program not a person. I may need to delegate such access further to X just as you delegated to me. I can create a new segment and copy the data into the new segment and pass the cap for the new segment to X, or merely pass the capability that you passed to me to X. The results are the same regarding security but the cost of copying was avoided in the 2nd case.

Hydra provided means of passing a capability so as to deny the ability of the recipient to pass it on. No security was achieved and overhead was caused.

Some of the anxiety (and threat) is avoided by rescinding access to the segment before new data is placed there. This plugs the hole where I fill a segment with data, pass you a cap for that segment, and after you return I put new more sensitive data in the same segment and don’t need to let you see the segment again. If I rescind access after I call you there is no way you can see the newer more sensitive data.

The situation is similar for passing read-write caps for segments. If you pass me a RW cap for a segment and I cannot pass in on, yet that is how I know how to solve your problem I can create a new segment, copy the data into the new seg, pass the RW cap for the new seg to X, copy X’s mods back to the old segment, and return. There is no security gain in limiting the passing of capabilities for segments.

These arguments can be applied equally to objects that you call instead of objects that you load and store into.

These arguments lead some to an intense fear of capabilities. They fall back on a familiar plan of including all the code in one address space and one protection domain. This foregoes the advantages of the high grade abstraction that separate protection domains provide and is incompatible with some business plans for metering access to data and software services. The new buzz word ‘API’ is now used to describe a service provided by one institution to another. The API is a description of the formats and meanings of messages between protection domains. The ‘cloud’ presumes that programs from several institutions may share a machine. Such services need high grade abstraction. The factory was invented to overcome these obstacles. In short the caller can show secrets to untrusted code and know they cannot be exported from the platform.