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 <kai...@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 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 <kai...@ak.jp.nec.com>
Index: sepgsql/doc/src/sgml/security.sgml
===================================================================
*** sepgsql/doc/src/sgml/security.sgml (revision 1467)
--- sepgsql/doc/src/sgml/security.sgml (working copy)
***************
*** 684,692 ****
From this, the client can infer the existence of the invisible foreign
key, an inference to which he is not entitled.
! As a practical matter, this scenario can sometimes be avoided by using
! non-natural primary and foreign keys, such as UUIDs. This may make it
! impossible to infer any meaningful data.
</para>
</sect2>
</sect1>
--- 684,692 ----
From this, the client can infer the existence of the invisible foreign
key, an inference to which he is not entitled.
! As a practical matter, this scenario can sometimes be avoided by using
! non-natural primary and foreign keys, such as UUIDs. This may make it
! impossible to infer any meaningful data.
</para>
</sect2>
</sect1>
***************
*** 702,729 ****
We need the following packages to build and install
SE-PostgreSQL properly. Please check it at first.
</para>
! <itemizedlist>
! <listitem>
! <para>
! Linux kernel (2.6.23, or later)
! </para>
! </listitem>
! <listitem>
! <para>
! libselinux and libselinux-devel (2.0.43, or later)
! </para>
! </listitem>
! <listitem>
! <para>
! selinux-policy (3.4.2, or later)
! </para>
! </listitem>
! <listitem>
! <para>
! policycoreutils (2.0.16, or later)
! </para>
! </listitem>
! </itemizedlist>
</sect3>
<sect3>
--- 702,796 ----
We need the following packages to build and install
SE-PostgreSQL properly. Please check it at first.
</para>
!
! <variablelist>
! <varlistentry>
! <term><literal>Linux kernel</literal></term>
! <listitem>
! <para>
! Linux kernel has to support SELinux feature, at least.
! In addition, it is necessary to provide an interface to
! obtain a list of supported object classes and permissions
! via <filename>/selinux/class</filename>, which is available
! on the Linux kernel 2.6.23 or later.
! </para>
! </listitem>
! </varlistentry>
!
! <varlistentry>
! <term><literal>Security policy</literal></term>
! <listitem>
! <para>
! The security policy of SELinux is neccesary to contain access
! control rules related to database objects.
! The recent upstreamed security policy already has a set of
! rules for SE-PostgreSQL, as a part of policy for PostgreSQL.
! </para>
! <para>
! In <literal>Red Hat EL</literal> or <literal>Fedora</literal>,
! check the version number of <literal>selinux-policy</literal>
! rpm package is <literal>3.4.2</literal>, or later.
! </para>
! </listitem>
! </varlistentry>
!
! <varlistentry>
! <term><literal>libselinux</literal></term>
! <listitem>
! <para>
! <literal>libselinux</literal> is a library to communicate
! between applications and in-kernel SELinux, so it provides
! us various kind of APIs and header definitions.
! It is necessary to provide header definitions of object
! classes and permissions related to database. Rest of
! requirements are already included in older version.
! </para>
! <para>
! In <literal>Red Hat EL</literal> or <literal>Fedora</literal>,
! check the version number of <literal>libselinux</literal>
! and <literal>libselinux-devel</literal> rpm packages are
! <literal>2.0.46</literal>, or later.
! </para>
! </listitem>
! </varlistentry>
!
! <varlistentry>
! <term><command>checkmodule</command></term>
! <listitem>
! <para>
! The <command>checkmodule</command> is a policy compiler for
! a modular policy package, such as
! <literal>sepostgresql-devel.pp</literal> we provided.
! </para>
! </listitem>
! </varlistentry>
!
! <varlistentry>
! <term><command>semodule</command></term>
! <listitem>
! <para>
! The <command>semodule</command> is a command to manage
! modular policy packages. It enables to link/unlink,
! upgrade or load/unload modular policy packages, such as
! <literal>sepostgresql-devel.pp</literal> we provided.
! </para>
! </listitem>
! </varlistentry>
!
! <varlistentry>
! <term><command>restorecon</command></term>
! <listitem>
! <para>
! The <command>restorecon</command> enables to assign
! correct security context for files, directories and
! any other objects on filesystem, based on the security
! policy configuration.
! It helps to assign correct security context on
! installed files by hand.
! </para>
! </listitem>
! </varlistentry>
! </variablelist>
</sect3>
<sect3>
***************
*** 740,749 ****
<prompt>$ </prompt><userinput>make -C src/backend/security/sepgsql/policy</userinput>
</screen>
<para>
! The current default security policy of SELinux contains a set of
! rules for SE-PostgreSQL on <literal>selinux-policy-3.4.2</literal>
! or later. So, we don't need to install special purpose security
! policy module now.
</para>
<para>
However, SE-PostgreSQL also provides an optinal policy module
--- 807,815 ----
<prompt>$ </prompt><userinput>make -C src/backend/security/sepgsql/policy</userinput>
</screen>
<para>
! Please note that the recent upstreamed security policy of SELinux
! contains a set of rules for SE-PostgreSQL, so we are not always
! necessary to build security policy module.
</para>
<para>
However, SE-PostgreSQL also provides an optinal policy module
***************
*** 914,922 ****
</para>
<para>
! This section introduces the steps to set up labeled ipsec.
!
! For more detailed information, visit <ulink url="http://www.redhat.com/docs/manuals/enterprise/RHEL-4-Manual/en-US/Security_Guide/s1-vpn-ipsec.html";>Red Hat Enterprise Linux 4 - Security Guide</ulink>
</para>
<sect4>
--- 980,989 ----
</para>
<para>
! This section introduces the steps to set up labeled ipsec,
! but it is necessity minimum configuration, so we recommend
! you to refer external technical documents related to ipsec
! for more details.
</para>
<sect4>
Index: sepgsql/doc/src/sgml/user-manag.sgml
===================================================================
*** sepgsql/doc/src/sgml/user-manag.sgml (revision 1467)
--- sepgsql/doc/src/sgml/user-manag.sgml (working copy)
***************
*** 29,34 ****
--- 29,40 ----
<xref linkend="ddl">.
</para>
+ <para>
+ PostgreSQL has an enhancement of database roles and privileges mechanism
+ which allows to set database ACLs in row-level granuality.
+ See, <xref linkend="security-row-level-acl"> for more details.
+ </para>
+
<sect1 id="database-roles">
<title>Database Roles</title>
Index: sepgsql/doc/src/sgml/config.sgml
===================================================================
*** sepgsql/doc/src/sgml/config.sgml (revision 1467)
--- sepgsql/doc/src/sgml/config.sgml (working copy)
***************
*** 750,756 ****
specified mode, independent from kernel setting. Please note
that those configuration requires in-kernel SELinux is not
disabled. The <literal>disabled</literal> disables SE-PostgreSQL.
! This parameter can only be set at server start.
</para>
</listitem>
</varlistentry>
--- 750,758 ----
specified mode, independent from kernel setting. Please note
that those configuration requires in-kernel SELinux is not
disabled. The <literal>disabled</literal> disables SE-PostgreSQL.
! This parameter is available on a binary with SELinux support
! (<literal>--enable-selinux</literal>), and can only be set at
! server start.
</para>
</listitem>
</varlistentry>
***************
*** 770,776 ****
for saving storage consumption.
The default is <literal>on</literal> which means row-level access
controls are available.
! This parameter can only be set at server start.
</para>
</listitem>
</varlistentry>
--- 772,780 ----
for saving storage consumption.
The default is <literal>on</literal> which means row-level access
controls are available.
! This parameter is available on a binary with SELinux support
! (<literal>--enable-selinux</literal>), and can only be set at
! server start.
</para>
</listitem>
</varlistentry>
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
