Re: SE-PostgreSQL Updated Revision (r1460)

Sorry, I attached incorrect patch file.
It is the correct one.

KaiGai Kohei wrote:
> Robert,
>
> The attached patch is a draft to replace RedHat/Fedora RPM centric
> expressions, to add a reference at "Database Roles and Privileges"
> chapter and a bit cleanups for the latest revision (r1467).
> In the previous revision, it noted users to check the version of
> RPM package, but the revised one notes actually required features.
> The version number is rewritten as a hint.
>
> What is your opinion?
>
> Thanks,
>
> KaiGai Kohei wrote:
>> Robert Haas wrote:
>>> On Fri, Jan 23, 2009 at 12:30 AM, KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)com>
>>> wrote:
>>>> The patch set of SE-PostgreSQL and related stuff were updated (r1460).
>>>>
>>>> [1/5]
>>>> http://sepgsql.googlecode.com/files/sepostgresql-sepgsql-8.4devel-3-r1460.patch
>>>>
>>>> [2/5]
>>>> http://sepgsql.googlecode.com/files/sepostgresql-utils-8.4devel-3-r1460.patch
>>>>
>>>> [3/5]
>>>> http://sepgsql.googlecode.com/files/sepostgresql-policy-8.4devel-3-r1460.patch
>>>>
>>>> [4/5]
>>>> http://sepgsql.googlecode.com/files/sepostgresql-docs-8.4devel-3-r1460.patch
>>>>
>>>> [5/5]
>>>> http://sepgsql.googlecode.com/files/sepostgresql-tests-8.4devel-3-r1460.patch
>>>>
>>>
>>> KaiGai -
>>>
>>> I read through your docs patch tonight and did some copy editing.
>>> Please see the attached patches, which I hope you will find helpful.
>>> I have attached my suggested changes both as a patch against v1460
>>> (sepostgresql-docs-rmh-vs-1460.gz) and also as patch against CVS HEAD
>>> (sepostgresql-docs-rmh-vs-cvs-head), since I am not sure which is
>>> easier for you. I have a couple of general comments about the
>>> documentation:
>>
>> Thanks your feedbacks!
>>
>> I basically applied your fixes as is, expect for the following items:
>> - You replaced
>> ! Its providing access controls are not _bypassable_ for any clients
>> ...
>> by
>> ! The access controls implemented by SE-PostgrSQL may not be
>> _biased_ even ...
>>
>> I wanted to express it is "unavoidable" here, so I changed as:
>> ! The access controls implemented by SE-PostgrSQL may not be
>> _bypassed_ even ...
>>
>> - I found a typo: "MAC" is described as "MAc".
>>
>> And, I have a question about documentation manner.
>> - You represented "getpeercon()" function as a system call.
>> But, it is actually a wrapper function of getsockopt(2) system call,
>> so the "getpeercon(3)" is not a system call strictly.
>> Is it necessary to represent these stuffs strictly correct?
>> (Thus, I wrote it as "API" in the r1460.)
>>
>>
>>> 1. The docs as written are very Red Hat-centric, even to the point of
>>> making reference to specific versions of Red Hat RPMs. I think that
>>> the community will find this unacceptable, as Red Hat is certainly not
>>> the only SELinux-enabled distribution and I presume that we want to
>>> support all of them to an equal degree.
>>
>> I guess you pointed out about:
>> 1. The "Requirement" section in "Build and Installation" assumes
>> RedHat/Fedora's RPM package and its version number.
>> 2. The security context and security policy used to explanation
>> assumes specific security policy.
>> 3. "Labeled IPsec" seciton points to "RedHatEL4 Security Guide",
>> and it assumes the racoon's configuration files are deployed
>> as RPM package doing.
>>
>> About 1, is it necessary to rip the RPM specific version number
>> and replace it as:
>> selinux-policy which includes SE-PostgreSQL related stuffs.
>>
>> About 2, SELinux community provides its default security policy,
>> and distributor's policy (including RedHat's one) is a derivative
>> of the default policy.
>> It is developed independent from distributor's cycle.
>> http://oss.tresys.com/projects/refpolicy
>>
>> http://oss.tresys.com/repos/refpolicy/trunk/policy/modules/services/postgresql.te
>>
>>
>> You can find some of sepgsql_xxxx identifiers in postgresql.te.
>> All the appeared identifiers are upstreamed, so these are not Red Hat
>> specific.
>>
>> About 3, If it rips the link to Red Hat and does not assume specific
>> path of "racoon.conf", the explnation become neutral.
>>
>>
>>> 2. Some of the information that is documented here properly belongs in
>>> other sections of the documentation. For example, the information
>>> about GUCs clearly belongs somewhere in the section on server
>>> configuration where all of the other GUCs are documented, not in a
>>> separate sections about SE-PostgreSQL.
>>
>> These explanations are moved to "Security and Authentication" section
>> in "Chapter 18. Server Configuration".
>>
>>> I suspect that all of the
>>> information about row-level ACLs should be ripped out of security.sgml
>>> and inserted into an appropriate portion of the "Database Roles and
>>> Privileges" chapter, leaving this file to talk just about
>>> SE-PostgreSQL.
>>
>> It is indeed an aspect of row-level ACLs.
>> However, it is also a feature on PGACE framework, same as SE-PostgreSQL.
>> An idea is to put a reference to indicate the row-level ACLs section
>> on "Database Roles and Privileges" chapter, like:
>>
>> PostgreSQL has an enhancement of database roles and privileges
>> mechanism
>> which allows to database ACLs in row-level granuality. See, <xref ...>
>> for more details.
>>
>> What do you think?
>>
>>> 3. It seems to me that the analogy between SQL DAC and Unix user/group
>>> DAC is mentioned far too many times, and there are other cases where
>>> information is repeated as well. I think it might help to reorganize
>>> the document a bit so that you introduce concepts in the right order.
>>
>> Indeed, it was redundant explanation. Thanks for youe edit.
>>
>>> For example, the section that defines MAC and DAC is a ways down in
>>> the document, but you use those terms a whole bunch of times before
>>> defining them. I'm not 100% sure that we even want to be defining MAC
>>> and DAC in our documentation, since those are general industry terms
>>> that are not PostgreSQL-specific. But if we are going to define them
>>> then we should try to do so in the clearest way possible.
>>
>> I can add the definitions of terms.
>> However, it is unclear whether PostgreSQL documentation should include
>> them, or not. For example, wikipedia has enough explanation for their
>> generam meanings.
>> http://en.wikipedia.org/wiki/Discretionary_Access_Control
>> http://en.wikipedia.org/wiki/Mandatory_Access_Control
>>
>> It seems to me "Discretionary Access Control (DAC)" is an enough key
>> to search its meaning.
>>
>>> Overall, I would say there is a fair amount of work left to be done to
>>> get this documentation up to par, but it's a good start and I hope
>>> that the attached patches and suggestions will be helpful.
>>
>> I'm glad to see your help.
>> I'll pay my efforts for documentations also. But English is not my mother
>> language, so any suggestions are helpful for me.
>>
>> Thanks,
>
>

--
OSS Platform Development Division, NEC
KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)com>