Josh Berkus wrote:
Stephen Frost wrote:
* Gregory Stark (st...@enterprisedb.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).
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
