Re: SE-PostgreSQL Updated Revision (r1460)

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>