Tom Lane wrote:
Joshua Brindle <met...@manicmethod.com> writes:
Tom Lane wrote:
Right, which is why it's bad for something like a foreign key constraint
to expose the fact that the row does exist after all.
Once again, this is not an issue for us.
Yes it is an issue; claiming it isn't doesn't make it so. You just
stated, in effect, that you don't implement data hiding in the
filesystem because it would break standard Unix filesystem semantics.
We break plenty of standard semantics. Applications generally expect to be able
to unlink files they can write to, to truncate or append. They expect
read()/write() calls to succeed after a successful open(). SELinux is more fine
grained than POSIX/UNIX is so some of these fundamental assumptions got broken.
In the end this created better/safer software, after some growing pains of
course.
How is that consistent with your opinion that it's okay to break
standard SQL semantics in order to implement data hiding in a database?
Please step me through how the SQL semantics are being broken.
From my perspective (I've used databases, written applications for them, etc
but never hacked on a database server directly) this seems pretty straightforward.
There already exists the possibility that you won't be able to read/write one or
more of the tables for which a foreign key constraint exists, how do you handle
it now? Why isn't it appropriate to handle it the same way?
The question of whether there is a covert channel is only a small part
of my complaint here. If it's the judgement of security experts that
that's an acceptable thing, that's fine, it's their turf. But SQL
behavior is my turf, and I'm not happy with discarding fundamental
semantic properties.
Quoting from your other message:
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.
This seems to me to be exactly parallel to deciding that SELinux should
control only table/column permissions within SQL; an approach that would
be enormously less controversial, less expensive, and more reliable than
what SEPostgres tries to do.
It isn't parallel though, in applications using the filesystem specifying
directories where files go is fairly common. In database applications you expect
all the data to be in the same table, having multiple tables with the same
schema to try and separate out data that should be visible to some and not
others isn't acceptable to most people and certainly wouldn't be compatible with
many existing applications.
Further, we have the ability to use per-process namespaces/polyinstantiation on
the filesystem. From what I've heard that is somewhere you are unwilling to go
as a community for postgresql so the options are somewhat more limited.
I'm not trying to pretend that SELinux and sepostgresql are the same thing and
always have to be treated the same. The trusted X work uses the same
infrastructure and security policy language as sepostgres and selinux itself but
noone is comparing windows and pointers to tables and rows.
Type enforcement is a flexible system. You identify the objects that are
important to you in the object manager (postgresql in this case) and assign
types to it and write policies around those types. The SELinux community came to
a consensus quite a while back about what objects were important to us. I had
assumed (perhaps foolishly) that this had been communicated and also agreed upon
in the postgresql community.
If that wasn't the case I hope we can sit down and talk about the model to
determine what objects are important to everyone and talk about the
implementation details afterward.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
