[cap-talk] More Heresey: ACLs not inherently bad

[Karp, Alan H]

(Continuing where I left off last week.)

Marcus Brinkmann wrote:
>
> First of all, access to information.  If information is spread in fine
> granularity across many protection domains, accessing that information
> is made much harder, to the point of being impractible.  The global
> filesystem in Unix that is shared across all processes causes quite a
> number of security issues, but it is easy to understand and manipulate
> (backups, restore, etc).  Having a simple mental model of the
> operating system and introspective tools to verify that model are a
> great aid in working with a system.  For example, I have in the past
> designed a defensive process model for a capability system, where
> subprocesses are managed and controlled by their direct parent, so
> that there is no global storage consumed (no global process table),
> and no denial of resource attack possible.  But the flip-side is that
> it is difficult to inspect the process hierarchy, and to know which
> data is reliable and which is not, because it comes from many sources.

I believe that the solution I proposed to Jonathan's problem meets your requirements (a global namespace with a hashtable per user that maps names to capabilities).  Still, I'm not sure about the statement in your second sentence because of my experience with e-speak.  In e-speak, each client (process) had a private namespace, the root of which was contained in the client's protection domain.  The mental model was a bit different, but familiar enough that programmers didn't have much trouble adapting to it.  The only substantive change was, if you wanted someone to have access to something, you sent a reference to it rather than the name as a string.

I don't understand your comment about data reliability.
>
> Second, collaboration, which is easier if barriers are removed.
> Capabilities provide a way to punch holes through barriers, but this
> requires some extra efforts (how much, I don't know, depends on many
> of the design decisions made).  Discussions on this mailing list have
> shown how hard it is to define what it should mean to share a
> capability with another principal (should it be revocable or not?
> should capabilities fetched through the capability be revocable or
> not?).  These semantic issues disappear in simpler systems.  To choose
> a non-operating system example for collaboration, Wikipedia is
> extremely successful, and its security model is very different from
> capabilities, relying on recoverability and monitoring instead of
> access control.  (Historically, there is also at least one operating
> system example, ITS, which was based on similar principles as
> Wikipedia).  People are very ingenious in overcoming protection
> measures when they want to get the job done, there is a reason why
> bosses give their passwords to secretaries.  The first thing people
> will add to a capability system (if they can and care about it) is a
> root capability that gives access to all other capabilities, and they
> will use it for all sorts of things.

Your first sentence is a widely stated fallacy, most often applied to encryption.  Encryption, the argument goes, hinders accessibility.  However, if the data is important enough to be protected, and encryption is not used, more draconian measures will be needed.  For example, if I don't encrypt customer data, I won't be allowed to carry it on my laptop, which means it is less accessible to me.

Removing access barriers is a hindrance to collaboration.  Every collaboration exposes the participants to risk.  The collaboration will only take place if the benefit outweighs that risk.  The risk will be large if there are no access barriers, resulting in fewer collaborations.

The only reason you don't see the questions you ask about capability systems (revocation, membranes) asked about ACL systems is that you don't have the functionality with an ACL.  Clearly, if there's no way to do something, there's no need to ask how to undo it.  However, the inability to delegate small amounts of authority leads people to delegating large amounts by sharing credentials.  I dispute that people would give up all their rights by creating a root capability if delegating small amounts was easy.  That's certainly the case with the managers I've talked to who currently give their login credentials to their assistants.

>
> Third, functionality.  Every second programmers spend on security they
>  can't spend on other functionality of the software, so there is an
> opportunity cost.  Now, this could be an argument for capability
> systems, because it may be easier to write secure applications with
> capability systems than in other systems.  However, this depends also
> on the surrounding culture.  Taken to the extreme, defensive
> programming is very hard.  If capability systems go hand in hand with
> POLA and defensive programming, progress could actually slow down
> while the GNOME people try to figure out how to do something like
> D-BUS securely.  It's important to strive for a balance.

Delegation in capability systems is a natural consequence of passing arguments.  The absence of delegation in ACL systems is actually a problem.  How do you ensure that the service you're invoking has the authority needed to satisfy your request?  Consider a simple backup service.  Alice invokes Bob's service, passing as an argument the file to be backed up.  In a capability system, the argument Alice passes to Bob grants him the right to read the file.  How do you make that work in an ACL system?  I guess you could modify the ACL on the fly, but that's a lot of work.  The normal solution is to either let Bob impersonate Alice or run as root.  Neither is a particularly attractive option.
>
> Depending on your perspective, you may come to different results.  For
> example, one may consider collaboration in the way of Wikipedia
> unacceptable, while controlled sharing via capabilities together with
> TCM enables collaboration in the first place ("DRM").  I understand
> that this is the case.  Security is not something that can be defined
> in the absence of an environment.
>
I agree with your last sentence, but I would also add that you must also include which aspects of security you are talking about.  I've been assuming we've been talking about access control, but your statement applies to all the other meanings of the word "security".

________________________
Alan Karp
Principal Scientist
Virus Safe Computing Initiative
Hewlett-Packard Laboratories
1501 Page Mill Road
Palo Alto, CA 94304
(650) 857-3967, fax (650) 857-7029
http://www.hpl.hp.com/personal/Alan_Karp