Re: Proposal of SE-PostgreSQL patches (for CommitFest:Sep)

> Yeah, that's what I keep hearing that the spooks think they want.
> I can't imagine how it would play nice with SQL-standard integrity
> constraints. Data that apparently violates a foreign-key constraint,
> for example, would give someone a pretty good clue that there's
> something there he's not being allowed to see.

Right, so you don't let that happen. If you're giving Mr. X access to
the "cities" table, and decide to restrict him only to cities in
Europe, then if you give him access to the "informants" table, you'll
probably restrict that to only informants located in cities that are
in Europe, so, no problem. It's easy to come up with cases where
there is a problem but just because there can be problems doesn't mean
the technology isn't basically useful.

I don't think there's much point in second-guessing the NSA: they are
smart and have thought about this more than we have. But I do think
it's worthwhile to ask whether it makes sense to introduce a bunch of
features that are only usable to people running SELinux. Column-level
permissions are the best example of this: it's very easy to imagine
people wanting that feature, but NOT being willing to run SELinux to
get it. It's more arguable whether data hiding falls into the same
category or not, because if you're doing data hiding then arguably
you're a security nut and more likely to be running (or willing to
run) SELinux. Against that, my boss made me do data hiding but we
have no interest in SELinux, so that's one data point the other way,
though not one I'd take all that seriously.

So far there has been no detailed discussion of any of the new
security features that are in this patch (column-level security,
row-level security, large object security, etc). For each of those
features, we need to answer the following questions:

1. Do we want this feature as a part of PostgreSQL at all?
2. If #1 is yes, do we eventually want to expose this feature via a
SQL interface, or some other interface substantially unlike
SE-PostgreSQL?
3. If #2 is yes, will accepting this patch get us closer to that goal
or further away from it?

I suspect that for most of the features the answer for #1 will be yes,
but the other two questions need some more careful examination.

...Robert