[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.
Eric
- Re: [Gnash-dev] Building in security, (continued)
[Gnash-dev] Re: Building in security, Eric Hughes, 2007/05/02
Re: [Gnash-dev] Re: Building in security, Martin Guy, 2007/05/02
[Gnash-dev] Whitelists and Blacklists,
Eric Hughes <=