[cap-talk] Capabilities and Freedom vs. Safety

[David Chizmadia (JHU)]

James,

    I will make every attempt to be clear and unambiguous in the way
that I phrase my observations below.

    For any statements with which you disagree, please do me the
courtesy of reading the questionable statement a couple of times
with a break between the readings to let other possible
interpretations of the words present themselves.

James A. Donald wrote:
> David Chizmadia (JHU) wrote:
>> In a pragmatic sense, your situation is akin to the
>> case of an evangelical Christian minister discussing
>> how to live life as a member of the faithful with a
>> group of Muslim imams.
> 
> Almost true -

    I maintain that it is completely true, since the fundamental
sources of miscommunication appear (to me) to be our differing
mental models of how a permission is managed within a computer
system and how and where we set our reasonable expectations of
security for a computer system.

> except that I have advocated using non
> communicable privileges where such are appropriate,
> generally for great or durable privileges such as the
> authority of a powerbox to read the entire file system,
> and write to most files therein, 

    My following statements are drawn from my experiences as a
TCSEC/ITSEC/CC evaluator and developer, where I have had the
opportunity to see how four high assurance and two lower assurance
products have chosen to implement label- and ACL-based access
control requirements.

    On the basis of these six samples, I have inductively come to
the rather tautological conclusion that the only difference between
a non-communicable and a communicable privilege is the actions of
the first piece of software that comes into possession of the
privilege. That is, the software that first comes into possession of
a non-communicable privilege is carefully written, and then even
more carefully reviewed, to ensure that the privilege is never
shared with any other software in the system. This is in contrast to
a communicable privilege, which first comes into the possession of
software that intentionally shares (or is tricked into sharing) the
privilege with other software in the system.

    The lesson that I have taken away from this is that all
privileges are equal - only the software matters with respect to the
communicability of the privilege.

> and communicable
> privileges where such are appropriate, generally for
> small and transient privileges, such as the privilege of
> an editor to edit a particular file.
> 
> Thus I am more in the position of a tourist to Saudi
> Arabia who wants to go to the beach, drink a scotch,
> celebrate Christmas, and tour the famous mosques, than
> in I am in the position of an evangelical Christian
> visiting Saudi Arabia.

    I can't disagree with your assessment, since all of those
actions have been known to provoke rather incendiary reactions in
Saudi Arabia :-(

> I am not the advocate of extreme purity and abstinence
> from sin in this debate.

    Nor are any of the other people who have posted to the list.
>From an engineering standpoint, all of the threads that I have ever
seen (I will admit that I have missed many threads, so these
conclusions might not be true for *all* threads in the archives - I
actually look forward to any counter-examples) here have converged
on conclusions that
  * An ocap design solution can be found for nearly all enforceable
    security problems;
  * Security problems for which an ocap design solution cannot be
    found are almost always intrinsically unenforceable;
  * In the cases where an enforceable security problem cannot be
    expressed with an ocap design solution it is also the case that
    the ACL/label design solution will be subject to all of the
    intrinsic design flaws of that access model;

    On the other hand, the ocap community is attempting to displace
a firmly entrenched ACL community that has an overwhelming economic
incentive to ignore any real solution to the problems from which
they derive profit. As a result, the ocap community is held to a
much higher standard of "evidence" than the ACL community. The main
reason that so many people on this list use the word "proof" (or
"prove") is that our experience is that we can't even be *heard*
unless we *prove* that ocaps are better than ACLs.

    So, when skeptics say "prove it", the ocap community very much
wants to have a consistent body of arguments that do just that.

> Security must be based on real attacks and real threats,

    Absolutely!!

> not on "proofs" of security which have little contact
> with reality external to that proof.  Nor can any usable
> desktop system be entirely secure - rather the attack
> surface can be reduced, and the system can be rendered
> reasonably secure, at some cost, against the worst
> threats, but not against all possible threats, for there
> are a great many possible threats.  Thus "proof" of
> security, when applied to desktops, is apt to prove that
> which cannot possibly be true.   A particular algorithm
> can be secure against a short list of relevant threats,
> and can frequently be proven secure against such a short
> list.  (Whereupon, as with PKI, the adversary fails to
> stick to the list that has been assigned to him.)
> Securing a desktop environment is a large and amorphous
> problem with an equally large and amorphous set of
> threats, thus "proofs" tend to be so detached from
> reality as to be strawmen.  One example of such a
> strawman being the prospect of capabilities as data
> so durable as to be compiled into a program image.
> 
> The correct approach is that taken in Bifrost, which
> enumerates numerous specific concrete real world
> attacks, by realistic adversaries, and takes a wide
> variety of concrete measures that will be effective
> against all or most of those attacks, or will
> substantially reduce the prospect of those attacks, even
> when they cannot be entirely eliminated.  Among those
> measures, are the use of communicable privileges, to
> make drastic limits on ambient privileges workable.  But
> ambient privileges are present in Bifrost. Communicable
> privileges in Bifrost are necessary because ambient
> privileges are for the most part severely limited, not
> because they are entirely absent.

    Only time will tell, but I'll wager that most (if not all)
successful attacks against the BitFrost system will vector in
through the ambient privileges. As you like to note, the attacker
doesn't follow the script!

    The interesting exercise in 2 years will be to make the
relatively easy port of BitFrost applications that have been
exploited to Coyotos or CapROS and attempt to mount the same attacks
in an environment with no ambient authority. Unfortunately, we'll
have to defer that discussion until we have working BitFrost and
Coyotos/CapROS systems.

> For every kind of privilege, we need a system for
> providing, limiting, and restricting that privilege that
> is best suited to facilitating rightful uses of that
> privilege, preventing wrongful uses of that privilege
> and protecting against realistic attacks.  The system
> necessarily depends on the case, requiring a multitude
> of systems.  One size is unlikely to fit all.

    I've interpreted the above paragraph to make the following
assertions - none of which I have any problem supporting:

1.  A powerbox is needed for each privilege;
2.  The powerboxes for different privileges may be different:
    specifically, they may enforce different policies for providing
    limited or restricted privileges derived from the original
    privilege to other software in the system;
3.  There exists a mechanism for enforcing the limitations and
    restrictions embodied in the derived privileges distributed by
    the powerbox.

> It is certainly true that for communicable permissions
> involving a single user on a single computer,
> "protected" capabilities - privileges that are simple
> unprotected data a ring<3 (OS code), but at ring 3 (user
> code) are not data, but relationships with the operating
> system, are apt to be simple, efficient, and provide
> provable security against certain types of error or
> defect in ring 3 code - protected capabilities are the
> most useful and best for many valuable tasks.  One
> should not however conclude from this that everything in
> the world should be rewritten in terms of protected
> capabilities, for the provable security they provide is
> provably secure against the least of our problems.

    It would be instructive for all of us if you could state the top
20 problems that you perceive. An ordered list would be best (so we
could get a sense of the relative importance that you place on
things), but even an unordered list would provide a starting point
for more focused discussion.

> I doubt that rewriting everything in terms of protected
> capabilities is a good idea, and I am sure that even if
> it is a very good idea, as many on this list have
> plausibly and passionately argued, it is not going to
> get done.

    I fully acknowledge that it is unlikely in the extreme (barring
a sudden large windfall from a true believer in ocaps) that all
major existing software will ever be rewritten in terms of protected
capabilities, but I will go on record as thinking that it is a great
idea!!  :-D


-DMC