Andrew Sullivan wrote:
On Fri, Oct 10, 2008 at 01:44:49PM +0900, KaiGai Kohei wrote:
Andrew Sullivan wrote:
I want to focus on this description, because you appear to be limiting
the problem scope tremendously here. We've moved from "general
security policy for database system" to "security policy for database
system as part of a web-application stack".
The "general security policy for database system" is an incorrect term.
SELinux does not cover database system only. It covers operating sytem
and application managing objects (like database object, X window, ...).
Thus, it should be talked as "general security policy for operating
system, database system and so on".
Ok, then let's use the broader case, which is "general security policy
for entire computing system including a RDBM subsystem" (call this
"GSPECS+DB", say). This shows up even more the issue that considering
primarily the application stack does not actually cover all the cases.
I'm not suggesting, even a little bit, that securing an application
stack as you propose is a waste of time. It could be, actually, that
this more modest goal is the more appropriate one, and that
SE-PostgreSQL would be a killer feature in this space (because it
would, if it worked, solve a lot of problems that other systems have,
as you have pointed out). But it is not GSPECS+DB, because of all the
corner case problems whose behaviour still needs working out.
Indeed, SE-PostgreSQL is an important piece of "GSPECS+DB" but it cannot
catch the ultimate goal by itself only.
Do you know other efforts to apply SELinux security policy for objects
managed in userspace? One prior example is X-window system. Its resources
are managed by X server so in-kernel SELinux cannot trap accesses to the
objects. Some of them (like cut&paste buffer, key input events) can be
shared several processes, so it should be controled by the policy.
We can call it like "GSPECS+X".
As widely known, security is an endless work. The ultimate goal might
not be as near as we can grab, but it does not mean it is not necessary
to fill up pieces to help it.
> But plainly, others who need to look after the code will want to know
> what the exact goal is before committing themselves to future maintenance.
It is same things as I repeated several times.
Its goal is to apply centralized manageable security policy (SELinux) on
database objects, as if SELinux doing on filesystem objects.
This feature can help web-application security, for example.
Thanks,
--
OSS Platform Development Division, NEC
KaiGai Kohei <[EMAIL PROTECTED]>
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
