Re: Updates of SE-PostgreSQL 8.4devel patches - Mailing list pgsql-hackers

Tom Lane wrote:
> Andrew Sullivan <ajs@commandprompt.com> writes:
>> The above point, and other similar ones in every discussion of the
>> proposed functionality, makes me think once again either that the
>> requirements for this feature aren't understood by everyone, or else
>> that they're not actually explicit enough.  I have a feeling it's the
>> latter.
> 
> Yeah, I think that's exactly the problem here: we've got this large
> patch and no agreement on just what requirements it's supposed to meet.
> Perhaps others see it differently, but I feel like I'm being told that
> whatever the patch does is the right thing by definition ... and yet
> it doesn't seem to meet what I would think are the likely requirements
> of the users who might actually want such features.

Indeed, I might not say my motivation and the goal/target of SE-PostgreSQL
in explicit.

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.
I know there are various aspect of opinions for SELinux, but it has
succeeded to run server applications with the least privileges and
enabled to prevent attachs from malicious ones.
However, web application had some of characteristics different from
server application.

The LAPP software stack is very popular architecture to provide web
services, and widely accepted. I had a concern from the viewpoint of
security folks. The LAPP stack is constructed from four components,
and each of them provides individual security mechanism.
For example, OS(Linux) provides filesystem permission and SELinux,
RDBMS(PostgreSQL) provides database ACL, and so on.
In addition, most of web application stores its data into databases
not only filesystems. This fact prevented to work web application
with least privilege set, because in-kernel SELinux cannot trap
accesses on database objects. In this situation, we have to set up
database acl, and choose a proper database role.
But there is no explicit relationship between database roles and
the least privilege set (called as security context), so web
application can/must select arbitrary one.

In my vision, Apache assigns its contents handler an individual
security context based on HTTP authentication, source IP address
and so on just before web application invoked.
Because web applications works with individual least privilege set,
its accesses on filesystem are restricted by the security policy.
In a similar way, its accesses on databases are also restricted
via SE-PostgreSQL by same policy, by same privilege set.
(Please note that SE-PostgreSQL obtain the security context ofpeer process using getpeercon() API provided by
SELinux.)
This architecture enables to minimize security sensitive code,
like openning database connection.
If we adopt this approach, web application can also select
a database role, but the outline of its privileges are defined
by security policy.

In recent years, web application flaws are nightmare for us.
The recent report said 95% of significant incidents on the first
half of 2008, and 75% of them were SQL injection in Japan.
My ultimate goal is to help the situation with mandatory access
control and least priviled set for whole of LAPP stack.

The fine-grained access controls are provided for practical advantage.
One requirement I got is to apply SE-PostgreSQL as a backend of medical
information system which is shared by several small hospitals.
An electronic chart has common format, so it is simple design to store
it within a single table. And, individual tuples have individual access
right which is only exposed to his doctor and medical staffs.

The actual origin of fine-grained access control is sense of rivalry
towards the prior commercial security aware RDBMS (like Oracle Label
Security, IBM DB2), however, it is neccesary to utilize access controls.
If we don't have fine-grained controls, any web application have to have
privileges to access all charts of patients, and vulnerable for SQL
injection. It is a real practical advantage, I think.

Sorry for long my description.

Thanks,

> Agreeing on the requirements seems like a necessary condition for
> arriving at any consensus on a patch.  Where can we get some evidence
> that would convince everyone that the requirements for a highly
> secure database are X, Y and Z?
> 
>             regards, tom lane
> 


-- 
KaiGai Kohei <kaigai@kaigai.gr.jp>