Re: Adding support for SE-Linux security - Mailing list pgsql-hackers

Ron Mayer wrote:
> KaiGai Kohei wrote:
>> Needless to say, NEC is also a supporter to develop and maintain
>> SE-PgSQL feature. We believe it is a necessity feature to construct
>> secure platform for SaaS/Cloud computing, so my corporation has funded
>> to develop SE-PgSQL for more than two years.
> 
> Rather than "needless to say", I think this is worth elaborating on.
> 
> Knowing how companies like NEC and their customers see SELinux and
> SE-PgSQL help their database projects would probably be one of the
> most compelling stories for getting broader support for the feature.
> 
> Before googling "nec software" after seeing you mention
> this, I knew very little about NEC's software business.
> I can read some about NEC's software/database business for
> NEC North America's[1] and NEC Global Services[2] but imagine
> globally there's even more to it than that.

I'm talking about our future business, not existing one.

Anyway, what is important here is that out corporation makes a decision
to contribute to develop and maintain an innovative OSS project rather
than what our business works well.


> Understanding how SE-PgSQL (and presumably SE-Linux) helps
> build a better SaaS/Cloud computing platform would probably
> help many people support this feature more.   The cloud computing
> platforms I see more are ones that isolate a user's data either
> at a higher application layer (like salesforce) or a lower
> virtual machine layer (like amazon's elastic cloud).  Is a
> vision of SE-PgSQL to help cloud computing companies sell
> customers access to a single underlying postgres instance,
> and share selected data between each other at a row level?
> Just curious.

Basically, note than we have no magic-bullets in security region.
Any approach has its merits and demerits. It depends on users what
should be emphasized.

If we tries to separate user's information assets in the application
level (like salesforce), the code to be checked and bug-free are much
larger than a case when we enforce accesses in OS/RDBMS.
It shall make development cost to increase.

If we tries to separate user's information assets in the virtual machine
layer (like amazon), the worker-hour to maintain each virtual machines
larger than a case when we enforce accesses in OS/RDBMS layer.
It shall make maintenance cost to increase.

If we tries to separate user's information assets in the OS/RDBMS layer,
the code to be checked and bug-free are less than application level
checks, and all administrator need to do is manage a limited number of
instances.

The granularity of access controls is not a primary matter.
We can separate user's information assets in table level, not only row
level. In addition, we cat set up a part of shared tables, unlike virtual
machine approach.

I don't mean this approach it a magic-bullets, but it can be an option
for security-conscious users.

Thanks,
-- 
OSS Platform Development Division, NEC
KaiGai Kohei <kaigai@ak.jp.nec.com>