Missing the point on Slashdot... yet again

Slashdot gets close to the truth... and then totally blows it, as usual. 

A recent story pointed out that there will be funding for Minix, one of the goals being to figure out how to build a provably secure OS kernel.

From the project proposal: (warning: pdf)

The most serious reliability and security problems are those relating to the operating system. The core problem is that no current system obeys the POLA: the Principle Of Least Authority. The POLA states that a system should be partitioned into components in such a way that an inevitable bug in one component cannot propagate into another component and do damage there. Each component should be given only the authority it needs to do its own job and no more. In particular, it should not be able to read or write data belonging to another component, read any part of the computer’s memory other than its own address space, execute sensitive instructions it has no business executing, touch I/O devices it should not touch, and so on. Current operating systems violate this principle completely, resulting in the reliability and security problems mentioned above.

So... in my opinion, this is the key take away... to build something actually secure, instead of trying to use the tired old language X is insecure chestnut or other assertions.

Slashdot encourages responses based on emotion and ego, and doesn't provide proper incentives to actually help discover truth and learn new things. There has to be a better way.

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.