Capabilities Summarized

One of the things about digging up information about Capabilities based security is trying to find Google terms that have value. It's like learning magic spells. I learned a new one from the video in the previous post...

Ambient Authority - google search

Here's a nice post that summarizes a lot of what Capabilities is all about from Julien Couvreur.

Object Capabilities for Security - YouTube

This video at YouTube looks very interesting... I hope to be able to watch the whole thing later today.

As an educational resource it's pretty good so far.

Update 5/22/2008 - It was VERY useful, and I learned some new terms, like Ambient Authority, and got some new examples to use.

AppArmor

AppArmor is a least-privilege system for Linux which uses the Linux Security Modules interface. Every "armored" application has a profile which specifies the privileges the program requires to do it's job. It's not clear to me right now if this project is still maintained or not, as Novell was leading it, but has since bowed out by laying off the programmers it had on the project.

Tony Jones while giving an overview of AppArmor to the Linux Kernel Mailing List said:

AppArmor is *not* intended to protect every aspect of the system from
every other aspect of the system: the intended usage is that only a
small fraction of all programs on a Linux system will have AppArmor
profiles. Rather, AppArmor is intended to protect the system against a
particular threat.

Now, this isn't a true capabilities system in that the profiles use names, and are explicit, but it does help enforce least privilege, so it's a very strong step in the right direction.

BeyondTrust | Privilege Manager

I came across BeyondTrust, which might be useful for people in a Windows Environment, because it helps lean towards a least privilege configuration for users. It's definitely not a capabilities based system, but still, you might find it useful.

It allows the Administrator to give rights to run some things, without handing over the administrative password.

Persevere - First impressions

The Persevere project is an open source set of tools for persistence and distributed computing using intuitive standards-based JSON interfaces of HTTP REST, JSON-RPC, JSONPath, and HTTP Channels. The core of the Persevere project is the Persevere Server. The Persevere server includes a Persevere JavaScript client, but the standards-based interface is intended to be used with any framework or client.

The interesting thing about this is that they mention capabilities in their security model, and they offer support for pluggable security modules. So, even if they don't due "pure" capabilities, someone else could add a library that does.

A tweet in the wilderness, calling for help.

Thomas Hawk recently tweeted:

I wish Blogger's moderate comments system was smart enough to whitelist people. I hate having to reapprove legit users over and over again.

Now, this is a call for capabilities if I've ever seen one. He wants to be able to delegate a capability to someone.

OATH: Open sourcing the mark of the beast??

OATH - initiative for open authentication | All users, all devices, all networks.

Ok, this one creeps me out a bit... they really, REALLY, REALLY want to make sure the user who is connected to whatever little box really is who they say they are. This project seems to want to build the backend to the REAL ID act of 2005.

Aside from my personal aversion, they are a STRONG IDENTITY project. You would have one set of keys to the kingdom, that would open everything. One ring to rule them all.

LBNL: Delegating responsibility in digital systems

Here's an interested article about Object Capability Systems, which they call ocaps from LBNL. They argue that the need to have a user to blame is one of the reasons that drove the adoption of the ACL security model. They then go on to introduce Horton, a system to help merge the best features of ACL and Capabilities models.

I don't understand the rest of it, for now, it's way over my head. I now understand a bit more about the ACL vs Capabilities history, and that's enough for me.

OAuth

OAuth is:

An open protocol to allow secure API authentication in a simple and standard method from desktop and web applications.

OAuth is a limited implementation of capabilities. A token allows proxy access to a resource on the internet. This eliminates the need to share authetication information.

They do a lot of great things. Their home page is clean and simple. They have example code in many programming languages. They have a FAQ section, chat and a wiki.

What is Capabilities Digest?

I'm pushing an agenda, Capabilities as a means of fixing a lot of the problems with computer security. The most effective way to push an agenda in 2008 appears to be the same one that has worked for a very long time... find an area to focus on, and try to occupy it. Traditionally this occupation is in terms of knowledge or skill.

I'm spending time and innumerable frustrating searches on this topic. Capability based security is not even close to Google friendly. Because there isn't a specific set of buzzwords to describe the concepts involved, the terms that do get used are sufficiently common that most searches get a ton of noise. I've spent a lot of time finding things of interest, so I'm sharing what I find on this topic, in this one space.

I'll keep original articles and other thoughts at my regular blog, and occasionally link back to it.

I'll also be pointing out things that are related, but near misses.

For example, I came across OAuth, which is about delegating access to Internet accessible resources without the need to share authentication information in a standard way. It's a good step in the overall evolution of security, but is not capabilities oriented.

I'll also be using Labels (tags) on the posts, with Hit or Miss to indicate if a given post is about a find that is or is not truly capabilities based.

In summary... I'm setting myself up as a gatekeeper to judge what is/isn't capabilities.