Re: 8.4 release planning - Mailing list pgsql-hackers

Andrew Sullivan wrote:
> On Tue, Jan 27, 2009 at 12:41:36PM -0500, Stephen Frost wrote:
>> * Gregory Stark (stark@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 <kaigai@ak.jp.nec.com>