Re: Updates of SE-PostgreSQL 8.4devel patches

Peter Eisentraut wrote:
> KaiGai Kohei wrote:
>> As I repeated several times, SE-PostgreSQL applies the seuciry policy
>> of SELinux to achieve consistency in access controls. This feature
>> enables to restrict client's privileges on accesses to database objects,
>> as if it accesses to filesystem objects. Its background is our nightmare
>> for web application flaws.
>>
>> The major purpose of this feature is to provide the most important
>> component to run enterprise class web application with least privilege
>> set which is consistent at whole of the system.
>
> How important is this consistency goal in reality? We typically
> recommend that database applications run entirely in the database, for
> transaction integrity reasons and so on.

It is a bit pointless.
The "consistency" in this term is also applied to references to static
web contents, like Jpeg images, PDF documents and so on.
These are not accessed via web application and databases because httpd
makes a response directly, but most of web applications are constructed
with dynamic and static contents.

Have you seen the example?
http://kaigai.myhome.cx/index.php (id: foo/var/baz pass: sepgsql)

It returns different query result based on the security context associated
with HTTP authenticated user. In like wise, your accesses to the listed
three Jpeg files are also restricted.
In both cases, a user "foo" cannot access anything except for objects
labeled as "FooData" or unlabled.

> Of coure, this is an ideal state, and we all of to break that once in a
> while. But hence the honest question, how often does that really happen
> and to what extent, and does that justify the significant investment
> that is being proposed here?

I think it is very usual case.
For example, it is a usefull case for a web-based document management
system to apply consistent access control policy for database tuples
and pdf documents on filesystem.

> Then, how does MAC help with SQL injections? Using the existing
> role-based system you can already define least-privilege users that are
> essentially powerless even if SQL injections were to happen. I am not
> aware that important flaws or gaps in our role-based access control
> system have been pointed out that would make it impossible to create
> applications with security levels similar to those achievable with a MAC
> system.

This feature is mainly placed on fine-grained access controls.
If 50% of tuples are invisible, the scope of dameges are limited.
However, please consider a case when connection string is hijacked
and malicious SQL is injected. As widely known, it is almost impossible
to eliminate all bugs withing various kind of web applications.

> Now, if you come back to your original goal of consistency in access
> control, then it may in fact turn out that an
> FLASK/SELinux/SE-PostgreSQL-based system is the best common ground for
> such a system, but I am unconvinced that MAC by itself is necessary.

It's unclear for me the meanings of "MAC by itself".
Are you wondering the mandatory access control policy by SE-PostgreSQL, not
a Linux kernel?

If so, please consider the relationship between a client, an object manager
and method to access.
In operating system case, a client (process) invokes a system call to access
filesystem object which is managed by operating system. It is similar to that
a client send a SQL query to access database object which is managed by database
management system.
# Accesses to database objects are invisible for operating system, at all. :)

Thanks,
--
OSS Platform Development Division, NEC
KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)com>