Stanford Seminar: Why Is Computer Security Such a Mess, and Can Object Capabilities Fix It?

TL;DR

Computer security is such a mess because conventional access control gives programs excessive permissions and makes sharing, delegation and chained services unnecessarily difficult. Every program a user runs can operate with all of that user’s permissions, while a single Netflix action may invoke between a couple of dozen and a couple of hundred microservices. Object capabilities offer finer control without requiring a central authority, so read on for the argument and examples.

Transcript

I guess I better explain this this anti identity guy thing here I've been going to the internet identity workshop twice a year for the past eleven years when I started going I realized that people were often using identity for a proxy for what they really wanted I mean it wasn't this bad but it was almost like the clerk at the Starbucks asked to se... Read More

Key Insights

• Identity can be an indirect proxy: The speaker’s objection is not merely to identity itself, but to using identity when a service actually needs a narrower authorization decision. The Starbucks comparison makes the mismatch concrete. Confirming who someone is can disclose or demand more than is necessary when the immediate transaction only requires accepting six dollars.
• Education changed workshop language: The “anti identity guy” badge served as a conversation starter at the Internet Identity Workshop. Wearing it for about five or six years accelerated opportunities to explain the position. After gaining several converts, the speaker planned to use “an anti identity guy” at the upcoming April workshop, treating that grammatical change as evidence of progress.
• Access control underlies other attacks: The talk excludes many familiar security failures so it can examine the mechanism beneath them. The speaker contends that attackers pursue hardware, protocol, operating-system and cryptographic weaknesses because access control prevents easier action. If an attacker could already perform any operation, techniques such as privilege escalation or TLS downgrade would be unnecessary.
• A simple question became difficult: Access control should answer whether a requester may perform a requested action. The existence of dozens of companies selling products to answer that question suggests that current systems make it unexpectedly hard. The speaker attributes this difficulty not to the wording of the question, but to a fundamental flaw in the way access control is implemented.
• Programs inherit excessive authority: Almost any program a person launches can act with all of that person’s permissions. This means ordinary software may read files unrelated to its purpose, send secrets over the internet or encrypt files. The danger comes from the authority granted at execution time, not only from whether a program was originally intended to be malicious.
• Ransomware illustrates permission failure: A program that can encrypt all of a user’s files can create the conditions for a Bitcoin ransom demand. The example connects a dramatic security outcome to routine permission design. The program succeeds because the system gives it access across the user’s files, showing why broad inherited permissions create a large field for abuse.
• Physical delegation feels natural: In the garage story, authority can pass from the speaker to a son and then to a neighbor without revealing every fact about any participant. The neighbor receives what is needed to complete a specific emergency task. The story demonstrates how people routinely understand delegated, limited authority without constructing a centralized identity and access procedure.
• Digital delegation becomes implausible: The equivalent file-copying request requires the neighbor to obtain access to the speaker’s computer from the son. Audience smiles signal how unreasonable this sounds. Conventional computer access does not provide a natural counterpart to handing over a garage key for one purpose, so a simple emergency favor becomes an expansive and risky authorization problem.
• Service chains multiply decisions: Netflix may invoke between a couple of dozen and a couple of hundred microservices after any click. Each link must participate in satisfying the original request, creating repeated questions about whose authority is being exercised. The complexity is not exceptional, since chained services are presented as a routine part of handling a user action.
• Intermediaries face two identities: When a voice service calls a streaming service or thermostat, it can authenticate as itself or as the user. Neither choice cleanly communicates the exact authority attached to the original request. Using the intermediary’s identity gives it broad service-level permissions, while using the user’s identity continues the system’s dependence on identity as a proxy.
• Policies do not travel automatically: A voice service may be authorized to make a viewing-history request because it serves customers who also use the streaming service. However, the voice service has no way to know the streaming service’s access policy. Authentication proves an identity at a link in the chain, but it does not inherently convey the narrowly bounded authorization intended by the originating user.
• Object capabilities narrow authority: The proposed object-capability approach gives objects their own capabilities instead of relying on programs that inherit every user permission. The existing page describes these capabilities as supporting fine-grained control, delegation, attenuation, chaining and revocation. They can also be generated and managed by users without requiring a central authority, making authority more closely match a requested operation.

Questions & Answers

Q: What is the fundamental flaw in the current computer access control system?

The fundamental flaw is that programs commonly run with all of the user’s permissions. A program therefore may read every file, transmit secrets or encrypt files even when its actual task requires much less authority. This broad grant replaces a precise decision about what one operation should be allowed to do. The result is a system in which a simple authorization question becomes difficult to answer safely. The speaker proposes object capabilities as a way to give objects finer, more limited authority.

Q: Why does the Stanford seminar focus on access control?

The speaker treats access control as fundamental because it determines whether a requester may perform an action. Without it, attackers could do whatever they wanted and would not need more complicated attacks. That is why the talk sets aside Rowhammer, Spectre, Meltdown, Heartbleed, privilege escalation, DNS hijacking and TLS downgrade examples. Focusing on access control allows the seminar to examine why the basic permission decision has become so hard. The many companies selling products for this seemingly simple question are presented as evidence of the underlying difficulty.

Q: Why does the speaker call himself an anti identity guy?

He adopted the label after observing that people at the Internet Identity Workshop often used identity as a proxy for what they really wanted. His Starbucks example asks why a clerk would need a driver’s license merely to accept six dollars. The point is that identifying a person may be broader than authorizing a specific transaction. He began wearing the label about five or six years before the talk because it prompted attendees to ask questions. Those conversations produced several converts and helped spread the distinction between identity and authority.

Q: How can ordinary programs create serious security risks?

Programs run with the user’s permissions, so their power may extend far beyond the work the user expects. A sufficiently powerful program can read all files, send secrets over the internet or encrypt those files. Encryption can then leave the user scrambling to obtain Bitcoin for a ransom. The risk is not confined to one special system program because almost any program can receive the same broad permissions. Fine-grained object capabilities are offered as a way to restrict authority more closely.

Q: What does the garage-key story explain about sharing?

The garage story shows that physical delegation can be both understandable and limited. Mark asks the speaker to park a car, the speaker cannot do it, and a neighbor can obtain the garage key from the speaker’s son. The corresponding digital request, copying a file between computers through the same chain of people, sounds implausible because it requires broad computer access. This contrast explains why the speaker calls sharing a mess. Digital access systems fail to represent the narrow, transferable authority that the physical key naturally provides.

Q: Why are chained microservices difficult to authorize?

A single Netflix action may invoke between a couple of dozen and a couple of hundred microservices. Every service in that chain helps satisfy the original request, but conventional authentication does not neatly communicate the request’s limited authority. The voice-service example makes the problem smaller by tracing a request from a remote through an intermediary to a streaming service or thermostat. The intermediary must use either its own authentication or the user’s. This creates uncertainty about whose permissions apply and what the downstream service’s policy permits.

Q: What is wrong with a voice service using its own authentication?

The voice service may legitimately need permission to issue requests for customers who use both it and the streaming service. If it authenticates as itself, the streaming service can honor a request that falls within those broad permissions. That creates the possibility of requesting another customer’s viewing history. The voice service also has no way to know the streaming service’s access policy. Its identity therefore does not communicate whether the originating user specifically authorized that particular request.

Q: How do object capabilities simplify access control?

Object capabilities associate authority with objects instead of giving every program all of a user’s permissions. This supports finer control because a capability can correspond more closely to the operation that needs to be performed. The existing page also identifies delegation, attenuation, chaining and revocation as capabilities of the approach. Those properties address the sharing and multi-service problems illustrated by the garage and voice-service stories. Users can generate and manage object capabilities without making a third-party central authority necessary for the system to function.

Summary & Key Takeaways

• Questioning identity as the default: The speaker begins by explaining the “anti identity guy” label worn at the Internet Identity Workshop. After attending the workshop twice a year for eleven years, he concluded that people often use identity as a proxy for what they actually need. He compares this habit to a Starbucks clerk requesting a driver’s license before accepting six dollars. Wearing the label helped him educate more attendees, gain several converts and consider changing “the anti identity guy” to “an anti identity guy.”

• Narrowing the security discussion: The seminar deliberately sets aside hardware attacks such as Rowhammer, side channels such as Spectre and Meltdown, protocol errors that led to Heartbleed, privilege escalation, DNS hijacking and TLS downgrade attacks. The speaker instead concentrates on access control because it is fundamental to security. Without access control, attackers would not need those other techniques because they could simply do whatever they wanted. The central question sounds simple: are you allowed to do what you are asking to do?

• Exposing excessive program power: The first example concerns a powerful program on everyone’s computer that can read every file, transmit secrets over the internet or encrypt files and force the owner to obtain Bitcoin for a ransom. Yet people use this kind of program at work, sometimes for hours. The deeper problem is broader than one application. Almost any program can cause comparable harm because every program a person runs receives all of that person’s permissions. This illustrates the lack of fine-grained control in the prevailing model.

• Contrasting physical and digital sharing: The speaker compares two emergency requests. Asking a neighbor to park Mark’s car using a garage key obtained from the speaker’s son sounds ordinary. Asking the neighbor to copy a file from Mark’s computer to the speaker’s computer by obtaining access from the son sounds ridiculous. The contrast shows that digital systems make delegation much harder than familiar physical arrangements. Existing access rules do not naturally express temporary, limited and transferable authority, leaving ordinary sharing complicated and unsafe.

• Following permissions through service chains: A Netflix action can invoke between a couple of dozen and a couple of hundred chained microservices. A simpler example connects a voice remote to a third-party voice service and then to either a streaming service or thermostat. The intermediary must act using either its own authentication or the user’s. If it uses its own authority, it may possess permission to request another customer’s viewing history, yet it cannot know the streaming service’s access policy. Object capabilities are proposed as a simpler basis for controlled delegation and chaining.