Re: SE-PostgreSQL Updated Revision (r1460) - Mailing list pgsql-hackers

Robert Haas wrote:
> On Fri, Jan 23, 2009 at 12:30 AM, KaiGai Kohei <kaigai@ak.jp.nec.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
implementedby 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
notbe _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)
systemcall,  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
packageand its version number. 2. The security context and security policy used to explanation    assumes specific
securitypolicy. 3. "Labeled IPsec" seciton points to "RedHatEL4 Security Guide",    and it assumes the racoon's
configurationfiles 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,
-- 
KaiGai Kohei <kaigai@kaigai.gr.jp>