[cap-talk] Reinterpreting POLA - "Authority Must Not Exceed Trust"

[Matej Kosik]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Friends,

David Wagner wrote:
> Toby Murray writes:
>> Given some means to calculate the authority A_o of each object, o, in a
>> system, and given the authority we're willing to trust each object to
>> wield, A_o', the system is insecure if for some o, A_o \superset A_o'
> 
> "the authority we're willing to trust each object to wield" is not an
> objective criteria.  It cannot be measured.  It is not a yardstick that
> a software developer can use: it is not realistically measurable.  Users
> make trust decisions for all sorts of peculiar and subjective reasons.
> My sister might trust any software that comes in professional-looking
> packaging, my brother might trust anything at all, my mother might trust
> whatever her friends use, and my father might not trust any software.
> There is no one answer, and the answers may not be rational, and they
> are probably not a very useful basis for making engineering decisions.

I would not be so pessimistic in this point. Surely, ordinary users have no idea concerning
appropriate authority for a given program. On the other hand, they should be able to rely on
security policies (developed or even perhaps selled) by parties to which they trust. People usually
trust to other people according to the credit they have and these relationships are ubiquitous. This
is realizable because identities of security auditors are need not to be feasibly forgeable (if they
digitally sign their security policies).

The roles:
- - programmer
- - security auditor
- - user
may but need not be played by a single person. If some person wants to be a security auditor, it has
to build a credit in this area. Similarly as layers, medicians, banks etc.

A similar system (for estabilishing trust between people who never physically meet) is described in
Earthweb sci-fi.

The addition of the "authority we are willing to grant" (in addition to "authority a given software
actually needs") is I think obvious and I use it in my previous documents too and I think it has sense.

Sometime "security auditor" is the person/group that is responsible for composition of an operating
system. They can get a some (untrusted) driver and the only thing they have to review is the
security policy applied upon that driver. Not the inner workings of that driver.

Sometime "security auditor" is a group of people who are distributing some operating system (such as
RedHad). They build their security policies over particular applications that are part of this
system (RedHad uses SELinux as a security mechanism. SELinux deals with current legacy and some
people need exactly that.). Of course, other groups can create their own security policies and
people can use them if they trust them.

> 
> The "we" in "we're willing to trust" is ambiguous.  To quote Tonto,
> who's we, kemo sabe?
> 
> Do you know anyone who sits down and decides how much they're willing to
> trust each object in a piece of complex software before deciding whether
> to install that software?  Users don't do that.  That'd be ridiculous.
> If you ask a user how much they're willing to trust each object, the
> most likely answer you'll get is probably "Huh?".
> 
> Finally: Authority is just one aspect of security, it is not the
> whole forest.  I don't think that trying to define security in terms of
> authority is going to work.
> 
> Analyzing how much authority is granted to each object may well be a
> useful thing to do.  That doesn't mean it is the definition of what it
> means for a system to be secure, though.  Buckling my seat belt when I
> get in the car is a good idea, but that doesn't make it the definition
> of safety for cars.
> _______________________________________________
> cap-talk mailing list
> cap-talk at mail.eros-os.org
> http://www.eros-os.org/mailman/listinfo/cap-talk
> 

Regards
- --
Matej Košík
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFG76KNL+CaXfJI/hgRAsakAKDOINoC9y/DuwqqWkGwH3AqU5yXuACguvV0
lBt3lIkR2nNlDY7IqQKS2pg=
=u2/D
-----END PGP SIGNATURE-----