Re: SE-PostgreSQL Updated Revision (r1460)

Robert Haas wrote:
>> 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.

I replaced all the "getpeercon()" by "getpeercon(3)", and removed
expression both "system call" and "API".

>> 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 noted it as:
| The upstreamed security policy (<literal>20080702</literal>
| or later) already has a set of rules for SE-PostgreSQL,
| as a part of PostgreSQL policy.

The "<whatever>" is not a tag, is it?

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

OK, I deployed these section as you suggested.
- The "Row-level Database ACLs" section is moved to the tail of
Chapter 20. Database Roles and Privileges.
- The new "Enhanced Security and SE-PostgreSQL" is moved to Chapter.21.
- The new "Chapter 57. PGACE Security Framework" is moved to Chapter.57,
next to the "56. How the Planner Uses Statistics".

> 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 added a new section "21.3. Making a Security Policy", but it is
still empty. I think it is not necessary to document comprehensive
information about security policy, since it is not a SELinux document.

My plan is to introduce a simple copy & pastable example and steps to
build it (with standard toolchain) and to install it as an security
policy module.

Please wait for filling up the section...

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