(forw) [bruce@momjian.us: [ANNOUNCE] Need help on possible PG 8.4 security features]

(forw) [bruce@momjian.us: [ANNOUNCE] Need help on possible PG 8.4 security features]

[Stephen Frost]

[-- Attachment #1: Type: text/plain, Size: 2627 bytes --]

Greetings,

  Hope the below hasn't already been sent here, if so, sorry, didn't
see it in the archives though.  This is very important for PostgreSQL
upstream addition of SE-Postgres.  I'm hopeful that there are some on
this list who can help the PostgreSQL core members be comfortable that
the patch does what is intended and properly implements the security it
claims.

The top of the current thread on -hackers can be found here:
http://archives.postgresql.org/pgsql-hackers/2009-01/msg01840.php
in particular:
http://archives.postgresql.org/pgsql-hackers/2009-01/msg01962.php
and others around that timeframe help frame this discussion.

In particular, we're looking for security experts who are familiar
with implementing SELinux (or similar..) in an RDBMS such as
PostgreSQL to review the patch, documentation, etc.

Please see below, and thanks.

	Stephen

----- Forwarded message from Bruce Momjian <bruce@momjian.us> -----

Date: Sat, 24 Jan 2009 10:36:22 -0500 (EST)
From: Bruce Momjian <bruce@momjian.us>
To: PostgreSQL-announce <pgsql-announce@postgresql.org>
X-Mailer: ELM [version 2.4ME+ PL124 (25)]
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham
	version=3.2.5
Subject: [ANNOUNCE] Need help on possible PG 8.4 security features

The PostgreSQL community is considering including security enhancements
in Postgres 8.4, e.g. row-level permissions and SE-Linux security. 
However, to evaluate the patch and its usefulness, we need security
experts who want to use this capability or have used it in other
databases.

The most recent version of the patch is mentioned here:

	http://archives.postgresql.org/pgsql-hackers/2009-01/msg01680.php

Particularly interesting is the documentation patch:

	http://sepgsql.googlecode.com/files/sepostgresql-docs-8.4devel-3-r1460.patch

If you know someone who is interested in these features or can help in
discussing them, please have them subscribe to pgsql-hackers here:

	http://www.postgresql.org/community/lists/subscribe

Email discussion about this topic will start on Wednesday, January 28,
at 12:00 GMT, and will include the subject text "SE-PostgreSQL".

-- 
  Bruce Momjian  <bruce@momjian.us>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +

---------------------------(end of broadcast)---------------------------
-To unsubscribe from this list, send an email to:

               pgsql-announce-unsubscribe@postgresql.org

----- End forwarded message -----

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: (forw) [bruce@momjian.us: [ANNOUNCE] Need help on possible PG 8.4 security features]

[KaiGai Kohei]

In the recent days, we have a hot discussion about what features
should be included within the next PostgreSQL release (v8.4) in
the pgsql-hackers list.
SE-PostgreSQL is a candidate of new features in the v8.4, but
it has been left for unreviewed yet.

| Bruce Momjian wrote:
| OK, time for me to chime in.
|
| I think the outstanding commit-fest items can be broken down into four
| sections:
|
| 	o  Log streaming
| 	o  Hot standby
| 	o  SE-PostgreSQL
| 	o  Others

 - snip -

| SE-PostgreSQL has been in steady development for a year so this is the
| time to decide about it.  My feeling is if we don't accept it now, we
| are never going to have SE-Linux or row-level security.  The next week
| should show us the right direction when we start discussion on
| Wednesday, noon GMT.

It seems to me some of pgsql-hackers concerned about security experts
don't join to its review process (except for me :), so it is unclear
whether the SE-PostgreSQL feature is really desired, or not, and
whether its security design is really appropriate, or not.

I would like to want some your helps.

Please see,
  http://www.postgresql.org/community/lists/subscribe
    -> "pgsql-hackers"
  http://archives.postgresql.org/pgsql-hackers/2009-01/threads.php
    -> "8.4 release planning" thread (sorry, it's a quite long thread).

Thanks,

Stephen Frost wrote:
> Greetings,
> 
>   Hope the below hasn't already been sent here, if so, sorry, didn't
> see it in the archives though.  This is very important for PostgreSQL
> upstream addition of SE-Postgres.  I'm hopeful that there are some on
> this list who can help the PostgreSQL core members be comfortable that
> the patch does what is intended and properly implements the security it
> claims.
> 
> The top of the current thread on -hackers can be found here:
> http://archives.postgresql.org/pgsql-hackers/2009-01/msg01840.php
> in particular:
> http://archives.postgresql.org/pgsql-hackers/2009-01/msg01962.php
> and others around that timeframe help frame this discussion.
> 
> In particular, we're looking for security experts who are familiar
> with implementing SELinux (or similar..) in an RDBMS such as
> PostgreSQL to review the patch, documentation, etc.
> 
> Please see below, and thanks.
> 
> 	Stephen
> 
> ----- Forwarded message from Bruce Momjian <bruce@momjian.us> -----
> 
> Date: Sat, 24 Jan 2009 10:36:22 -0500 (EST)
> From: Bruce Momjian <bruce@momjian.us>
> To: PostgreSQL-announce <pgsql-announce@postgresql.org>
> X-Mailer: ELM [version 2.4ME+ PL124 (25)]
> X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham
> 	version=3.2.5
> Subject: [ANNOUNCE] Need help on possible PG 8.4 security features
> 
> The PostgreSQL community is considering including security enhancements
> in Postgres 8.4, e.g. row-level permissions and SE-Linux security. 
> However, to evaluate the patch and its usefulness, we need security
> experts who want to use this capability or have used it in other
> databases.
> 
> The most recent version of the patch is mentioned here:
> 
> 	http://archives.postgresql.org/pgsql-hackers/2009-01/msg01680.php
> 
> Particularly interesting is the documentation patch:
> 
> 	http://sepgsql.googlecode.com/files/sepostgresql-docs-8.4devel-3-r1460.patch
> 
> If you know someone who is interested in these features or can help in
> discussing them, please have them subscribe to pgsql-hackers here:
> 
> 	http://www.postgresql.org/community/lists/subscribe
> 
> Email discussion about this topic will start on Wednesday, January 28,
> at 12:00 GMT, and will include the subject text "SE-PostgreSQL".
> 
-- 
OSS Platform Development Division, NEC
KaiGai Kohei <kaigai@ak.jp.nec.com>

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: (forw) [bruce@momjian.us: [ANNOUNCE] Need help on possible PG 8.4 security features]

[James Morris]

On Tue, 27 Jan 2009, KaiGai Kohei wrote:

> It seems to me some of pgsql-hackers concerned about security experts
> don't join to its review process (except for me :), so it is unclear
> whether the SE-PostgreSQL feature is really desired, or not, and
> whether its security design is really appropriate, or not.

It's a pity you couldn't make it to LCA, as I had a question which I 
suspect only you could answer.

One thing I noticed was the use of MCS for labels relating to external 
subjects, and the type field being used apparently for internal purposes.

Is this correct?

(From memory, the type field of some rows were along the lines of
fixed_table_t, presumably for internal db use).

Can the entire security context be specified and utilized for the data 
itself ?  e.g. Can data be inserted into the db with the label 
"system_u:object_r:shadow_t", corresponding exactly to the filesystem 
label of the file it came from?

-- 
James Morris
<jmorris@namei.org>

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: (forw) [bruce@momjian.us: [ANNOUNCE] Need help on possible PG 8.4 security features]

[KaiGai Kohei]

James Morris wrote:
> On Tue, 27 Jan 2009, KaiGai Kohei wrote:
> 
>> It seems to me some of pgsql-hackers concerned about security experts
>> don't join to its review process (except for me :), so it is unclear
>> whether the SE-PostgreSQL feature is really desired, or not, and
>> whether its security design is really appropriate, or not.
> 
> It's a pity you couldn't make it to LCA, as I had a question which I 
> suspect only you could answer.
> 
> One thing I noticed was the use of MCS for labels relating to external 
> subjects, and the type field being used apparently for internal purposes.
> 
> Is this correct?
> 
> (From memory, the type field of some rows were along the lines of
> fixed_table_t, presumably for internal db use).

There are no specific discrimination like internal/external.
SE-PostgreSQL simply assigns a default security context based
on type_transition rules, or inherits upper class obejct.

At the LCA example, I assigned sepgsql_fixed_table_t on the
"drink" table, so newly inserted tuples also inherit it.

> Can the entire security context be specified and utilized for the data 
> itself ?  e.g. Can data be inserted into the db with the label 
> "system_u:object_r:shadow_t", corresponding exactly to the filesystem 
> label of the file it came from?

Please consider the following case.
  1. App-X read /etc/shadhow (system_u:object_r:shadow_t)
  2. App-X create a file /tmp/aaa
  3. App-X write a buffered data into /tmp/aaa
In this case, /tmp/aaa will be labeled as "tmp_t".

  1'. App-X read /etc/shadhow (system_u:object_r:shadow_t)
  2'. App-X insert a row with buffered data.
In this case, I don't think it should be labeled as "shadow_t".
The newly inserted row is labeled based on TYPE_TRANSITION, or
inherits its table's context.
(Maybe, "sepgsql_table_t" in default)

Thanks,
-- 
KaiGai Kohei <kaigai@kaigai.gr.jp>

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: (forw) [bruce@momjian.us: [ANNOUNCE] Need help on possible PG 8.4 security features]

[James Morris]

On Tue, 27 Jan 2009, KaiGai Kohei wrote:

> At the LCA example, I assigned sepgsql_fixed_table_t on the
> "drink" table, so newly inserted tuples also inherit it.

Can this type be anything defined by the admin?

Why is MCS being used in the example?  Would anything stop the examples 
using types such as "marketing_department_t" and "research_department_t", 
with no MCS ?


- James
-- 
James Morris
<jmorris@namei.org>

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: (forw) [bruce@momjian.us: [ANNOUNCE] Need help on possible PG 8.4 security features]

[KaiGai Kohei]

James Morris wrote:
> On Tue, 27 Jan 2009, KaiGai Kohei wrote:
> 
>> At the LCA example, I assigned sepgsql_fixed_table_t on the
>> "drink" table, so newly inserted tuples also inherit it.
> 
> Can this type be anything defined by the admin?

YES, as follows:

CREATE TABLE drink (
   id   integer primary key,
   name text security_label = 'system_u:object_r:example_foo_t',
   price integer
) security_label = 'system_u:object_r:example_var_t';

It enables to create a table/columns with specified context.

and,

INSERT INTO drink (security_label, id, name, price)
   VALUES ('system_u:object_r:example_baz_t', 1, 'coffee', 120);

It enables to insert a tuple with specified context.

(*) security_label is a system column, so it automatically
     generated for all tables, and not expanded by "SELECT *".

> Why is MCS being used in the example?  Would anything stop the examples 
> using types such as "marketing_department_t" and "research_department_t", 
> with no MCS ?

It is possible, if we make an example policy module.

Thanks,
-- 
KaiGai Kohei <kaigai@kaigai.gr.jp>

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.