Re: 8.4 release planning

Josh Berkus wrote:
> Stephen Frost wrote:
>> * Gregory Stark (stark(at)enterprisedb(dot)com) wrote:
>>> It does seem weird to simply omit records rather than throw an error and
>>> require the user to use a where clause, even if it's something like
>>> WHERE
>>> pg_accessible(tab).
>
> The idea is for the level of informations security we're talking about,
> someone with limited permissions not only isn't allowed to know certain
> data, they're not allowed to know certain data *exists*. Within the
> SELinux framework, this is accomplished by hiding files you don't have
> permission to see, not merely denying access to them.
>

SELinux does not (and can not) hide the existence of files, as file names are
part of the directory data and not part of the file data.

We can restrict read on the directory so you can't see any of the file names but
this is not a complete solution as anyone with search/create perms on the
directory can enumerate the file name namespace to discover existence of files.

We do not consider that a short coming, anyone who needs to hide existence of
files needs to set up their directory structure to disallow read/search/create
on the directories they aren't allowed to discover filenames in.
Polyinstanciation can also address this issue.

> The presumption is that if you know the data exists but can't access it
> directly, you'll use indirect methods to derive what it is. But if you
> don't even know it exists, then you won't look for it.
>

There are ways to mitigate this in the current security model of sepostgres,
namely using trusted stored procedures to fetch data you are unwilling to let
someone query against directly (or indirectly). Just as with SELinux anyone who
needs this kind of capability would have to correctly design their tables and
stored procedures to address their security goals.

> There's a level above that which I don't think SEPostgres implements,
> which is data substitution, in which you see different data according to
> what security level you are. While this may seem insane for a business
> application, for military-support applications it makes some sense.
>

Trusted stored procedures can handle the above requirement, either by fuzzing
data (consider coordinates x,y are in a table but below top secret you can't
have access to the exact coordinates, the trusted stored procedure can fetch and
fuzz them sufficiently before delivering them to the client).