[refpolicy] [PATCH] Policy rework for SE-PostgreSQL (Re: Some ideas in SE-PostgreSQL enhancement)

[refpolicy] [PATCH] Policy rework for SE-PostgreSQL (Re: Some ideas in SE-PostgreSQL enhancement)

[Andy Warner]

KaiGai Kohei wrote:

> > The attached patch is the first one in the series of reworks for
> > the SE-PostgreSQL security policy.
> >
> > It updates the following items.
> >
> > * Changes in the definition of object classes
> >
> > This patch add new three object classes and modifies the definition
> > of a few object classes.
> >  - db_database:{get_param set_param} is removed due to nonsense.
> >  - db_database:{superuser} is added to restrict privileges of
> >    database superuser.
> >  - db_table/db_column/db_tuple:{use} is removed due to nonsense.
> >  - New object classes: db_catalog, db_schema and db_sequence are added.
> >
> >   
>   
In the RUBIX policy I used the db_table use permission (could be called
open) to have a simple way to control access to the table as a whole,
much like a file open permission. While not absolutely necessary, I
think it is valuable. The other uses of the use permission I did not
use. Also, see my related comment below on the catalog/schema object
permissions.

> > In the previous design, we have the following object hierarchy:
> >   [db_database]
> >    + [db_table]
> >    |  + [db_column]
> >    |  + [db_tuple]
> >    + [db_procedure]
> >    + [db_blob]
> >
> > The newly added db_schema should be placed between the db_database and
> > the db_table and others. TYPE_TRANSITION rules follows the revised design.
> >
> >   [db_database]
> >    + [db_schema]
> >    |  + [db_table]
> >    |  |   + [db_column]
> >    |  |   + [db_tuple]
> >    |  + [db_procedure]
> >    |  + [db_sequence] (newly added object class)
> >    + [db_blob]
> >
> >   (*) Unfortunatelly, PostgreSQL handles large object quite ad-hoc,
> >       although it can be used to communicate channel between multiple
> >       domains. So, it needs to be placed under the database.
> >
> > Currently, SE-PostgreSQL does not use db_catalog class, but it can be
> > used for other DBMS's.
> >
> > In addition, this patch changes something.
> >
> >  o The trusted procedure (sepgsql_trusted_proc_t) lost the
> >    db_database:{superuser} privilege, because it is invoked by
> >    unprived users to over the MAC restriction for a certain
> >    purpose, but it does not need to allow superpower in DAC.
> >   
>   
Is it intended that the superuser privilege give only DAC override or
both MAC and DAC? Specifically, is it intended to override MLS or Type
enforcement?

> >  o The trusted procedure (sepgsql_trusted_proc_exec_t) lost the
> >    db_procedure:{install} privilege, because once installed procedure
> >    as a system internal entity can be invoked implicitly.
> >    We should not install trusted procedures for the purpose.
> >
> >  o The db_schema:{add_object remove_object} newly added are controled
> >    via the "sepgsql_enable_users_ddl" boolean.
> >    Now we control user's DDLs on uncategorized objects as row-level
> >    checks on sepgsql_sysobj_t, but it can be revised with adding
> >    db_schema object class.
> >   
>   
I think this also needs the equivalent of a "search" permission (or
open, or use). This gives a nice way to control some access to an entire
schema. That is, we want to use the schema (and catalog) as a mechanism
to cut off users from entire subtrees. This helps to ensure that a user
does not gain access to a newly created subordinate object. So, if a
user does not have search for a schema (or catalog), there is no way
they can access any present or future object in that schema (or
catalog). Analogous to a directory. Without this search control I would
continue to use the dir object class.

> >  o type_transition for user_sepgsql_XXXX_t is moved to outside of
> >    tunable_policy(`...'). IIRC, I said these should be inside of
> >    the tunable, but unprive ones cannot create/drop tables labeled
> >    as sepgsql_XXX_t anyway when the boolean is disabled.
> >    So, I reconsidered it should be placed out of the tunable.
> >
> >  o {create drop setattr} permission for user_sepgsql_XXX is moved
> >    to inside of the tunable_policy, even if it is db_procedure
> >    class. I wonder why we didn't control CREATE FUNCTION statement
> >    by unpriv domains.
> >
> >  o db_blob:{import export} on user_sepgsql_blob_t is allowed to
> >    unpriv domains. It seems to me a strange behavior that it is
> >    not allowed on the object created by unpriv domain itself.
> >
> > * Remaining items
> >  o When we allows an unpriv domain to access SE-PostgreSQL using
> >    postgresql_unpriv_client(), its default labeling behavior is
> >    same as unconfined domains. For example, functions created by
> >    them are labeled as "sepgsql_proc_t".
> >    Now I'm considering it should be user_sepgsql_XXXX_t, because
> >    I would like to handle unprefixed types as an object created
> >    by database administrator (unconfined domains).
> >    It helps correctness of db_procedure:{install} permission.
> >
> >  o Because of db_schema object class, we can control user's DDLs
> >    without ad-hoc using row-level security on sepgsql_sysobj_t
> >    class. Now I think its purpose should be changed to prevent
> >    users accesses system catalogs directly.
> >   
>   
Are you implying here the need for something like a search or open
permissions as I suggested above? If so, please disregard my previous
comment:-)

> > Thanks,
> >   
>   

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://oss.tresys.com/pipermail/refpolicy/attachments/20090327/38c58260/attachment-0001.html 

The status of SE-PostgreSQL

[KaiGai Kohei]

[-- 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 };

Re: The status of SE-PostgreSQL

[Andy Warner]

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

Just a thought from working with the DBMS functionality within the
SELinux policy. Has there been any thought or talks about adding support
for catalog or schema objects? When I integrated the SELinux policy into
our DBMS I found them lacking and ended up using the dir object class,
as that closely mimicked our use of catalogs and schemata.

Andy

KaiGai Kohei wrote:
> 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,
>   

[-- Attachment #2: Type: text/html, Size: 4240 bytes --]

Re: The status of SE-PostgreSQL

[KaiGai Kohei]

Andy Warner wrote:
> Just a thought from working with the DBMS functionality within the 
> SELinux policy. Has there been any thought or talks about adding support 
> for catalog or schema objects? When I integrated the SELinux policy into 
> our DBMS I found them lacking and ended up using the dir object class, 
> as that closely mimicked our use of catalogs and schemata.
> 
> Andy

Yes, I initially considered whether we should have "db_schema" object
class or not, but concluded it is not needed strongly because of
differences between two security models.

When we create a new database object (like a table), PostgreSQL checks
"create" privilege on the schema on which the table is placed.
Meanwhile, SELinux checks "db_table:{create}" privilege on the table
itself which has a security context. In other word, the schema works
just a namespace from viewpoint of the SELinux design.

However, I can understand the analogy which you pointed out.
The "dir" object class has "add_name", "remove_name" and
"search" permissions, similar to what the schema doing.

Because the SE-PostgreSQL is postponed to get merged, we can fix
its fundamental design in other words.

Thanks,

> KaiGai Kohei wrote:
>> 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>

--
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.

Some ideas in SE-PostgreSQL enhancement (Re: The status of SE-PostgreSQL)

[KaiGai Kohei]

As I noted in the previous message, SE-PostgreSQL is postponed to
the PostgreSQL v8.5 after the long discussion in the pgsql-hackers
list, unfortunately.
However, it also mean a good chance to revise its design because
we have a few months before v8.5 development cycle launched.

1. Changes in object classes and access vectors
 - add db_database:{superuser} permission
 - remove db_database:{get_param set_param} permission
 - remove db_table/db_column/db_tuple:{use} permission

  Please refer the previous messages for them.

 - add new object class "db_schema"
  As Andy noted, we directly put database objects under the
  db_database class directly. But, some of database objects
  are created under a schema object.
  In other word, RDBMS's design has three level hierachy as:
     <database>  (<-- some DBMSs calls it as <catalog>)
      + <schema>
         + <tables>, <procedures>, ...

  Now, we control user's DDL statement via permissions on
  the sepgsql_sysobj_t type as row-level controls.
  But I think db_schema object class here is meaningful
  to match SQL's design and analogy to the dir class.

  The new db_schema object class inherits six permissions
  from common database objects, and defines three its own
  permissions: add_object, remove_object, usage

  The former two permissions are checked when we create
  or drop database object within the given schema.
  The usage permission is checked when we use database
  objects under the schema.

 - add new object class "db_sequence"
  A secuence object enables to generate a set of sequencial
  numbers to avoid confliction of key value.
  We can set a value on the sequence, and others can fetch it.
  It can be used as an information flow channel.

  The new db_sequence object class inherits six permissions
  from common database objects, and defines two its own
  permissions: get_value and set_value.


2. System audit integration

Now, SE-PostgreSQL writes out its access denied message into
the logfile of PostgreSQL (/var/log/sepostgresql.log).
But it is more desirable approach to write out them into system
audit mechanism, because any other SELinux related messages
are collected here and utilities like audit2allow is available.

TODO:
- changes in the security policy:
  We need to allow postgresql_t to write audit messages.
  In addition, the backend process need to run with cap_audit_write.

- a new interface in audit-libs:
  The current audit-libs has the following interface.

    extern int audit_log_user_avc_message(int audit_fd, int type,
            const char *message, const char *hostname, const char *addr,
            const char *tty, uid_t uid);

  But some arguments are not meaningful in SE-PostgreSQL.
  I would like to write out database role here, instead of tty and uid.


3. Simplifies netlink loops

SE-PostgreSQL needs to implement its own userspace AVC due to
some reasons. When the backend started up, it creates a worker
process to receive messages from in-kernel SELinux via netlink
socket. The worker process invalidates the userspace AVC of
all the instance of PostgreSQL backend process when the state
of SELinux is changed.

However, I think the following loop to receive messages from
netlink socket should be provided via libselinux.

  http://code.google.com/p/sepgsql/source/browse/trunk/core/src/backend/security/sepgsql/avc.c#647

If avc_netlink_loop() provided a callback function, I could push
the code into the libselinux.

TODO:
- a set of new interface on libselinux:
I would like to add a few new interfaces to handle netlink socket
in libselinux, and expose them to application. I guess we can
write the existing standard avc with the interfaces.


4. Permissive domain in userspace

It is an issue got sleep for a few months.
  http://marc.info/?l=selinux&m=122337314619667&w=2


5. Handle unsupported object classes/access vectors

What is the correct behavior for userspace object managers,
when it tries to check undefined object classes or access
vectors?

For example, we don't define db_database:{superuser} in the
security policy. We cannot decide whether it is denied, or not.
How the SE-PostgreSQL should perform for this?

In the current implementation, it simply ignores undefined
permissions because string_to_av_perm() cannot return a valid
access vector.

One possible idea is it performs according to /selinux/deny_unknown.
If so, a new interface on libselinux is desirable.


Any comments are welcome.

Thanks,


KaiGai Kohei wrote:
> Andy Warner wrote:
>> Just a thought from working with the DBMS functionality within the 
>> SELinux policy. Has there been any thought or talks about adding support 
>> for catalog or schema objects? When I integrated the SELinux policy into 
>> our DBMS I found them lacking and ended up using the dir object class, 
>> as that closely mimicked our use of catalogs and schemata.
>>
>> Andy
> 
> Yes, I initially considered whether we should have "db_schema" object
> class or not, but concluded it is not needed strongly because of
> differences between two security models.
> 
> When we create a new database object (like a table), PostgreSQL checks
> "create" privilege on the schema on which the table is placed.
> Meanwhile, SELinux checks "db_table:{create}" privilege on the table
> itself which has a security context. In other word, the schema works
> just a namespace from viewpoint of the SELinux design.
> 
> However, I can understand the analogy which you pointed out.
> The "dir" object class has "add_name", "remove_name" and
> "search" permissions, similar to what the schema doing.
> 
> Because the SE-PostgreSQL is postponed to get merged, we can fix
> its fundamental design in other words.
> 
> Thanks,
> 
>> KaiGai Kohei wrote:
>>> 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>

--
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.

[refpolicy] [PATCH] Policy rework for SE-PostgreSQL (Re: Some ideas in SE-PostgreSQL enhancement)

[KaiGai Kohei]

The attached patch is the first one in the series of reworks for
the SE-PostgreSQL security policy.

It updates the following items.

* Changes in the definition of object classes

This patch add new three object classes and modifies the definition
of a few object classes.
 - db_database:{get_param set_param} is removed due to nonsense.
 - db_database:{superuser} is added to restrict privileges of
   database superuser.
 - db_table/db_column/db_tuple:{use} is removed due to nonsense.
 - New object classes: db_catalog, db_schema and db_sequence are added.

In the previous design, we have the following object hierarchy:
  [db_database]
   + [db_table]
   |  + [db_column]
   |  + [db_tuple]
   + [db_procedure]
   + [db_blob]

The newly added db_schema should be placed between the db_database and
the db_table and others. TYPE_TRANSITION rules follows the revised design.

  [db_database]
   + [db_schema]
   |  + [db_table]
   |  |   + [db_column]
   |  |   + [db_tuple]
   |  + [db_procedure]
   |  + [db_sequence] (newly added object class)
   + [db_blob]

  (*) Unfortunatelly, PostgreSQL handles large object quite ad-hoc,
      although it can be used to communicate channel between multiple
      domains. So, it needs to be placed under the database.

Currently, SE-PostgreSQL does not use db_catalog class, but it can be
used for other DBMS's.

In addition, this patch changes something.

 o The trusted procedure (sepgsql_trusted_proc_t) lost the
   db_database:{superuser} privilege, because it is invoked by
   unprived users to over the MAC restriction for a certain
   purpose, but it does not need to allow superpower in DAC.

 o The trusted procedure (sepgsql_trusted_proc_exec_t) lost the
   db_procedure:{install} privilege, because once installed procedure
   as a system internal entity can be invoked implicitly.
   We should not install trusted procedures for the purpose.

 o The db_schema:{add_object remove_object} newly added are controled
   via the "sepgsql_enable_users_ddl" boolean.
   Now we control user's DDLs on uncategorized objects as row-level
   checks on sepgsql_sysobj_t, but it can be revised with adding
   db_schema object class.

 o type_transition for user_sepgsql_XXXX_t is moved to outside of
   tunable_policy(`...'). IIRC, I said these should be inside of
   the tunable, but unprive ones cannot create/drop tables labeled
   as sepgsql_XXX_t anyway when the boolean is disabled.
   So, I reconsidered it should be placed out of the tunable.

 o {create drop setattr} permission for user_sepgsql_XXX is moved
   to inside of the tunable_policy, even if it is db_procedure
   class. I wonder why we didn't control CREATE FUNCTION statement
   by unpriv domains.

 o db_blob:{import export} on user_sepgsql_blob_t is allowed to
   unpriv domains. It seems to me a strange behavior that it is
   not allowed on the object created by unpriv domain itself.

* Remaining items
 o When we allows an unpriv domain to access SE-PostgreSQL using
   postgresql_unpriv_client(), its default labeling behavior is
   same as unconfined domains. For example, functions created by
   them are labeled as "sepgsql_proc_t".
   Now I'm considering it should be user_sepgsql_XXXX_t, because
   I would like to handle unprefixed types as an object created
   by database administrator (unconfined domains).
   It helps correctness of db_procedure:{install} permission.

 o Because of db_schema object class, we can control user's DDLs
   without ad-hoc using row-level security on sepgsql_sysobj_t
   class. Now I think its purpose should be changed to prevent
   users accesses system catalogs directly.

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

Re: [PATCH] Policy rework for SE-PostgreSQL (Re: Some ideas in SE-PostgreSQL enhancement)

[Andy Warner]

KaiGai Kohei wrote:
> The attached patch is the first one in the series of reworks for
> the SE-PostgreSQL security policy.
>
> It updates the following items.
>
> * Changes in the definition of object classes
>
> This patch add new three object classes and modifies the definition
> of a few object classes.
>  - db_database:{get_param set_param} is removed due to nonsense.
>  - db_database:{superuser} is added to restrict privileges of
>    database superuser.
>  - db_table/db_column/db_tuple:{use} is removed due to nonsense.
>  - New object classes: db_catalog, db_schema and db_sequence are added.
>
>   
In the RUBIX policy I used the db_table use permission (could be called
open) to have a simple way to control access to the table as a whole,
much like a file open permission. While not absolutely necessary, I
think it is valuable. The other uses of the use permission I did not
use. Also, see my related comment below on the catalog/schema object
permissions.
> In the previous design, we have the following object hierarchy:
>   [db_database]
>    + [db_table]
>    |  + [db_column]
>    |  + [db_tuple]
>    + [db_procedure]
>    + [db_blob]
>
> The newly added db_schema should be placed between the db_database and
> the db_table and others. TYPE_TRANSITION rules follows the revised design.
>
>   [db_database]
>    + [db_schema]
>    |  + [db_table]
>    |  |   + [db_column]
>    |  |   + [db_tuple]
>    |  + [db_procedure]
>    |  + [db_sequence] (newly added object class)
>    + [db_blob]
>
>   (*) Unfortunatelly, PostgreSQL handles large object quite ad-hoc,
>       although it can be used to communicate channel between multiple
>       domains. So, it needs to be placed under the database.
>
> Currently, SE-PostgreSQL does not use db_catalog class, but it can be
> used for other DBMS's.
>
> In addition, this patch changes something.
>
>  o The trusted procedure (sepgsql_trusted_proc_t) lost the
>    db_database:{superuser} privilege, because it is invoked by
>    unprived users to over the MAC restriction for a certain
>    purpose, but it does not need to allow superpower in DAC.
>   
Is it intended that the superuser privilege give only DAC override or
both MAC and DAC? Specifically, is it intended to override MLS or Type
enforcement?
>  o The trusted procedure (sepgsql_trusted_proc_exec_t) lost the
>    db_procedure:{install} privilege, because once installed procedure
>    as a system internal entity can be invoked implicitly.
>    We should not install trusted procedures for the purpose.
>
>  o The db_schema:{add_object remove_object} newly added are controled
>    via the "sepgsql_enable_users_ddl" boolean.
>    Now we control user's DDLs on uncategorized objects as row-level
>    checks on sepgsql_sysobj_t, but it can be revised with adding
>    db_schema object class.
>   
I think this also needs the equivalent of a "search" permission (or
open, or use). This gives a nice way to control some access to an entire
schema. That is, we want to use the schema (and catalog) as a mechanism
to cut off users from entire subtrees. This helps to ensure that a user
does not gain access to a newly created subordinate object. So, if a
user does not have search for a schema (or catalog), there is no way
they can access any present or future object in that schema (or
catalog). Analogous to a directory. Without this search control I would
continue to use the dir object class.
>  o type_transition for user_sepgsql_XXXX_t is moved to outside of
>    tunable_policy(`...'). IIRC, I said these should be inside of
>    the tunable, but unprive ones cannot create/drop tables labeled
>    as sepgsql_XXX_t anyway when the boolean is disabled.
>    So, I reconsidered it should be placed out of the tunable.
>
>  o {create drop setattr} permission for user_sepgsql_XXX is moved
>    to inside of the tunable_policy, even if it is db_procedure
>    class. I wonder why we didn't control CREATE FUNCTION statement
>    by unpriv domains.
>
>  o db_blob:{import export} on user_sepgsql_blob_t is allowed to
>    unpriv domains. It seems to me a strange behavior that it is
>    not allowed on the object created by unpriv domain itself.
>
> * Remaining items
>  o When we allows an unpriv domain to access SE-PostgreSQL using
>    postgresql_unpriv_client(), its default labeling behavior is
>    same as unconfined domains. For example, functions created by
>    them are labeled as "sepgsql_proc_t".
>    Now I'm considering it should be user_sepgsql_XXXX_t, because
>    I would like to handle unprefixed types as an object created
>    by database administrator (unconfined domains).
>    It helps correctness of db_procedure:{install} permission.
>
>  o Because of db_schema object class, we can control user's DDLs
>    without ad-hoc using row-level security on sepgsql_sysobj_t
>    class. Now I think its purpose should be changed to prevent
>    users accesses system catalogs directly.
>   
Are you implying here the need for something like a search or open
permissions as I suggested above? If so, please disregard my previous
comment:-)
> Thanks,
>   

--
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.

[refpolicy] [PATCH] Policy rework for SE-PostgreSQL (Re: Some ideas in SE-PostgreSQL enhancement)

[KaiGai Kohei]

Andy Warner wrote:
> 
> KaiGai Kohei wrote:
>> The attached patch is the first one in the series of reworks for
>> the SE-PostgreSQL security policy.
>>
>> It updates the following items.
>>
>> * Changes in the definition of object classes
>>
>> This patch add new three object classes and modifies the definition
>> of a few object classes.
>>  - db_database:{get_param set_param} is removed due to nonsense.
>>  - db_database:{superuser} is added to restrict privileges of
>>    database superuser.
>>  - db_table/db_column/db_tuple:{use} is removed due to nonsense.
>>  - New object classes: db_catalog, db_schema and db_sequence are added.
>>
>>   
> In the RUBIX policy I used the db_table use permission (could be called
> open) to have a simple way to control access to the table as a whole,
> much like a file open permission. While not absolutely necessary, I
> think it is valuable. The other uses of the use permission I did not
> use. Also, see my related comment below on the catalog/schema object
> permissions.

It is incorrect use of use permission.
The use permission was used when we refer the table, but its contents
were not read directly, like:

  SELECT count(*) FROM t WHERE x > 0;

This query refers the table t and column t.x, but its contents are
consumed by backend internally. But it was pointed out such kind of
discrimination is nonsense in pgsql-hackers.

If you need something like "open" permission on the db_table class,
what you should do is submitting a proposition for a new permission.
It is not a right way to apply existing one for another purpose.

If SE-PostgreSQL does not care about, it simply ignore the permission
like as db_catalog class.

>> In the previous design, we have the following object hierarchy:
>>   [db_database]
>>    + [db_table]
>>    |  + [db_column]
>>    |  + [db_tuple]
>>    + [db_procedure]
>>    + [db_blob]
>>
>> The newly added db_schema should be placed between the db_database and
>> the db_table and others. TYPE_TRANSITION rules follows the revised design.
>>
>>   [db_database]
>>    + [db_schema]
>>    |  + [db_table]
>>    |  |   + [db_column]
>>    |  |   + [db_tuple]
>>    |  + [db_procedure]
>>    |  + [db_sequence] (newly added object class)
>>    + [db_blob]
>>
>>   (*) Unfortunatelly, PostgreSQL handles large object quite ad-hoc,
>>       although it can be used to communicate channel between multiple
>>       domains. So, it needs to be placed under the database.
>>
>> Currently, SE-PostgreSQL does not use db_catalog class, but it can be
>> used for other DBMS's.
>>
>> In addition, this patch changes something.
>>
>>  o The trusted procedure (sepgsql_trusted_proc_t) lost the
>>    db_database:{superuser} privilege, because it is invoked by
>>    unprived users to over the MAC restriction for a certain
>>    purpose, but it does not need to allow superpower in DAC.
>>   
> Is it intended that the superuser privilege give only DAC override or
> both MAC and DAC? Specifically, is it intended to override MLS or Type
> enforcement?

If the client does not have db_database:{superuser} privilege,
he cannot perform as database superuser, even if the DAC policy
allows. Please note that MAC stuff does not have a concept of
superuser. All the player need to be checked by the reference
monitor and its security policy.

>>  o The trusted procedure (sepgsql_trusted_proc_exec_t) lost the
>>    db_procedure:{install} privilege, because once installed procedure
>>    as a system internal entity can be invoked implicitly.
>>    We should not install trusted procedures for the purpose.
>>
>>  o The db_schema:{add_object remove_object} newly added are controled
>>    via the "sepgsql_enable_users_ddl" boolean.
>>    Now we control user's DDLs on uncategorized objects as row-level
>>    checks on sepgsql_sysobj_t, but it can be revised with adding
>>    db_schema object class.
>>   
> I think this also needs the equivalent of a "search" permission (or
> open, or use). This gives a nice way to control some access to an entire
> schema. That is, we want to use the schema (and catalog) as a mechanism
> to cut off users from entire subtrees. This helps to ensure that a user
> does not gain access to a newly created subordinate object. So, if a
> user does not have search for a schema (or catalog), there is no way
> they can access any present or future object in that schema (or
> catalog). Analogous to a directory. Without this search control I would
> continue to use the dir object class.

This boolean controls the capability of DDL statement from unpriv
users. They should access existing objects via DML, even if they
cannot modify the definition of tables and so on.
I don't think your suggestion is correct one.

>>  o type_transition for user_sepgsql_XXXX_t is moved to outside of
>>    tunable_policy(`...'). IIRC, I said these should be inside of
>>    the tunable, but unprive ones cannot create/drop tables labeled
>>    as sepgsql_XXX_t anyway when the boolean is disabled.
>>    So, I reconsidered it should be placed out of the tunable.
>>
>>  o {create drop setattr} permission for user_sepgsql_XXX is moved
>>    to inside of the tunable_policy, even if it is db_procedure
>>    class. I wonder why we didn't control CREATE FUNCTION statement
>>    by unpriv domains.
>>
>>  o db_blob:{import export} on user_sepgsql_blob_t is allowed to
>>    unpriv domains. It seems to me a strange behavior that it is
>>    not allowed on the object created by unpriv domain itself.
>>
>> * Remaining items
>>  o When we allows an unpriv domain to access SE-PostgreSQL using
>>    postgresql_unpriv_client(), its default labeling behavior is
>>    same as unconfined domains. For example, functions created by
>>    them are labeled as "sepgsql_proc_t".
>>    Now I'm considering it should be user_sepgsql_XXXX_t, because
>>    I would like to handle unprefixed types as an object created
>>    by database administrator (unconfined domains).
>>    It helps correctness of db_procedure:{install} permission.
>>
>>  o Because of db_schema object class, we can control user's DDLs
>>    without ad-hoc using row-level security on sepgsql_sysobj_t
>>    class. Now I think its purpose should be changed to prevent
>>    users accesses system catalogs directly.
>>   
> Are you implying here the need for something like a search or open
> permissions as I suggested above? If so, please disregard my previous
> comment:-)
>> Thanks,
>>   
> 
> --
> This message was distributed to subscribers of the selinux mailing list.
> If you no longer wish to subscribe, send mail to majordomo at tycho.nsa.gov with
> the words "unsubscribe selinux" without quotes as the message.
> 


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

[refpolicy] [PATCH] Policy rework for SE-PostgreSQL (Re: Some ideas in SE-PostgreSQL enhancement)

[Andy Warner]

KaiGai Kohei wrote:
> Andy Warner wrote:
>   
>> KaiGai Kohei wrote:
>>     
>>> The attached patch is the first one in the series of reworks for
>>> the SE-PostgreSQL security policy.
>>>
>>> It updates the following items.
>>>
>>> * Changes in the definition of object classes
>>>
>>> This patch add new three object classes and modifies the definition
>>> of a few object classes.
>>>  - db_database:{get_param set_param} is removed due to nonsense.
>>>  - db_database:{superuser} is added to restrict privileges of
>>>    database superuser.
>>>  - db_table/db_column/db_tuple:{use} is removed due to nonsense.
>>>  - New object classes: db_catalog, db_schema and db_sequence are added.
>>>       

I guess I should have asked before, is there is any proposed permission
set for the three new object classes mentioned above?
>>>   
>>>       
>> In the RUBIX policy I used the db_table use permission (could be called
>> open) to have a simple way to control access to the table as a whole,
>> much like a file open permission. While not absolutely necessary, I
>> think it is valuable. The other uses of the use permission I did not
>> use. Also, see my related comment below on the catalog/schema object
>> permissions.
>>     
>
> It is incorrect use of use permission.
> The use permission was used when we refer the table, but its contents
> were not read directly, like:
>
>   SELECT count(*) FROM t WHERE x > 0;
>
> This query refers the table t and column t.x, but its contents are
> consumed by backend internally. But it was pointed out such kind of
> discrimination is nonsense in pgsql-hackers.
>
> If you need something like "open" permission on the db_table class,
> what you should do is submitting a proposition for a new permission.
> It is not a right way to apply existing one for another purpose.
>
> If SE-PostgreSQL does not care about, it simply ignore the permission
> like as db_catalog class.
>   
I understand now and then the intent of the use permission. If I need
functionality from the database object classes that is not provided,
then I have little option other than use something in a way that is not
"correct". Such as my use of the dir object class to account for not
having object classes for schemata and catalog. And, from a user's point
of view, a permission called "use" works well with being to (or not) use
a table. So, I think it was quite reasonable to use it for my purposes.
I'm not sure what the official means of proposing a new permission is,
but I thought this thread was a discussion of any changes that may need
to made to the database policy, and since you are removing the use
permission, I thought it relevant. Call the permission "use" or call if
"open", the intent of my comment was to suggest that policy support for
the semantics of how I used the use permission would be good.
>   
>>> In the previous design, we have the following object hierarchy:
>>>   [db_database]
>>>    + [db_table]
>>>    |  + [db_column]
>>>    |  + [db_tuple]
>>>    + [db_procedure]
>>>    + [db_blob]
>>>
>>> The newly added db_schema should be placed between the db_database and
>>> the db_table and others. TYPE_TRANSITION rules follows the revised design.
>>>
>>>   [db_database]
>>>    + [db_schema]
>>>    |  + [db_table]
>>>    |  |   + [db_column]
>>>    |  |   + [db_tuple]
>>>    |  + [db_procedure]
>>>    |  + [db_sequence] (newly added object class)
>>>    + [db_blob]
>>>
>>>   (*) Unfortunatelly, PostgreSQL handles large object quite ad-hoc,
>>>       although it can be used to communicate channel between multiple
>>>       domains. So, it needs to be placed under the database.
>>>
>>> Currently, SE-PostgreSQL does not use db_catalog class, but it can be
>>> used for other DBMS's.
>>>
>>> In addition, this patch changes something.
>>>
>>>  o The trusted procedure (sepgsql_trusted_proc_t) lost the
>>>    db_database:{superuser} privilege, because it is invoked by
>>>    unprived users to over the MAC restriction for a certain
>>>    purpose, but it does not need to allow superpower in DAC.
>>>   
>>>       
>> Is it intended that the superuser privilege give only DAC override or
>> both MAC and DAC? Specifically, is it intended to override MLS or Type
>> enforcement?
>>     
>
> If the client does not have db_database:{superuser} privilege,
> he cannot perform as database superuser, even if the DAC policy
> allows. Please note that MAC stuff does not have a concept of
> superuser. All the player need to be checked by the reference
> monitor and its security policy.
>
>   
>>>  o The trusted procedure (sepgsql_trusted_proc_exec_t) lost the
>>>    db_procedure:{install} privilege, because once installed procedure
>>>    as a system internal entity can be invoked implicitly.
>>>    We should not install trusted procedures for the purpose.
>>>
>>>  o The db_schema:{add_object remove_object} newly added are controled
>>>    via the "sepgsql_enable_users_ddl" boolean.
>>>    Now we control user's DDLs on uncategorized objects as row-level
>>>    checks on sepgsql_sysobj_t, but it can be revised with adding
>>>    db_schema object class.
>>>   
>>>       
>> I think this also needs the equivalent of a "search" permission (or
>> open, or use). This gives a nice way to control some access to an entire
>> schema. That is, we want to use the schema (and catalog) as a mechanism
>> to cut off users from entire subtrees. This helps to ensure that a user
>> does not gain access to a newly created subordinate object. So, if a
>> user does not have search for a schema (or catalog), there is no way
>> they can access any present or future object in that schema (or
>> catalog). Analogous to a directory. Without this search control I would
>> continue to use the dir object class.
>>     
>
> This boolean controls the capability of DDL statement from unpriv
> users. They should access existing objects via DML, even if they
> cannot modify the definition of tables and so on.
> I don't think your suggestion is correct one.
>   
I think you misunderstood me. I was not commenting on the boolean at
all. I was commenting on the reference to "db_schema:{add_object
remove_object}" thinking (assuming) that add_object and remove_object
were the only two permission given to the db_schema object class. Is
this the intent? I did not see anywhere in the email that defined the
set of permissions the db_schema (or db_catalog) would have.
>   
>>>  o type_transition for user_sepgsql_XXXX_t is moved to outside of
>>>    tunable_policy(`...'). IIRC, I said these should be inside of
>>>    the tunable, but unprive ones cannot create/drop tables labeled
>>>    as sepgsql_XXX_t anyway when the boolean is disabled.
>>>    So, I reconsidered it should be placed out of the tunable.
>>>
>>>  o {create drop setattr} permission for user_sepgsql_XXX is moved
>>>    to inside of the tunable_policy, even if it is db_procedure
>>>    class. I wonder why we didn't control CREATE FUNCTION statement
>>>    by unpriv domains.
>>>
>>>  o db_blob:{import export} on user_sepgsql_blob_t is allowed to
>>>    unpriv domains. It seems to me a strange behavior that it is
>>>    not allowed on the object created by unpriv domain itself.
>>>
>>> * Remaining items
>>>  o When we allows an unpriv domain to access SE-PostgreSQL using
>>>    postgresql_unpriv_client(), its default labeling behavior is
>>>    same as unconfined domains. For example, functions created by
>>>    them are labeled as "sepgsql_proc_t".
>>>    Now I'm considering it should be user_sepgsql_XXXX_t, because
>>>    I would like to handle unprefixed types as an object created
>>>    by database administrator (unconfined domains).
>>>    It helps correctness of db_procedure:{install} permission.
>>>
>>>  o Because of db_schema object class, we can control user's DDLs
>>>    without ad-hoc using row-level security on sepgsql_sysobj_t
>>>    class. Now I think its purpose should be changed to prevent
>>>    users accesses system catalogs directly.
>>>   
>>>       
>> Are you implying here the need for something like a search or open
>> permissions as I suggested above? If so, please disregard my previous
>> comment:-)
>>     
>>> Thanks,
>>>   
>>>       
>> --
>> This message was distributed to subscribers of the selinux mailing list.
>> If you no longer wish to subscribe, send mail to majordomo at tycho.nsa.gov with
>> the words "unsubscribe selinux" without quotes as the message.
>>
>>     
>
>
>   
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://oss.tresys.com/pipermail/refpolicy/attachments/20090327/823bbafa/attachment.html 

[refpolicy] [PATCH] Policy rework for SE-PostgreSQL (Re: Some ideas in SE-PostgreSQL enhancement)

[KaiGai Kohei]

Andy Warner wrote:
> 
> 
> KaiGai Kohei wrote:
>> Andy Warner wrote:
>>   
>>> KaiGai Kohei wrote:
>>>     
>>>> The attached patch is the first one in the series of reworks for
>>>> the SE-PostgreSQL security policy.
>>>>
>>>> It updates the following items.
>>>>
>>>> * Changes in the definition of object classes
>>>>
>>>> This patch add new three object classes and modifies the definition
>>>> of a few object classes.
>>>>  - db_database:{get_param set_param} is removed due to nonsense.
>>>>  - db_database:{superuser} is added to restrict privileges of
>>>>    database superuser.
>>>>  - db_table/db_column/db_tuple:{use} is removed due to nonsense.
>>>>  - New object classes: db_catalog, db_schema and db_sequence are added.
>>>>       
> 
> I guess I should have asked before, is there is any proposed permission 
> set for the three new object classes mentioned above?

In the attached patch:
--------
+# More database stuff
+class db_catalog
+inherits database
+{
+	search
+	add_object
+	remove_object
+}
+
+class db_schema
+inherits database
+{
+	search
+	add_object
+	remove_object
+}
+
+class db_sequence
+inherits database
+{
+	get_value
+	set_value
+}
--------

The db_catalog, db_schema and db_sequence inherit six permissions
from common database object.

  create        ... should be checked when the object is created
  drop          ... should be checked when the object is dropped
  getattr       ... should be checked when its metadata is changed
  setattr       ... should be checked when its metadata is changed
  relabelfrom   ... should be checked when its security context is changed
  relabelto     ... same as relabelfrom

And these object class has its own permission:

  search        ... should be checked when a object under the namespace
                    is refered.
  add_object    ... should be checked when we add a object under the namespace
  remove_object ... should be checked when we remove a object under the namespace
   (*) namespace means catalog or schema, here.
  get_value     ... should be checked when we fetch a value from the sequence
  set_value     ... should be checked when we reset the sequence

> I understand now and then the intent of the use permission. If I need 
> functionality from the database object classes that is not provided, 
> then I have little option other than use something in a way that is not 
> "correct". Such as my use of the dir object class to account for not 
> having object classes for schemata and catalog. And, from a user's point 
> of view, a permission called "use" works well with being to (or not) use 
> a table. So, I think it was quite reasonable to use it for my purposes. 
> I'm not sure what the official means of proposing a new permission is, 
> but I thought this thread was a discussion of any changes that may need 
> to made to the database policy, and since you are removing the use 
> permission, I thought it relevant. Call the permission "use" or call if 
> "open", the intent of my comment was to suggest that policy support for 
> the semantics of how I used the use permission would be good.

I don't intend you to force my opinion.
However, it's not unclear the purpose of your "use" permission on
db_table class. If you prevent users to access the tabel, it can
be controled via select, update, delete, insert and other permission.

I can understand "search" permission on the db_catalog and db_schema
as an analogy of directory.
But it is not suitable for tables, procedures or others, because it
does not intend to hide existence of these object.
For example, when "cat.schm.tbl_A" is invisible, I can try to create
a table with same name then get an error. It enables us to know
existence of the table, so such kind of permission is nonsense.

>>>>  o The db_schema:{add_object remove_object} newly added are controled
>>>>    via the "sepgsql_enable_users_ddl" boolean.
>>>>    Now we control user's DDLs on uncategorized objects as row-level
>>>>    checks on sepgsql_sysobj_t, but it can be revised with adding
>>>>    db_schema object class.
>>>>   
>>>>       
>>> I think this also needs the equivalent of a "search" permission (or
>>> open, or use). This gives a nice way to control some access to an entire
>>> schema. That is, we want to use the schema (and catalog) as a mechanism
>>> to cut off users from entire subtrees. This helps to ensure that a user
>>> does not gain access to a newly created subordinate object. So, if a
>>> user does not have search for a schema (or catalog), there is no way
>>> they can access any present or future object in that schema (or
>>> catalog). Analogous to a directory. Without this search control I would
>>> continue to use the dir object class.
>>>     
>>
>> This boolean controls the capability of DDL statement from unpriv
>> users. They should access existing objects via DML, even if they
>> cannot modify the definition of tables and so on.
>> I don't think your suggestion is correct one.
>>   
> I think you misunderstood me. I was not commenting on the boolean at 
> all. I was commenting on the reference to "db_schema:{add_object 
> remove_object}" thinking (assuming) that add_object and remove_object 
> were the only two permission given to the db_schema object class. Is 
> this the intent? I did not see anywhere in the email that defined the 
> set of permissions the db_schema (or db_catalog) would have.

As I noted above, the db_schema object class has 9 permissions in total.
It also includes "search" permission.

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