Re: SE-PostgreSQL Specifications - Mailing list pgsql-hackers

Greg Williamson wrote:
> Thanks for the updates.
> 
> I might suggest a couple of small changes:
> 
> a) a section that explains comments like "This is not supported in the initial version" -- do you
> mean in the first Beta release of SE-PostgreSQL, or not in the initial release(s) for commitfests ?
> If it is not supported why mention it ? If experienced users of SELinux expect it, they might look for
> an explanation as to why it is missing and when it might appear. I'm not sure if postgres DB
> hackers would care if is it is not to be included. How much do these compromise the design,
> and if so, are there specific plans for implementing them ?

The "This is not supported ..." comment means this feature is not included within
the initial patch submitted to the next commit fest, so the corresponding section
is not also included within the documentation patch at that time.
However, I expect all the features and corresponding user documents should be
included within the stable v8.5 release. So, I also described these sections
with notations.

> b) something which explains the differences between SELinux and SEPostgreSQL on the one
> hand (for SE fans). You've done a good job of outlining the differences and similarities with the
> more standard ACL methods and that needs to be kept prominent so people with DB experience
> can see the differences.
> 
> I am all in favor of external links if you can find good explanation of concepts elsewhere. This is a
> very high level outline and so I'd be tempted to move all implementation details to another page --
> basically everything from ""Installation" on, with the exception of the overview of the dump issues,
> is (to my eye) a detail that doesn't need exposing (yet).

At first, what should be included within the PostgreSQL official documentation?

I don't think here is any opposition to include- Steps to installations- Enhancement in SQL statement- External links
somethinglike:  "It provides mandatory access controls. See the http://..... for details."
 

Needs to be discussed- Securtiy model overview, such as security context, security policy and so on.- Feature overview,
suchas example of access controls.- References to object classes and permissions. (Basically, it is not necessary for
endusers.)
 

If we prepare a comprehensive external documentation, one idea is to revise
the series of wikipages at:
 http://wiki.postgresql.org/wiki/SEPostgreSQL

Thanks,

> I'll send mail when I have a few paragraphs done so you can check it and see if you approve.
> 
> Apologies for top-posting -- lame mailer.
> 
> Greg W.
> 
> 
> 
> 
> ----- Original Message ----
> From: KaiGai Kohei <kaigai@ak.jp.nec.com>
> To: KaiGai Kohei <kaigai@kaigai.gr.jp>
> Cc: Sam Mason <sam@samason.me.uk>; pgsql-hackers@postgresql.org
> Sent: Monday, July 27, 2009 11:57:32 PM
> Subject: Re: [HACKERS] SE-PostgreSQL Specifications
> 
> 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@ak.jp.nec.com>