[Gnash-dev] Whitelists and Blacklists

[Eric Hughes]

There's been a low hum of talk about whitelists and blacklists.  I want to 
use these mechanisms to illustrate some broader principles about security 
design as well as to point the way to decent implementation of these 
mechanisms.

(1) I find it useful to view security mechanism as containing inference 
engines, almost always implicit, that provide yes/no answers to a class of 
authorization questions: "Shall I allow actor X to perform operation Y on 
object Z?"  Framed as an inference question, we can immediately ask the 
question of interpretation about the data stored within the mechanism: 
"What is the predicate assertion implicit in a security item?"

Take a whitelist as an example.  First, a whitelist for what 
operations?  Without further specifying, we might say "for any operation Y 
on any object Z".  Or perhaps "for any operation Y on cookies".  Each of 
these are whitelists.  My point is that just tossing about the word 
whitelist is ambiguous.

Consider a whitelist of domain names and IP addresses.  Does an item in 
this list refer to an actor X, an operation Y, or an object Z?  Well, it 
can refer to any or all of the above:
-- An actor X.  We might consider a domain a proxy for the identification 
of an actor or, more realistically, a class of actors with common 
authorization.  Requests arriving from domain X are allowed.  The predicate 
assertion is "for all operations Y and for all objects Z, X is permitted to 
perform Z.Y" (assuming Z.Y is well-formed, of course).
-- An operation Y.  A domain isn't an operation itself, but it might be a 
parameter to an operation, for example, "connect to Y".  A whitelist of 
this form might assert "All users X may use my server Z to connect to 
Y".  Mock-algebraically: \forall X, Z: Z = myserver \implies perm( X, 
Z.connect(Y) )
-- An object Z.  A domain may be a proxy for a network operations to and 
from that address.  This is typical of application-level firewall 
rules.  For example, "My users X may do anything with server Z".  (Note 
that "my users" is typically using a local network address as a proxy to 
identify an actor X.)

For a blacklist, substitute "\not perm" for "perm" in the predicate assertion.

So, when speaking about whitelists (and blacklists), first, please be more 
specific.  I'm not requesting ultimate precision, simply more than just a word.

(2) Consider the issue posed thus: "Should YouTube be on a whitelist?"  Is 
YouTube an actor, an object, or an operation?  We might pose it as any of 
these, relative to what we are securing.  I'll argue, though, that in the 
way it's been discussed, that YouTube is an actor.  We say "we can't allow 
YT to load any old arbitrary SWF and run it".  This is the role of an actor.

So here's the first improvement I'd like to make for Gnash.  For our 
whitelist, we document what it means and use it accordingly.  At least we 
will want a whitelist of actors.  We might also want other whitelists.  And 
respectively for blacklists.

(3) Consider a whitelist and a blacklist together.  We may consider these 
as representing a set of predicate assertions, or, in the language of 
formal logic, an axiom set.  Well now some questions become conventional:
-- Are the axioms consistent?
-- Given a predicate, do the axioms imply it?
-- Given a predicate, do the axioms imply its negation?
-- Given a predicate, is there an effective algorithm to determine its 
provability and, if so, its truth value?

Of particular note is the issue of non-provability.  In this case our 
inference mechanism doesn't give us an answer, but our software must 
nevertheless have one.  This is the origin of a cardinal rule of security 
implementation: If you don't know, just say no.  This is the rule 
applicable to security with respect to the anonymous general public.  It's 
not a "fascist default"; it's prudence, but also symptomatic of an immature 
inference mechanism and/or axiom set.

This perspective also address the concept of "conflicting rule", one 
solution to which is "priority".  I don't wish to delve into this here 
except to point out that "conflict" is a way of talking about an 
inconsistent axiom set, and "priority" is one way of changing the 
axioms.  Consistency is vital, and there are multiple ways of achieving it.

(4) Practically speaking, it's impractical to expect that every user will 
be able to adequately and correctly populate their own axiom sets to 
sufficiency.  This is the role of security information subscriptions (think 
AdBlock).

There's a particular kind of assertion that a subscription service might 
make: "You can't know who's on YouTube".  What does this say formally?  It 
says: "For any actor X, and for any request from an origin of YT, it is not 
possible to derive X as the source of that request".  The consequence of 
this, practically, is to recommend that X not be put on the actor 
whitelist, since it doesn't represent any single actor.  Otherwise, we'd be 
violating the principle of prudence.  We can always put it on the 
blacklist, which doesn't violate.

Eric