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
themselvesto 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 <kaigai@ak.jp.nec.com>
