[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Gnash-dev] Whitelists and Blacklists

From: Eric Hughes
Subject: [Gnash-dev] Whitelists and Blacklists
Date: Wed, 02 May 2007 08:20:23 -0600

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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]