Re: SE-PgSQL patch review

Tom Lane wrote:
> Even if we were to accept the SEPostgres patches lock stock and barrel
> tomorrow, I don't foresee that it will ever get to the point of being
> useful except to an extremely small group of users who are driven by
> extreme need. Nobody else is going to have the motivation needed to
> develop custom security policies, and there simply isn't any chance
> of anyone developing any generally useful default policy. Red Hat's
> policy has been trying to cope with cases like "which directories should
> Apache be allowed to read, *given that it's running a Red-Hat-standard
> configuration*?" That's far more circumscribed than any useful database
> policy would be, because database applications aren't nearly that
> standardized.

Basically, it is the last option to write custom policy modules for users,
and it is not a recommendable for average users.
The default security policy contains various kind of pre-defined security
contexts, and it allows administrators to assign them dirs/files according
to their purpose. In most cases, user can complete SELinux setups with
customizations nowadays, not writing their custom policy modules.

For example, the default security policy intend to web contents are stored
in "/var/www/html" labeled as "httpd_sys_content_t" which allows web-servers
read-only access to the files. If we want to store web contents in
"/opt/html", all we have to do is:

$ chcon -R system_u:object_r:httpd_sys_content_t:s0 /opt/html

It changes the security context of the /opt/html and files under the
directory. It performs as web-contents from perspective of SELinux.

We can apply similar configuration on database objects.
For example, we want to have a read-only table from confined processes,
all we have to do is:

CREATE TABLE read_only_tbl (
x int,
y text
) SECURITY CONTEXT ('system_u:object_r:sepgsql_ro_table_t:s0');

The "sepgsql_ro_table_t" is a type which allows confined processes only
SELECT contents from the table, and it is provided by the default security
policy. We don't need to write any custom security policy in typical use
cases.

SELinux has been integrated into RedHat/Fedora since FC2.
It had a lot of matters in the early phase. For example, the default security
policy was troubled, user needed to modify the security policy and rebuild
whole of the policy, here were no custmization parameters, ...
However, these matters have been resolved for the recent years.

It seems to me your complaints based on the legacy SELinux.

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