Re: Questions for Meredith

(Catching up on some stuff I've been rather lax on ...)

Quinn Weaver wrote:
> On Fri, Jan 12, 2007 at 10:50:23PM -0800, Meredith L. Patterson wrote:
>> For instance, if you could remove the rule
>>
>> <a_expr> ::= <a_expr> OR <a_expr>
>>
>> from your sublanguage, you've just removed the "OR 1=1" attack while
>> still allowing other <a_expr>s into your WHERE clause.
>
> It would be nice to have a good default restricted language built into
> Dejector. For instance, Dejector should probably _always_ disallow the rule
> you cite above, unless the client code explicitly overrides that behavior.
> You know, secure by default... because otherwise people won't do it right.

There are pluses and minuses to this approach, from both a philosophical
and a practical standpoint.

On one hand, it would be terribly nice to find a one-size-fits-all
solution, but I doubt that if you put five DBAs in a room you could get
them all to agree on what constitutes a sufficiently secure sublanguage.
(You might be able to get them to agree on a minimal set of things to
exclude, but I'm not confident that set would provide all that much
protection.)

On the other hand, there are a lot of programmers out there who just
aren't interested in security or don't have the mindset for it, and if
Dejector were to become an industry standard, a default restriction set
could help protect them from their own ignorance. That said, encouraging
all the other developers out there to place their systems' well-being in
the hands of Dejector's developers might not be the height of sanity,
either. Life suddenly gets really awful when someone figures out a way
to inject something around the default set and boxes with nothing but
that are suddenly compromised.[1] It gets worse when you're not
Microsoft and you don't have an infrastructure in place to push security
patches out to people.

(Apparently the philosophical pros have practical cons, and vice versa.)

If it seems like I'm straddling the fence here, well, I am. :) More than
anything, I'd like to see Dejector used as just one part of a multi-tier
database security strategy; in a perfect world, people would have the
time and the knowledge to do the job right the first time, which ideally
would include turning off individual rules when necessary. But it's not
a perfect world, and Dejector's just a tool; some people will use it
well and others, probably far more others, will use it badly. So I think
the real question is whether it's possible to find a solution that isn't
so restrictive that nobody will want to use it, yet not so permissive
that it causes more problems than it solves.

One start might be to have several possible default rule exclusion sets
that the user could invoke when constructing a validator. Give them
increasing degrees of paranoia, similar to Internet Explorer's security
profiles (or whatever they're called; I haven't used IE in nearly five
years now). The problem there is that someone might, as I footnoted
earlier, think they're perfectly safe if they use the tinfoil-hattiest
ruleset and an exemplar that's bracketed end-to-end. That case wouldn't
be the end of the world -- as I pointed out during the meeting, having
an exemplar at all limits you to <stmt>s of only that type, so a SELECT
statement cannot be replaced with an INSERT or a DELETE. But it's still
not good.

Another approach could be a config file listing rule expansions the
developer Considers Harmful, which then gets referred to at runtime.
Include a default .cfg with the distribution, and truly clueless
developers won't even notice it's there. My collaborator Rob objects to
this idea on the grounds that Dejector is about restricting a
sublanguage, not expanding it, and a developer who's just clever enough
to be dangerous could screw himself by allowing too much back in. I
disagree, on the grounds that a sublanguage is mostly defined by the
parse of the exemplar, and there need not be a way to reintroduce a rule
that the exemplar has pared out. It should not, for instance, be
possible to add in the rule <stmt> ::= <DeleteStmt> if your exemplar is
a SELECT. So in the worst case, somebody removes something like <a_expr>
:== <a_expr> OR <a_expr> from the Considered Harmful list and is no
worse off than they would have been without such a list.

I'd very much appreciate everyone's thoughts on these questions; they're
design, usability and security issues that would greatly benefit from
the expertise of the folks here.

(One meta-design issue, btw, is that Rob and I ultimately intend
Dejector to be not only cross-database but cross-CF-input-language. It
would be ideal if the design for whatever approach we take to removing
rules could be extended to XML, XPath, &c. without too much effort.
Adding a collection of security settings to the API strikes me as much
more tightly coupled to Postgres than some mechanism for removing
individual rule expansions -- but would a collection of security
settings be easier for users to grok? In the latter case, would it be
necessary to figure out the "safe territory" for every language we apply
this to? If so, uh, ow, and pretty much impossible for custom XML
schemas...)

And, finally, a more theoretical-linguistics-y notion that just popped
to mind: it occurs to me that the rules that we're identifying as
inherently risky are *functional* expressions, as opposed to content
expressions. They're the Postgres equivalent of conjunctions,
prepositions and auxiliary verbs.

OK, on to the rest of Josh's email...

--mlp

[1]Of course, if a developer is using an appropriate exemplar string,
his sublanguage would be much smaller than this hypothetical default
set. But there's always going to be some idiot who brackets the entire
string and has nothing but the default watching his back.