Re: SE-PostgreSQL Specifications

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 ?

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).

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(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
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(at)ak(dot)jp(dot)nec(dot)com>