All of lore.kernel.org
 help / color / mirror / Atom feed
From: KaiGai Kohei <kaigai@ak.jp.nec.com>
To: selinux <selinux@tycho.nsa.gov>
Cc: refpolicy@oss.tresys.com
Subject: The status of SE-PostgreSQL
Date: Mon, 23 Mar 2009 19:37:46 +0900	[thread overview]
Message-ID: <49C7667A.3020804@ak.jp.nec.com> (raw)

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

Here is a bad news.

I've had a discussion in pgsql-hackers list for a long time, but
we cannot get a conclusion that SE-PostgreSQL should be merged
in the PostgreSQL v8.4 which is the next major release, and it
was postponed to the v8.5 development cycle due to lack of time
for enough reviewing the feature.

If it can be released on schedule, the v8.4 is released on the
second quarter of 2009, and the v8.5 will be relased on a year
later (but it tend to delay a few months).
So, it is necessary to apply SE-PostgreSQL patches or install
it from RPM package distributed via Fedora project. :(

Under the discussion, I got a few suggestions in its security
design, and it seems to me fair enough. Some of them needs to
change definitions in the default policy.

See the following items,

* new permission: db_database:{superuser}

They required a new permission to control database superuser
privileges similar to "root" capability in operating system.
The concept of superuser is common for some of major DBMSs,
not only PostgreSQL. In addition, it seems to me well symmetric
with operating system.

The db_database:{superuser} controls whether the client can
perform as database superuser on the given database, or not.

* undesired permission: db_database:{set_param get_param}

They wondered the necessity of these checks, because SQL spec
does not require checks in set/get database parameters.
I didn't think it is necessary the security design of SELinux
should be symmetric with SQL, but I also thought these might
be unnecessary due to another reason.
In PostgreSQL, the scope of database parameters are session
local and initialized on the connection startup, so we cannot
use it as a pass to communicate between different two or more
domains.

* undesired permission: db_table/db_column/db_tuple:{use}

I originally proposed the {use} permission to set up write-only
tables, but it might be a misdesign.
(Sorry, a bit long description.)

At the initial design, SE-PostgreSQL applied {select} permission
for all the refered tables, columns and tuples. But, it also means
{select} permission is necessary for conditional DELETE or UPDATE
even if its content is not exposed to the client.
So, I proposed the privilege into two different permission: {select}
and {use}. The {select} allows the client to refer the object and
its content can be returned to him. The {use} also allows the client
to refer the object but its content has to be consumed internally.

  Example)
    SELECT a, b FROM t WHERE c = 5;
  In this case, we need {select} on column t.a and t.b, but {use}
  is required on column t.c because its content is consumed by
  SE-PostgreSQL itself and not returned to the client.

  Example)
    UPDATE t SET x = 20 WHERE y = 'aaa';
  In this case, we need {update} on column t.x, and {use} on t.y,
  but {select} is not necessary.

However, we can break it rapidly with a clever condition clause.
For example, we can get a result from the first trial:
  DELETE FROM account WHERE userid = 100 and creditno like '1%';

If this query removes a tuple, it means the first character of
credit card number is '1'. If not so, he can try it 9 times.
Then, he can get the information without {select} permission,
with enough small number of trials.

They concluded the "{use}" permission cannot work correctly, and
danger to expect it does not allow to leak contexnt to the outside.
I can agree this opinion.


The attached patch add/remove these permissions.
Any comments please.

Thanks,
-- 
OSS Platform Development Division, NEC
KaiGai Kohei <kaigai@ak.jp.nec.com>

[-- Attachment #2: refpolicy-sepgsql-perms.patch --]
[-- Type: text/x-patch, Size: 5130 bytes --]

Index: policy/flask/access_vectors
===================================================================
--- policy/flask/access_vectors	(revision 2935)
+++ policy/flask/access_vectors	(working copy)
@@ -723,14 +723,12 @@
 	access
 	install_module
 	load_module
-	get_param
-	set_param
+	superuser
 }
 
 class db_table
 inherits database
 {
-	use
 	select
 	update
 	insert
@@ -749,7 +747,6 @@
 class db_column
 inherits database
 {
-	use
 	select
 	update
 	insert
@@ -759,7 +756,6 @@
 {
 	relabelfrom
 	relabelto
-	use
 	select
 	update
 	insert
Index: policy/modules/services/postgresql.if
===================================================================
--- policy/modules/services/postgresql.if	(revision 2935)
+++ policy/modules/services/postgresql.if	(working copy)
@@ -55,10 +55,10 @@
 		type_transition $2 sepgsql_sysobj_table_type:db_tuple user_sepgsql_sysobj_t;
 	')
 
-	allow $2 user_sepgsql_table_t:db_table  { getattr setattr use select update insert delete };
-	allow $2 user_sepgsql_table_t:db_column { getattr setattr use select update insert };
-	allow $2 user_sepgsql_table_t:db_tuple	{ use select update insert delete };
-	allow $2 user_sepgsql_sysobj_t:db_tuple	{ use select };
+	allow $2 user_sepgsql_table_t:db_table  { getattr setattr select update insert delete lock };
+	allow $2 user_sepgsql_table_t:db_column { getattr setattr select update insert };
+	allow $2 user_sepgsql_table_t:db_tuple	{ select update insert delete };
+	allow $2 user_sepgsql_sysobj_t:db_tuple	{ select };
 
 	allow $2 user_sepgsql_proc_exec_t:db_procedure { create drop getattr setattr execute };
 	type_transition $2 sepgsql_database_type:db_procedure user_sepgsql_proc_exec_t;
Index: policy/modules/services/postgresql.te
===================================================================
--- policy/modules/services/postgresql.te	(revision 2935)
+++ policy/modules/services/postgresql.te	(working copy)
@@ -281,27 +281,27 @@
 # Rules common to all clients
 #
 
-allow sepgsql_client_type sepgsql_db_t:db_database { getattr access get_param set_param };
+allow sepgsql_client_type sepgsql_db_t:db_database { getattr access };
 type_transition sepgsql_client_type sepgsql_client_type:db_database sepgsql_db_t;
 
-allow sepgsql_client_type sepgsql_fixed_table_t:db_table { getattr use select insert };
-allow sepgsql_client_type sepgsql_fixed_table_t:db_column { getattr use select insert };
-allow sepgsql_client_type sepgsql_fixed_table_t:db_tuple { use select insert };
+allow sepgsql_client_type sepgsql_fixed_table_t:db_table { getattr select insert lock };
+allow sepgsql_client_type sepgsql_fixed_table_t:db_column { getattr select insert };
+allow sepgsql_client_type sepgsql_fixed_table_t:db_tuple { select insert };
 
-allow sepgsql_client_type sepgsql_table_t:db_table { getattr use select update insert delete };
-allow sepgsql_client_type sepgsql_table_t:db_column { getattr use select update insert };
-allow sepgsql_client_type sepgsql_table_t:db_tuple { use select update insert delete };
+allow sepgsql_client_type sepgsql_table_t:db_table { getattr select update insert delete lock };
+allow sepgsql_client_type sepgsql_table_t:db_column { getattr select update insert };
+allow sepgsql_client_type sepgsql_table_t:db_tuple { select update insert delete };
 
-allow sepgsql_client_type sepgsql_ro_table_t:db_table { getattr use select };
-allow sepgsql_client_type sepgsql_ro_table_t:db_column { getattr use select };
-allow sepgsql_client_type sepgsql_ro_table_t:db_tuple { use select };
+allow sepgsql_client_type sepgsql_ro_table_t:db_table { getattr select lock };
+allow sepgsql_client_type sepgsql_ro_table_t:db_column { getattr select };
+allow sepgsql_client_type sepgsql_ro_table_t:db_tuple { select };
 
 allow sepgsql_client_type sepgsql_secret_table_t:db_table getattr;
 allow sepgsql_client_type sepgsql_secret_table_t:db_column getattr;
 
-allow sepgsql_client_type sepgsql_sysobj_t:db_table { getattr use select };
-allow sepgsql_client_type sepgsql_sysobj_t:db_column { getattr use select };
-allow sepgsql_client_type sepgsql_sysobj_t:db_tuple { use select };
+allow sepgsql_client_type sepgsql_sysobj_t:db_table { getattr select lock };
+allow sepgsql_client_type sepgsql_sysobj_t:db_column { getattr select };
+allow sepgsql_client_type sepgsql_sysobj_t:db_tuple { select };
 
 allow sepgsql_client_type sepgsql_proc_t:db_procedure { getattr execute install };
 allow sepgsql_client_type sepgsql_trusted_proc_t:db_procedure { getattr execute entrypoint };
@@ -321,7 +321,7 @@
 # to access classified tuples and can make a audit record.
 #
 # Therefore, the following rule is applied for any domains which can connect SE-PostgreSQL.
-dontaudit { postgresql_t sepgsql_client_type sepgsql_unconfined_type } { sepgsql_table_type -sepgsql_sysobj_table_type }:db_tuple { use select update insert delete };
+dontaudit { postgresql_t sepgsql_client_type sepgsql_unconfined_type } { sepgsql_table_type -sepgsql_sysobj_table_type }:db_tuple { select update insert delete };
 
 tunable_policy(`sepgsql_enable_users_ddl',`
 	allow sepgsql_client_type sepgsql_table_t:db_table { create drop setattr };

WARNING: multiple messages have this Message-ID (diff)
From: kaigai@ak.jp.nec.com (KaiGai Kohei)
To: refpolicy@oss.tresys.com
Subject: [refpolicy] The status of SE-PostgreSQL
Date: Mon, 23 Mar 2009 19:37:46 +0900	[thread overview]
Message-ID: <49C7667A.3020804@ak.jp.nec.com> (raw)

Here is a bad news.

I've had a discussion in pgsql-hackers list for a long time, but
we cannot get a conclusion that SE-PostgreSQL should be merged
in the PostgreSQL v8.4 which is the next major release, and it
was postponed to the v8.5 development cycle due to lack of time
for enough reviewing the feature.

If it can be released on schedule, the v8.4 is released on the
second quarter of 2009, and the v8.5 will be relased on a year
later (but it tend to delay a few months).
So, it is necessary to apply SE-PostgreSQL patches or install
it from RPM package distributed via Fedora project. :(

Under the discussion, I got a few suggestions in its security
design, and it seems to me fair enough. Some of them needs to
change definitions in the default policy.

See the following items,

* new permission: db_database:{superuser}

They required a new permission to control database superuser
privileges similar to "root" capability in operating system.
The concept of superuser is common for some of major DBMSs,
not only PostgreSQL. In addition, it seems to me well symmetric
with operating system.

The db_database:{superuser} controls whether the client can
perform as database superuser on the given database, or not.

* undesired permission: db_database:{set_param get_param}

They wondered the necessity of these checks, because SQL spec
does not require checks in set/get database parameters.
I didn't think it is necessary the security design of SELinux
should be symmetric with SQL, but I also thought these might
be unnecessary due to another reason.
In PostgreSQL, the scope of database parameters are session
local and initialized on the connection startup, so we cannot
use it as a pass to communicate between different two or more
domains.

* undesired permission: db_table/db_column/db_tuple:{use}

I originally proposed the {use} permission to set up write-only
tables, but it might be a misdesign.
(Sorry, a bit long description.)

At the initial design, SE-PostgreSQL applied {select} permission
for all the refered tables, columns and tuples. But, it also means
{select} permission is necessary for conditional DELETE or UPDATE
even if its content is not exposed to the client.
So, I proposed the privilege into two different permission: {select}
and {use}. The {select} allows the client to refer the object and
its content can be returned to him. The {use} also allows the client
to refer the object but its content has to be consumed internally.

  Example)
    SELECT a, b FROM t WHERE c = 5;
  In this case, we need {select} on column t.a and t.b, but {use}
  is required on column t.c because its content is consumed by
  SE-PostgreSQL itself and not returned to the client.

  Example)
    UPDATE t SET x = 20 WHERE y = 'aaa';
  In this case, we need {update} on column t.x, and {use} on t.y,
  but {select} is not necessary.

However, we can break it rapidly with a clever condition clause.
For example, we can get a result from the first trial:
  DELETE FROM account WHERE userid = 100 and creditno like '1%';

If this query removes a tuple, it means the first character of
credit card number is '1'. If not so, he can try it 9 times.
Then, he can get the information without {select} permission,
with enough small number of trials.

They concluded the "{use}" permission cannot work correctly, and
danger to expect it does not allow to leak contexnt to the outside.
I can agree this opinion.


The attached patch add/remove these permissions.
Any comments please.

Thanks,
-- 
OSS Platform Development Division, NEC
KaiGai Kohei <kaigai@ak.jp.nec.com>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: refpolicy-sepgsql-perms.patch
Type: text/x-patch
Size: 5130 bytes
Desc: not available
Url : http://oss.tresys.com/pipermail/refpolicy/attachments/20090323/d55fa108/attachment.bin 

             reply	other threads:[~2009-03-23 10:38 UTC|newest]

Thread overview: 75+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-03-23 10:37 KaiGai Kohei [this message]
2009-03-23 10:37 ` [refpolicy] The status of SE-PostgreSQL KaiGai Kohei
2009-03-23 14:56 ` Shaz
2009-03-23 14:57   ` Shaz
2009-03-23 15:19 ` Andy Warner
2009-03-24  2:14   ` KaiGai Kohei
2009-03-24  2:14     ` [refpolicy] " KaiGai Kohei
2009-03-25  6:54     ` Some ideas in SE-PostgreSQL enhancement (Re: The status of SE-PostgreSQL) KaiGai Kohei
2009-03-25  6:54       ` [refpolicy] " KaiGai Kohei
2009-03-25  7:45       ` Andy Warner
2009-03-25  8:20         ` KaiGai Kohei
2009-03-25  8:59           ` Andy Warner
2009-03-25 12:00             ` KaiGai Kohei
2009-03-25 17:02               ` Andy Warner
2009-03-26  0:13                 ` KaiGai Kohei
2009-03-25 17:43         ` Joshua Brindle
2009-03-25 19:42           ` Andy Warner
2009-03-27 15:43             ` Joshua Brindle
2009-03-27 16:25               ` Andy Warner
2009-03-27 17:15                 ` Joshua Brindle
2009-03-27 17:54                   ` Andy Warner
2009-03-27 18:12                     ` Joshua Brindle
2009-03-27 18:48                       ` Andy Warner
2009-03-27 19:53                         ` Joshua Brindle
2009-03-27 20:04                           ` Andy Warner
2009-03-27 23:59                           ` KaiGai Kohei
2009-03-28  7:17                             ` Andy Warner
2009-03-30  0:56                               ` KaiGai Kohei
2009-03-30  8:21                                 ` KaiGai Kohei
2009-03-30  9:58                                   ` Andy Warner
2009-03-30 13:22                                     ` KaiGai Kohei
2009-04-22  0:08                                   ` Eamon Walsh
2009-04-22  3:59                                     ` KaiGai Kohei
2009-05-01  4:54                                       ` Eamon Walsh
2009-05-07  1:34                                         ` KaiGai Kohei
2009-05-07  7:24                                           ` KaiGai Kohei
2009-03-30  9:49                                 ` Andy Warner
2009-03-26  5:50       ` [PATCH] Expose avc_netlink_loop() for applications (Re: Some ideas in SE-PostgreSQL enhancement) KaiGai Kohei
2009-03-26 23:28         ` Eamon Walsh
2009-03-26 23:41         ` Eamon Walsh
2009-03-27  0:35           ` KaiGai Kohei
2009-03-28  0:54             ` Eamon Walsh
2009-03-28  2:00               ` KaiGai Kohei
2009-03-30  4:56                 ` KaiGai Kohei
2009-03-26  6:11       ` [PATCH] database audit integration " KaiGai Kohei
2009-03-26  6:11         ` KaiGai Kohei
2009-03-26 21:45         ` John Dennis
     [not found]         ` <49CB313B.7020507@redhat.com>
2009-03-27  2:34           ` KaiGai Kohei
2009-03-27  2:34             ` KaiGai Kohei
2009-03-26  8:29       ` [PATCH] Permissive domain in userspace " KaiGai Kohei
2009-03-28  2:41         ` Eamon Walsh
2009-03-30  2:55           ` KaiGai Kohei
2009-03-31  1:45             ` KaiGai Kohei
2009-03-31 16:46               ` Stephen Smalley
2009-04-01  1:07                 ` [PATCH] Permissive domain in userspace object manager KaiGai Kohei
2009-04-01  1:41                   ` KaiGai Kohei
2009-04-01 12:34                   ` Stephen Smalley
2009-04-01 20:07                     ` Eric Paris
2009-04-01 22:53                   ` James Morris
2009-03-27  8:18       ` [PATCH] Policy rework for SE-PostgreSQL (Re: Some ideas in SE-PostgreSQL enhancement) KaiGai Kohei
2009-03-27  8:18         ` [refpolicy] " KaiGai Kohei
2009-03-27  9:44         ` Andy Warner
2009-03-27 11:20           ` KaiGai Kohei
2009-03-27 11:20             ` [refpolicy] " KaiGai Kohei
2009-03-27 11:45             ` Andy Warner
2009-03-27 11:45               ` [refpolicy] " Andy Warner
2009-03-27 12:17               ` KaiGai Kohei
2009-03-27 12:17                 ` [refpolicy] " KaiGai Kohei
2009-04-01  7:26       ` Correct manner to handler undefined classes/permissions? " KaiGai Kohei
2009-04-01 12:45         ` Stephen Smalley
2009-04-02  0:28           ` KaiGai Kohei
2009-03-23 15:25 ` The status of SE-PostgreSQL Stephen Smalley
2009-03-23 15:25   ` [refpolicy] " Stephen Smalley
2009-03-24  1:13   ` KaiGai Kohei
2009-03-24  1:13     ` [refpolicy] " KaiGai Kohei

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=49C7667A.3020804@ak.jp.nec.com \
    --to=kaigai@ak.jp.nec.com \
    --cc=refpolicy@oss.tresys.com \
    --cc=selinux@tycho.nsa.gov \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.