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

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 <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 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@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">RedHat
EnterpriseLinux 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>