Re: SE-PostgreSQL and row level security

On Mon, Feb 16, 2009 at 10:54:32AM +0000, Gregory Stark wrote:
> > Both of SE-PostgreSQL and vanilla PostgreSQL don't give an assurance to
> > eliminate information leaks via such kind of covert channels, so they
> > don't violate any specifications of them. Thus, it is not a problem.
>
> If that's true then I don't see why we would try to automatically hide records
> you don't have access to. The only reason to do so is to try to close these
> covert channels and if we can't do that then I don't see any benefit to doing
> so.

To me the reason you automatically hide records is because otherwise
everyone has to rewrite all of their queries since accessing anything
you don't have rights to would generate an error (and abort the
transaction and be a covert channel itself).

When you search something in your webmail, you don't have to tick the
box saying "please only show me emails I have permission to access".
That's implied, just like all MACs in the real world.

> If users want to select "all matching records the user has access to" they
> should just put that in the WHERE clause (and we should provide a convenient
> function to do so). If we implicitly put it in the WHERE clause then
> effectively we're providing incorrect answers to the SQL query they did
> submit.

Eh, the result of the query is the correct answer with respect to the
model its applied to. Users of a MAC system are aware that the model
they're working may not be totally logical but setting up an illogical
system is the admin's fault, not SE-Postgres itself.

BTW, it sounds to me like you're suggesting the entire rule system
breaks SQL semantics because it's not executing the query the user
gave. Indeed, if we go down the road of requiring users to apply their
own permission checks, what SE-Postgres users could do is use the rule
system to apply the checks automatically.

Perhaps that's the way to go. For 8.4 provide something that people can
stuff in the where clause and users can use the rule system to apply it
globally.

> 3) The data hiding scheme -- which frankly I think is dead in the water. It
>    amounts to a major change to the SQL semantics where every query
>    effectively has a volatile function in it which produces different answers
>    for different users. And it doesn't accomplish anything since the covert
>    channels it attempts to address are still open.

This doesn't make sense to me. The covert channel you're referring to
leaks the primary key, whereas what it's hiding is an entire row. These
are in no way the same thing, and the hiding is more of a convenience
than anything else (aborted transactions are more annoying). As for
giving different answers to different users, this is precisely what
Veil does (and information_schema for that matter).

Have a nice day,
--
Martijn van Oosterhout   <kleptog@svana.org>   http://svana.org/kleptog/
> Please line up in a tree and maintain the heap invariant while
> boarding. Thank you for flying nlogn airlines.