Re: SE-PostgreSQL Updated Revision (r1460)

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

Good catch, my mistake.

> - I found a typo: "MAC" is described as "MAc".

Also my mistake.

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

Oh, OK. It sounds a little awkward to me to refer to it as an API.
Perhaps we could just refer to it as getpeercon(3) and not call it
either an API or a system call.

> 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

OK, I wasn't aware of that. I think perhaps you could spell this out
a little more in the docs so people understand that there is an
upstream version which includes SE-PostgreSQL support from version
<whatever>.

>> 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:

Actually, I think this should probably be broken up into three
sections. All of the stuff about how PGACE is not very interesting to
anyone who isn't a developer, so it should be moved to someplace under
"Internals". I would suggest just adding a new chapter to the end of
that section, after "How the Planner Uses Statistics".

The database ACL stuff properly belongs in the "Database Roles and
Privileges" section, and needs to be moved there, not just a
cross-reference.

The discussion of enhanced security and SE-PostgreSQL is another new
chapter, probably immediately following "Database Roles and
Privileges". I would suggest calling it "Enhanced Security and
SE-PostgreSQL".

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

I agree. I think you should go through and rip out all of the
definitions and explanations of what these terms mean, and just use
them in the appropriate context. I think in general that the current
documentation spends far too much time explaining what SE-PostgreSQL
is and not enough time discussing the issues that are likely to come
up when you're actually using it. For example, it seems to me that
anyone who has any interest in using SE-PostgreSQL to control access
to functions will need a much more complicated policy than what you
are proposing here, and there doesn't seem to be much discussion of
that issue. I'm not really looking for specific examples of how to
build a policy so much as general considerations that you should keep
in mind when trying to prevent information leakage via functions.

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

Well, your English is certainly better than my Japanese...

...Robert