From: | KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)com> |
---|---|
To: | KaiGai Kohei <kaigai(at)kaigai(dot)gr(dot)jp> |
Cc: | Sam Mason <sam(at)samason(dot)me(dot)uk>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: SE-PostgreSQL Specifications |
Date: | 2009-07-28 07:57:32 |
Message-ID: | 4A6EAF6C.9050304@ak.jp.nec.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
I revised the SE-PostgreSQL Specifications:
http://wiki.postgresql.org/wiki/SEPostgreSQL_Draft
- Put several external link to introduce something too detail
for PostgreSQL documentations.
- Paid attention not to use undefined terminology, such as
"security context", "security policy" and "mandatory access
controls".
- Revised whole of the composition in the "Brief overview" section.
- Put an example of security policy rule.
- "SECURITY_LABEL" option was replaced by "SECURITY_CONTEXT" to
avoid meaningless confusion.
I believe it become better than previous revision.
Thanks,
KaiGai Kohei wrote:
> Sam Mason wrote:
>> On Sun, Jul 26, 2009 at 12:27:12PM +0900, KaiGai Kohei wrote:
>>> Indeed, the draft used the term of "security context" with minimum
>>> introductions, but not enough friendliness for database folks.
>>>
>>> The purpose of security context is an identifier of any subject and
>>> object to describe them in the security policy. Because the security
>>> policy is common for operating system, databases, x-window and others,
>>> any managed database objects needs its security context.
>>>
>>> Anyway, I need to introduce them in the security model section.
>>
>> I'm coming to the conclusion that you really need to link to external
>> material here; there must be good (and canonical) definitions of these
>> things outside and because SE-PG isn't self contained I really think you
>> need to link to them.
>>
>> This will be somewhat of a break from normal PG documentation because
>> so far everything has been self contained, it's chosen its own
>> interpretation of the SQL standard and it needs to document that. SE-PG
>> will be interacting with much more code from outside and showing which
>> parts of these are PG specific vs. which parts are common to all SELinux
>> seems important.
>>
>> If you try to document *everything* you're going to be writing for years
>> and give the impression that everything is implemented in SE-PG. A
>> dividing line needs to be drawn between what is PG specific and what is
>> SELinux (why not SEL?).
>
> It also seems to me reasonable suggestion.
>
> However, a reasonable amount (which should be adjusted under discussions)
> of description should be self-contained.
> For example, "security context is a formatted short string" is not enough
> to understand why it is necessary and what is the purpose.
>
> As Robert suggested, a few example and definition of technical terms
> will help database folks to understand what it is, even if self-contained
> explanation is not comprehensive from viewpoint of security folks.
>
> Thanks,
--
OSS Platform Development Division, NEC
KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)com>
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2009-07-28 08:32:06 | Re: SE-PostgreSQL Specifications |
Previous Message | Fujii Masao | 2009-07-28 07:08:45 | Re: Review: support for multiplexing SIGUSR1 |