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

[Marcus Brinkmann]

At Wed, 24 Sep 2008 18:35:30 +0000,
"Karp, Alan H" <alan.karp at hp.com> wrote:
> 
> Marcus Brinkmann wrote:
> >
> > I am not saying that there can't be a qualitative difference per se.
> > But we should be careful in picking out examples, in order to make the
> > strongest points possible.
> 
> You're the one who chose this particular example :)

Yes, but not in defense of capability systems ;)

> > That is a strong statement to make, considering that there are many
> > more metrics than restricting authority in any real world system, and
> > the most persuasive arguments for capability systems are about
> > restricting authority and not any of the other many things people are
> > interested in.  It is not a priori clear to me that the properties of
> > capability systems you like most can be preserved once the other
> > demands are brought in.
> >
> I stand by my statement.
> 
> O The virus problem is a direct result of applying least privilege
> at the granularity of the user.  Every process runs with the user's
> permissions, allowing erroneous or malicious code to do anything the
> user may do, even if the user doesn't want it done.  Polaris shows
> that you can address this problem with ACLs, but it is an attempt to
> retrofit capability principles on an ACL system, and it has
> deficiencies because of that.

I know that the theory is that Unix is just as vulnerable to viruses
as Windows, and that attackers are just picking the lowest hanging
fruit.  However, although from an operating system design perspective
Windows and Unix are not very different, the socio-economic factors
are very different between Windows and GNU/Linux.  The virus problem
may be attributable to other causes than the failure to apply POLA at
a finer level than users.  I think we are lacking data for comparison.

There are other potential problems I see with your reasoning as well.
Viruses may just as well spread from browser to browser than from user
to user.  To be member of a botfarm it may be sufficient to have some
CPU resources, a virtual machine to execute in, and internet access.
For phishing user data, it's usually sufficient to ask for it.  It's
not clear to me that avoiding per-user viruses is sufficient to
address the problem.

I don't claim that I know enough about these problems to refute you.
Maybe there are simple responses to my challenges.  If there are, I
don't know them :(

> O The problems with managing ACLs are well known.  Even the Open
> Group in "CDSA Explained" says, "However, straight ACL operation can
> put an administrative load on the resource owner that can become
> excessive.  Therefore, we assume that there are times when the
> administrator wants to do something better than a straight ACL."
> That raises the question of why not use the "something better" all
> the time.  They go on to describe the something better, which is
> essentially capabilities.

My main interest are desktop systems.  These systems must be
preconfigured, and their configurations do not need to be very
dynamic.
 
> O Our experience with capabilities is that managing rights at fine
> granularity is easier than managing them at a coarse grain.  With
> capabilities user acts of designation result in the transfer of a
> small set of rights without the need for confirmation dialog boxes.
> Since there is no convenient way to do that with ACLs, users are
> forced to share large chunks.  Managing the risk of sharing so much
> authority adds considerable complexity both to the user interaction
> and the underlying infrastructure.

This presumes a need for managing access at that level, which I only
see for a couple of applications.  I am not worried about solitair.exe.

> O User-Group-World is too crude a sharing model.  Actual patterns
> are far more complex, which is one reason Microsoft introduced a UI
> for directly manipulating the ACL.  Unfortunately, in attempting to
> enable the sharing patterns people want, they made it so complex
> that it's possible to prevent anyone from logging in.  (I can find
> the citation if anyone is interested.)

I am not sure which use cases require that fine manipulation of ACLs.

> O Object capabilities make it easier to write applications in which
> a single breach doesn't compromise the entire program.  Security
> reviews of such programs are considerably simpler.

From my experience of working on the GNU/Hurd, debugging such
applications is a lot harder, because it is harder to identify objects
and the processes implementing them and following execution flow
across process domains.

> What other metrics are you thinking of?

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.

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.

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.

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.

Thanks,
Marcus