Andrew Sullivan wrote:
On Tue, Jan 27, 2009 at 12:41:36PM -0500, 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).
[…]
do row-level security and security labels. Requiring a where clause
or you throw an error would certainly make porting applications that
depend on that mechanism somewhat difficult, and doesn't really seem
like it'd gain you all that much...
Throwing an error would entail a side-channel leak that would not be
acceptable to the security community, I bet. That said, I have
reservations, along the lines of Peter E's, that the early
design-level objections to the approach were never answered. I
certainly never got any real answer to questions I asked, for what
it's worth.
I will note that I tried to have a look at the literature on this
topic. As I started to read, it became obvious that it was copious,
but pretty well-determined. What bothered me most about the answers I
got was that there never seemed to be an answer to "please outline the
design principles" except for "it's what SE-Linux does". The OS-level
control rules seemed to me to be totally foreign to the database
world, precisely because ACID is a problem in databases in a way it
isn't for filesystems under the traditional UNIX model. I formed the
impression -- only an impression, mind, that there was a poor fit
between SE-Linux and database systems, and that the proponents had
decided that enough caulk (in the form of "don't do that") would seal
the gap.
As I noted before, there is a symmetrical structure between
OS and DBMS.
In operating system, a process accesses objects (like file,
socket, ...) managed by operating system via system calls.
Its security system (filesystem permission, SELinux, ...)
acquires the request and applies its access control rules.
In DBMS, a client accesses database objects managed by DBMS
via SQL queries. Its security system (Database ACL,
SE-PostgreSQL, ...) aquires the request and applies its access
control rules.
We have similar structures everywhere, not only DBMS and OS.
What we should pay attention is a subject entity accesses via
a method provided by object managers (DBMS, OS, ...), and
object managers apply its rules to decide either "allowed"
or "denied" on acquired request.
I haven't (obviously) been paying much attention to this topic since,
but I detect something of the same sort of response in the recent
discussion. Maybe the goal isn't explicit enough. If the goal is
compliance with some set of well-defined tests, what are they? If the
goal is buzzword compliance, what are the tests of that (to the extent
there ever are some)? If the goal is just "security enhancement", I
confess that I am still unable to understand the definitions of
"security" and "enhancement" such that I think we have some
operationalization of what the patch is supposed to provide.
The most significant feature is centralized access control policy
between OS and DBMS. Did you attend PGcon2008?
I talked here we should consider the value of information asset
is independent from the way to store them.
Needless to say, the value of information asset is decided by its
contents. If your credit card number is recorded on a paper,
do you think it has lesser value than recorded on database?
Thus, from the viewpoint of security, we need to consider the
way to apply unified centralized access controls.
SELinux works as "security server". It enables to provide a centralized
access control decision any other object managers (like, Linux kernel,
X-window, PostgreSQL, ...). It is quite consistent because of
common security policy and common clearance of entities.
It finally enables to apply centralized access control policy on
whole of application stack.
Please note that 95% of attacks in 2008 targeted to web system,
so it gives a nightmare for security folks.
Thanks,
I know there are people who think this is cool. I guess, if I were
running the circus, I'd want to know what's cool about it, and why.
Then maybe the project would be in a position to understand whether
that kind of cool is the way it wants to be. But without a clear
problem statement, and a roadmap of how the patches solve the problem,
I'm at a loss. And last I checked (which was, admittedly, not today),
the project pages didn't have that information.
A
--
OSS Platform Development Division, NEC
KaiGai Kohei <kai...@ak.jp.nec.com>
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
