Re: SE-PostgreSQL Specifications

Greg Williamson wrote:
> [wretched top-posting -- begs forgiveness!]
>
> KaiGai --
>
> I have edited the first three sections (up to but not including "Architecture"),
> mostly cleaning up language but I did run into a few places where I am not
> sure if I got the proper meaning -- I flagged those in square brackets
(e.g.[...])
> and with your name. Feel free to change them, accept them, or confer back with me
> about them.

Thanks for your efforts so much.
I'll confirm it tomorrow (in JST).

> In particular, in the Security policy section you had:
>
>> TE rules use the third field in the security context. It is called type or domain (for processes).
>> allow httpd_t sepgsql_ro_table_t : db_table {getattr select lock};
>
> I thought that colons were used to split these fields, so the above line would
> have only 2 ? Perhaps after the httpd_t ?

It says the third field in the security policy, not a rule in the security
policy. Sorry, it might be introduced more carefully.

In the default security policy, web server process performs labeled as
"system_u:system_r:httpd_t:s0".
^^^^^^^
This rule is checked when web server process tries to access a table labeled
as "system_u:object_r:sepgsql_ro_table_t:s0", for example.
^^^^^^^^^^^^^^^^^^
The TE rule is defined between the pair of third field (which is called type
or domain) of security contexts.

# BTW, basically, the second field is used for RBAC rules, the fourth field
# is used for MLS rules. The first field is used to record who create the
# object.

Thanks,

>
>
> I'd like to get some feedback from you (and any other readers) before I do more ... I need to go deal an invasion of the kitchen -- it is garbage collection morning (early) and I just had a pretty young skunk and two raccoon kits in rapid order and I have to clean up and secure the premises.
>
> Regards!
>
> G
>
>
>
> ----- Original Message ----
> From: Greg Williamson <gwilliamson39(at)yahoo(dot)com>
> To: KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)com>; 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: Tuesday, July 28, 2009 1:20:29 AM
> Subject: Re: [HACKERS] 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,
>
>

--
KaiGai Kohei <kaigai(at)kaigai(dot)gr(dot)jp>