The status of SE-PostgreSQL

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

[refpolicy] The status of SE-PostgreSQL

[KaiGai Kohei]

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 

Re: The status of SE-PostgreSQL

[Shaz]

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

Some updates on SE-posgreSql.

2009/3/23 KaiGai Kohei <kaigai@ak.jp.nec.com>

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



-- 
Shaz

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

Re: The status of SE-PostgreSQL

[Shaz]

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

On Mon, Mar 23, 2009 at 7:56 PM, Shaz <shazalive@gmail.com> wrote:

> Some updates on SE-posgreSql.


Sorry this was meant for my students.

>
>
> 2009/3/23 KaiGai Kohei <kaigai@ak.jp.nec.com>
>
> 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>
>>
>
>
>
> --
> Shaz
>
>


-- 
Shaz

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

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

[Stephen Smalley]

On Mon, 2009-03-23 at 19:37 +0900, 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.

Any chance of splitting this up into finer-grained privileges?
And what precisely are the implications of this permission:  does it
effectively make all of the other permission checks irrelevant for the
subject?  In comparison, the SELinux capability permissions only allow
the subject to override e.g. DAC file checks, not the SELinux MAC file
checks.

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

Are any of the database parameters security-relevant (not just
information flow)?

-- 
Stephen Smalley
National Security Agency


--
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] The status of SE-PostgreSQL

[Stephen Smalley]

On Mon, 2009-03-23 at 19:37 +0900, 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.

Any chance of splitting this up into finer-grained privileges?
And what precisely are the implications of this permission:  does it
effectively make all of the other permission checks irrelevant for the
subject?  In comparison, the SELinux capability permissions only allow
the subject to override e.g. DAC file checks, not the SELinux MAC file
checks.

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

Are any of the database parameters security-relevant (not just
information flow)?

-- 
Stephen Smalley
National Security Agency

Re: The status of SE-PostgreSQL

[KaiGai Kohei]

>> 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.
> 
> Any chance of splitting this up into finer-grained privileges?

I basically think it is good idea from the viewpoint of security.
However, if they separate the superuser privige into finer-grained
ones without SQL specification, its design will fully depends on
PostgreSQL.

> And what precisely are the implications of this permission:  does it
> effectively make all of the other permission checks irrelevant for the
> subject?  In comparison, the SELinux capability permissions only allow
> the subject to override e.g. DAC file checks, not the SELinux MAC file
> checks.

In currently, it checks the context of client (subject) and the one
of database (object), but it can be fixed soon.
We already have several permissions on db_database class. Some of
them are checked on the database object, and the "superuser" is
checked on the subject itself. Is it no matter?

>> * 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.
> 
> Are any of the database parameters security-relevant (not just
> information flow)?

It provide a parameter of "sepostgresql=(on|off)" to turn on/off
its feature, but it is not allowed to change via SQL commands.
This parameter is initialized with the configuration file on
the server startup time, then it is handled as read-only.

If a man who can modify "$PGDATA/postgresql.conf" disables
SE-PostgreSQL, we have the matter in different place.

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] The status of SE-PostgreSQL

[KaiGai Kohei]

>> 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.
> 
> Any chance of splitting this up into finer-grained privileges?

I basically think it is good idea from the viewpoint of security.
However, if they separate the superuser privige into finer-grained
ones without SQL specification, its design will fully depends on
PostgreSQL.

> And what precisely are the implications of this permission:  does it
> effectively make all of the other permission checks irrelevant for the
> subject?  In comparison, the SELinux capability permissions only allow
> the subject to override e.g. DAC file checks, not the SELinux MAC file
> checks.

In currently, it checks the context of client (subject) and the one
of database (object), but it can be fixed soon.
We already have several permissions on db_database class. Some of
them are checked on the database object, and the "superuser" is
checked on the subject itself. Is it no matter?

>> * 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.
> 
> Are any of the database parameters security-relevant (not just
> information flow)?

It provide a parameter of "sepostgresql=(on|off)" to turn on/off
its feature, but it is not allowed to change via SQL commands.
This parameter is initialized with the configuration file on
the server startup time, then it is handled as read-only.

If a man who can modify "$PGDATA/postgresql.conf" disables
SE-PostgreSQL, we have the matter in different place.

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

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.

[refpolicy] 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>

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

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

[Andy Warner]

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



KaiGai Kohei wrote:
> 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
>   
I would suggest that the SQL catalog object should also be supported.
Though not common in implementation, it is part of the SQL spec. Our
DBMS (Trusted RUBIX) supports it, and for us it is basically another
level in the naming. (database.catalog.schema.table). I would suggest
that a db_catalog object be included with the same basic semantics as
the db_schema object.

In our selinux policy, we encourage users to partition the database
space up by catalog, where each catalog is "owned" by an selinux domain.
Rules are then setup so that domain may create schemata, tables, etc.
under that catalog. It provides a MAC security partitioning by catalog
subtree, and allows the user to be able to logically create their own
DBMS schema subtree according to personal needs, such as one schema per
linux logon user, protected using the DAC policy. Of course, other
security architectures are possible. But, my point is that the catalog
object allows us to the this in a nice, modular way. Where, if we only
had the schema to work with this would not be possible.
>   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,
>>>>         
>
>   

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

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

[KaiGai Kohei]

Andy Warner wrote:
> 
> 
> KaiGai Kohei wrote:
>> 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
>>   
> I would suggest that the SQL catalog object should also be supported. 
> Though not common in implementation, it is part of the SQL spec. Our 
> DBMS (Trusted RUBIX) supports it, and for us it is basically another 
> level in the naming. (database.catalog.schema.table). I would suggest 
> that a db_catalog object be included with the same basic semantics as 
> the db_schema object.

I wonder you are talking about same object in another name.
The "database" is the most gross level separation in PostgreSQL,
similar to catalog in your explanation.
When a user logs in PostgreSQL, he has to choose a "database" and
he cannot access any database object stored within another "database".

NOTE: PostgreSQL can handle several databases concurrently, but
      a user can only one database in a database session.

> In our selinux policy, we encourage users to partition the database 
> space up by catalog, where each catalog is "owned" by an selinux domain.

It is not correct design to port an idea of ownership in SELinux.

> Rules are then setup so that domain may create schemata, tables, etc. 
> under that catalog.

The create permission should be checked on the newly created object
itself. For example, when a table is created with a security context
X_t, the client has to be allowed db_table:{create} on X_t.

> It provides a MAC security partitioning by catalog 
> subtree, and allows the user to be able to logically create their own 
> DBMS schema subtree according to personal needs, such as one schema per 
> linux logon user, protected using the DAC policy. Of course, other 
> security architectures are possible. But, my point is that the catalog 
> object allows us to the this in a nice, modular way. Where, if we only 
> had the schema to work with this would not be possible.

Is is not still possible, if you handle db_database class as the
object class to represent the catalog in RUBIX?

Thanks,

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

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

[Andy Warner]

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



KaiGai Kohei wrote:
> Andy Warner wrote:
>   
>> KaiGai Kohei wrote:
>>     
>>> 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
>>>   
>>>       
>> I would suggest that the SQL catalog object should also be supported. 
>> Though not common in implementation, it is part of the SQL spec. Our 
>> DBMS (Trusted RUBIX) supports it, and for us it is basically another 
>> level in the naming. (database.catalog.schema.table). I would suggest 
>> that a db_catalog object be included with the same basic semantics as 
>> the db_schema object.
>>     
>
> I wonder you are talking about same object in another name.
> The "database" is the most gross level separation in PostgreSQL,
> similar to catalog in your explanation.
> When a user logs in PostgreSQL, he has to choose a "database" and
> he cannot access any database object stored within another "database".
>
> NOTE: PostgreSQL can handle several databases concurrently, but
>       a user can only one database in a database session.
>
>   
I do not believe so. We also have a database concept much like
PostgreSQL. With RUBIX a user may connect to a database, may only have
one database during a connection, and SQL operations cannot access
objects in other databases (or, if they do, you have moved into the
realm of distributed transactions/databases).

Our catalog object is directly usable in queries. For instance, select *
from catalog1.schema1.table1 and select * from catalog2.schema2.table2
are both valid statements within a single database. So, it is an
extension of the naming to a level beyond the schema.

My assumption is that since the db_* objects within the selinux policy
are to used by DBMS's in general, we should recognize (but not
necessarily be subservient to) some standards, where the SQL standard
seems relevant in this case. Others, such as ODBC/JDBC may also be
relevant. Note that ODBC has support for objects named database,
catalog, and schema. ODBC also has support for naming objects in queries
as catalog.schema.table.

In SQL (I am going by Date's "A Guide to The SQL Standard"), there is
actually no object called database (though this is obviously in common
use). Date identifies three relevant objects: the cluster, catalog, and
schema. he also states that the SQL spec is very loose on defining these
terms. But, Dates interpretation looks like:

cluster: groups of catalogs; the group is defined as all catalogs that
describe any object that may be accessible to a given user;each
SQL-session has exactly one associated cluster which defines the
totality of the SQL-data that is available to that SQL-session; SQL
operations are not allowed to span clusters.

catalog: consists of a set of schemata

schema: contains a collection of tables, views, etc. Generally, but not
required to be associated with a particular user's objects.
Note: According to Date's interpretation of the SQl spec, SQL operations
are allowed to span schemata and catalogs. So, it is possible to join
tables that reside in different catalogs and/or schemata. This is a
major reason for needing support for db_schema and db_catalog objects in
SELinux.

So, based upon the above I would say that PostgreSQL's database object
(as well as RUBIX's) is analogous to the cluster. I think database is a
much more common term. Based upon the fact that SQL and ODBC (JDBC?)
provide support for directly accessing DBMS objects (e.g., in a select
statement) using the catalog and schema (but not database), I would
still propose that both db_catalog and db_schema support are needed in
SELinux. Obviously, the db_database also needs to be provided, as it is.

>From my rather limited understanding of SELinux I do not believe that is
a technical problem with having an object class, such as db_catalog,
that a particular DBMS does not use. Correct?
>> In our selinux policy, we encourage users to partition the database 
>> space up by catalog, where each catalog is "owned" by an selinux domain.
>>     
>
> It is not correct design to port an idea of ownership in SELinux.
>
>   
>> Rules are then setup so that domain may create schemata, tables, etc. 
>> under that catalog.
>>     
>
> The create permission should be checked on the newly created object
> itself. For example, when a table is created with a security context
> X_t, the client has to be allowed db_table:{create} on X_t.
>
>   
>> It provides a MAC security partitioning by catalog 
>> subtree, and allows the user to be able to logically create their own 
>> DBMS schema subtree according to personal needs, such as one schema per 
>> linux logon user, protected using the DAC policy. Of course, other 
>> security architectures are possible. But, my point is that the catalog 
>> object allows us to the this in a nice, modular way. Where, if we only 
>> had the schema to work with this would not be possible.
>>     
>
> Is is not still possible, if you handle db_database class as the
> object class to represent the catalog in RUBIX?
>
> Thanks,
>
>   
>>>   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,
>>>>>>         
>>>>>>             
>>>   
>>>       
>
>
>   

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

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

[KaiGai Kohei]

Andy Warner wrote:
> 
> 
> KaiGai Kohei wrote:
>> Andy Warner wrote:
>>   
>>> KaiGai Kohei wrote:
>>>     
>>>> 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
>>>>   
>>>>       
>>> I would suggest that the SQL catalog object should also be supported. 
>>> Though not common in implementation, it is part of the SQL spec. Our 
>>> DBMS (Trusted RUBIX) supports it, and for us it is basically another 
>>> level in the naming. (database.catalog.schema.table). I would suggest 
>>> that a db_catalog object be included with the same basic semantics as 
>>> the db_schema object.
>>>     
>>
>> I wonder you are talking about same object in another name.
>> The "database" is the most gross level separation in PostgreSQL,
>> similar to catalog in your explanation.
>> When a user logs in PostgreSQL, he has to choose a "database" and
>> he cannot access any database object stored within another "database".
>>
>> NOTE: PostgreSQL can handle several databases concurrently, but
>>       a user can only one database in a database session.
>>
>>   
> I do not believe so. We also have a database concept much like 
> PostgreSQL. With RUBIX a user may connect to a database, may only have 
> one database during a connection, and SQL operations cannot access 
> objects in other databases (or, if they do, you have moved into the 
> realm of distributed transactions/databases).

Yes, it is same as PostgreSQL doing.
Here is one question. What object is checked for the permission
something like whether a client can log on?
I guess RUBIX checks this permission on the database itself, not
a catalog. Is it correct?

> Our catalog object is directly usable in queries. For instance, select * 
> from catalog1.schema1.table1 and select * from catalog2.schema2.table2 
> are both valid statements within a single database. So, it is an 
> extension of the naming to a level beyond the schema.

PostgreSQL does not support such kind of qualification now.
All we can do is something like "schema1.table1" in maximum.

> My assumption is that since the db_* objects within the selinux policy 
> are to used by DBMS's in general, we should recognize (but not 
> necessarily be subservient to) some standards, where the SQL standard 
> seems relevant in this case. Others, such as ODBC/JDBC may also be 
> relevant. Note that ODBC has support for objects named database, 
> catalog, and schema. ODBC also has support for naming objects in queries 
> as catalog.schema.table.

Yes, I'm not a fundamentalist of SQL, but I think the selinux policy
should not be designed for a specific DBMS as far as possible.
The reason why I wondered for a new object class of catalogs is
that it seems to me a synonym.

> So, based upon the above I would say that PostgreSQL's database object 
> (as well as RUBIX's) is analogous to the cluster. I think database is a 
> much more common term. Based upon the fact that SQL and ODBC (JDBC?) 
> provide support for directly accessing DBMS objects (e.g., in a select 
> statement) using the catalog and schema (but not database), I would 
> still propose that both db_catalog and db_schema support are needed in 
> SELinux. Obviously, the db_database also needs to be provided, as it is.
> 
> From my rather limited understanding of SELinux I do not believe that 
> is a technical problem with having an object class, such as db_catalog, 
> that a particular DBMS does not use. Correct?

At least, I don't oppose to db_catalog class as far as we can make
clear the differences between databases, catalogs and schemas.
In PostgreSQL, it does not have an idea of catalog as a namespace
upper than schema, so we cannot handle these object obviously,
even if it is defined in the security policy.

I have still a question. Is there any functional differences between
a catalog and a schema? If both of them works just a namespace, we
can apply db_schema class and its permission on both of catalogs and
schema.
In other word, when we accesses /var/log/messages, we need to have
privileges for /var and /var/log on dir class and /var/log/message
on file class. The reason why dir class is applied both of /var
and /var/log is these are same kind of object.
(Perhaps, this suggestion might be a misdesign.)

Thanks,

>>> In our selinux policy, we encourage users to partition the database 
>>> space up by catalog, where each catalog is "owned" by an selinux domain.
>>>     
>>
>> It is not correct design to port an idea of ownership in SELinux.
>>
>>   
>>> Rules are then setup so that domain may create schemata, tables, etc. 
>>> under that catalog.
>>>     
>>
>> The create permission should be checked on the newly created object
>> itself. For example, when a table is created with a security context
>> X_t, the client has to be allowed db_table:{create} on X_t.
>>
>>   
>>> It provides a MAC security partitioning by catalog 
>>> subtree, and allows the user to be able to logically create their own 
>>> DBMS schema subtree according to personal needs, such as one schema per 
>>> linux logon user, protected using the DAC policy. Of course, other 
>>> security architectures are possible. But, my point is that the catalog 
>>> object allows us to the this in a nice, modular way. Where, if we only 
>>> had the schema to work with this would not be possible.
>>>     
>>
>> Is is not still possible, if you handle db_database class as the
>> object class to represent the catalog in RUBIX?
>>
>> Thanks,
>>
>>   
>>>>   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,
>>>>>>>         
>>>>>>>             
>>>>   
>>>>       
>>
>>
>>   


-- 
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: Some ideas in SE-PostgreSQL enhancement (Re: The status of SE-PostgreSQL)

[Andy Warner]

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



KaiGai Kohei wrote:
> Andy Warner wrote:
>   
>> KaiGai Kohei wrote:
>>     
>>> Andy Warner wrote:
>>>   
>>>       
>>>> KaiGai Kohei wrote:
>>>>     
>>>>         
>>>>> 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
>>>>>   
>>>>>       
>>>>>           
>>>> I would suggest that the SQL catalog object should also be supported. 
>>>> Though not common in implementation, it is part of the SQL spec. Our 
>>>> DBMS (Trusted RUBIX) supports it, and for us it is basically another 
>>>> level in the naming. (database.catalog.schema.table). I would suggest 
>>>> that a db_catalog object be included with the same basic semantics as 
>>>> the db_schema object.
>>>>     
>>>>         
>>> I wonder you are talking about same object in another name.
>>> The "database" is the most gross level separation in PostgreSQL,
>>> similar to catalog in your explanation.
>>> When a user logs in PostgreSQL, he has to choose a "database" and
>>> he cannot access any database object stored within another "database".
>>>
>>> NOTE: PostgreSQL can handle several databases concurrently, but
>>>       a user can only one database in a database session.
>>>
>>>   
>>>       
>> I do not believe so. We also have a database concept much like 
>> PostgreSQL. With RUBIX a user may connect to a database, may only have 
>> one database during a connection, and SQL operations cannot access 
>> objects in other databases (or, if they do, you have moved into the 
>> realm of distributed transactions/databases).
>>     
>
> Yes, it is same as PostgreSQL doing.
> Here is one question. What object is checked for the permission
> something like whether a client can log on?
> I guess RUBIX checks this permission on the database itself, not
> a catalog. Is it correct?
>   
Correct. You must some permission on the database to log on. Both SQL
DAC and SELinux.
>   
>> Our catalog object is directly usable in queries. For instance, select * 
>> from catalog1.schema1.table1 and select * from catalog2.schema2.table2 
>> are both valid statements within a single database. So, it is an 
>> extension of the naming to a level beyond the schema.
>>     
>
> PostgreSQL does not support such kind of qualification now.
> All we can do is something like "schema1.table1" in maximum.
>   
This common. Not many DBMS's support catalogs as we do. But, as I noted
before, it is part of the SQL standard.
>   
>> My assumption is that since the db_* objects within the selinux policy 
>> are to used by DBMS's in general, we should recognize (but not 
>> necessarily be subservient to) some standards, where the SQL standard 
>> seems relevant in this case. Others, such as ODBC/JDBC may also be 
>> relevant. Note that ODBC has support for objects named database, 
>> catalog, and schema. ODBC also has support for naming objects in queries 
>> as catalog.schema.table.
>>     
>
> Yes, I'm not a fundamentalist of SQL, but I think the selinux policy
> should not be designed for a specific DBMS as far as possible.
> The reason why I wondered for a new object class of catalogs is
> that it seems to me a synonym.
>   
For us it is definitely not a synonym. And, as I pointed out before,
your database is closer to an SQL cluster than an SQL catalog.
>   
>> So, based upon the above I would say that PostgreSQL's database object 
>> (as well as RUBIX's) is analogous to the cluster. I think database is a 
>> much more common term. Based upon the fact that SQL and ODBC (JDBC?) 
>> provide support for directly accessing DBMS objects (e.g., in a select 
>> statement) using the catalog and schema (but not database), I would 
>> still propose that both db_catalog and db_schema support are needed in 
>> SELinux. Obviously, the db_database also needs to be provided, as it is.
>>
>> From my rather limited understanding of SELinux I do not believe that 
>> is a technical problem with having an object class, such as db_catalog, 
>> that a particular DBMS does not use. Correct?
>>     
>
> At least, I don't oppose to db_catalog class as far as we can make
> clear the differences between databases, catalogs and schemas.
> In PostgreSQL, it does not have an idea of catalog as a namespace
> upper than schema, so we cannot handle these object obviously,
> even if it is defined in the security policy.
>
> I have still a question. Is there any functional differences between
> a catalog and a schema? If both of them works just a namespace, we
> can apply db_schema class and its permission on both of catalogs and
> schema.
> In other word, when we accesses /var/log/messages, we need to have
> privileges for /var and /var/log on dir class and /var/log/message
> on file class. The reason why dir class is applied both of /var
> and /var/log is these are same kind of object.
> (Perhaps, this suggestion might be a misdesign.)
>   
Actually, I think using one object class to represent both schemata and
catalogs is a possibility. As I said before, we currently use the dir
object class to represent both, and it provides all of the SELinux
function we require, at this time. However, I think it may produce a bit
of confusion for the user (to use dir), as to why we use what appears to
be an OS object class within the database. Also, it would seem a bit odd
and possibly confusing to use an object class named db_schema on a
catalog object, when the DBMS has distinct objects called schema and
catalog.

>From an SQL perspective, the general difference between a schema and a
catalog is that a catalog may only hold schemata. A schema may only hold
tables, views, etc. Also, according to the spec there should be an
Information Schema (which describes objects from all catalogs and
schemata) within each catalog. Though, we do not support this. There may
be other distinguishing factors, but I am not aware of them right now.
Note that a catalog may not hold catalogs and a schema may not hold
catalogs or schemata. So, in that sense there is a distinction between
them, where in your /var/log directory comparison there is no such
distinction. Both the /var and /var/log may each hold files and directories.

So, using one object class to represent both objects could create
confusion, in my opinion. Also, if in the future it becomes attractive
to have some distinct SELinux permission for catalogs and schemata, this
will not be an option if the same object class is chosen for both.

So, the bottom line for me is that I slightly would prefer having both
the db_catalog and db_schema object classes. If we have a single db
object class for both catalog and schema, I would suggest using some
generic name (e.g., db_dir) and not db_schema, to avoid confusion. I
more strongly prefer using one of the previous two options and have some
db_ class to cover the catalog and schema. Using the dir object class as
I have been seems a bit "hackish" to me. I would preface my opinion with
the fact that I know very little of the impact on the SELinux code of
having one extra object class or two extra object classes (or none).
> Thanks,
>
>   
>>>> In our selinux policy, we encourage users to partition the database 
>>>> space up by catalog, where each catalog is "owned" by an selinux domain.
>>>>     
>>>>         
>>> It is not correct design to port an idea of ownership in SELinux.
>>>
>>>   
>>>       
>>>> Rules are then setup so that domain may create schemata, tables, etc. 
>>>> under that catalog.
>>>>     
>>>>         
>>> The create permission should be checked on the newly created object
>>> itself. For example, when a table is created with a security context
>>> X_t, the client has to be allowed db_table:{create} on X_t.
>>>
>>>   
>>>       
>>>> It provides a MAC security partitioning by catalog 
>>>> subtree, and allows the user to be able to logically create their own 
>>>> DBMS schema subtree according to personal needs, such as one schema per 
>>>> linux logon user, protected using the DAC policy. Of course, other 
>>>> security architectures are possible. But, my point is that the catalog 
>>>> object allows us to the this in a nice, modular way. Where, if we only 
>>>> had the schema to work with this would not be possible.
>>>>     
>>>>         
>>> Is is not still possible, if you handle db_database class as the
>>> object class to represent the catalog in RUBIX?
>>>
>>> Thanks,
>>>
>>>   
>>>       
>>>>>   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,
>>>>>>>>         
>>>>>>>>             
>>>>>>>>                 
>>>>>   
>>>>>       
>>>>>           
>>>   
>>>       
>
>
>   

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

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

[Joshua Brindle]

Andy Warner wrote:
> 
> 
> KaiGai Kohei wrote:
>> 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
>>   
> I would suggest that the SQL catalog object should also be supported. 
> Though not common in implementation, it is part of the SQL spec. Our 
> DBMS (Trusted RUBIX) supports it, and for us it is basically another 
> level in the naming. (database.catalog.schema.table). I would suggest 
> that a db_catalog object be included with the same basic semantics as 
> the db_schema object.
> 

Is there more information available about how Trusted RUBIX uses SELinux? I see
on the webpage a brief mention of it but no detailed page like the other access
control models, nor in the security policy manager data sheet.

--
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: Some ideas in SE-PostgreSQL enhancement (Re: The status of SE-PostgreSQL)

[Andy Warner]

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



Joshua Brindle wrote:
> Andy Warner wrote:
>   
>> KaiGai Kohei wrote:
>>     
>>> 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
>>>   
>>>       
>> I would suggest that the SQL catalog object should also be supported. 
>> Though not common in implementation, it is part of the SQL spec. Our 
>> DBMS (Trusted RUBIX) supports it, and for us it is basically another 
>> level in the naming. (database.catalog.schema.table). I would suggest 
>> that a db_catalog object be included with the same basic semantics as 
>> the db_schema object.
>>
>>     
>
> Is there more information available about how Trusted RUBIX uses SELinux? I see
> on the webpage a brief mention of it but no detailed page like the other access
> control models, nor in the security policy manager data sheet.
>   

On our download page (http://rubix.com/cms/downloads) there is a pdf
called the Trusted RUBIX SELinux Guide.
Because our SELinux integration is very new we have not updated our
website to reflect it yet. The above Guide is the best source of how we
use SELinux. I can also answer any questions you have.

In general, I created a concept called an "object set" which may be
created with SELinux interfaces. An object set is all DBMS objects under
(and including) a named catalog object. An object set may include any
number of schemata, tables, views, etc. An admin may create an object
set and roles to administer the object set. They may also use provided
interfaces to give a domain restricted SQL access to the access set
(e.g., full sql, select only, insert, update, DDL, etc.). The intent was
to partition security domains by database subtree and provide easy
interfaces for them to create roles and control SQL access.

Our Security Policy Manager is a totally separate Attribute Based Access
Control policy mechanism, based upon XACML. It does interact with
SELinux a little but in general is orthogonal. The ABAC decisions may
optionally override SELinux or work to further refine the SELinux policy
decision. The SPM may also consult about an SELinux policy decision and
use it in its policy decision.
> --
> 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.
>
>   

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

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

[KaiGai Kohei]

Andy Warner wrote:
>>> So, based upon the above I would say that PostgreSQL's database object 
>>> (as well as RUBIX's) is analogous to the cluster. I think database is a 
>>> much more common term. Based upon the fact that SQL and ODBC (JDBC?) 
>>> provide support for directly accessing DBMS objects (e.g., in a select 
>>> statement) using the catalog and schema (but not database), I would 
>>> still propose that both db_catalog and db_schema support are needed in 
>>> SELinux. Obviously, the db_database also needs to be provided, as it is.
>>>
>>> From my rather limited understanding of SELinux I do not believe that 
>>> is a technical problem with having an object class, such as db_catalog, 
>>> that a particular DBMS does not use. Correct?
>>>     
>>
>> At least, I don't oppose to db_catalog class as far as we can make
>> clear the differences between databases, catalogs and schemas.
>> In PostgreSQL, it does not have an idea of catalog as a namespace
>> upper than schema, so we cannot handle these object obviously,
>> even if it is defined in the security policy.
>>
>> I have still a question. Is there any functional differences between
>> a catalog and a schema? If both of them works just a namespace, we
>> can apply db_schema class and its permission on both of catalogs and
>> schema.
>> In other word, when we accesses /var/log/messages, we need to have
>> privileges for /var and /var/log on dir class and /var/log/message
>> on file class. The reason why dir class is applied both of /var
>> and /var/log is these are same kind of object.
>> (Perhaps, this suggestion might be a misdesign.)
>>   
> Actually, I think using one object class to represent both schemata and 
> catalogs is a possibility. As I said before, we currently use the dir 
> object class to represent both, and it provides all of the SELinux 
> function we require, at this time. However, I think it may produce a bit 
> of confusion for the user (to use dir), as to why we use what appears to 
> be an OS object class within the database. Also, it would seem a bit odd 
> and possibly confusing to use an object class named db_schema on a 
> catalog object, when the DBMS has distinct objects called schema and 
> catalog.
> 
> From an SQL perspective, the general difference between a schema and a 
> catalog is that a catalog may only hold schemata. A schema may only hold 
> tables, views, etc. Also, according to the spec there should be an 
> Information Schema (which describes objects from all catalogs and 
> schemata) within each catalog. Though, we do not support this. There may 
> be other distinguishing factors, but I am not aware of them right now. 
> Note that a catalog may not hold catalogs and a schema may not hold 
> catalogs or schemata. So, in that sense there is a distinction between 
> them, where in your /var/log directory comparison there is no such 
> distinction. Both the /var and /var/log may each hold files and directories.
> 
> So, using one object class to represent both objects could create 
> confusion, in my opinion. Also, if in the future it becomes attractive 
> to have some distinct SELinux permission for catalogs and schemata, this 
> will not be an option if the same object class is chosen for both.
> 
> So, the bottom line for me is that I slightly would prefer having both 
> the db_catalog and db_schema object classes. If we have a single db 
> object class for both catalog and schema, I would suggest using some 
> generic name (e.g., db_dir) and not db_schema, to avoid confusion. I 
> more strongly prefer using one of the previous two options and have some 
> db_ class to cover the catalog and schema. Using the dir object class as 
> I have been seems a bit "hackish" to me. I would preface my opinion with 
> the fact that I know very little of the impact on the SELinux code of 
> having one extra object class or two extra object classes (or none).

OK, indeed, the namespaces in database (catalog and schema) has
a restriction about what kind of objects to be stored under them.
At least, I can agree the selinux policy have two new different
object classes, even if SE-PostgreSQL does not use db_catalog class.

I have one more point interested in. Could you make clear how does
the Trusted RUBIX assigns a security context on the newly created
database objects on the modified design?

We can obtain a security context for a new object using
security_compute_create() which provides us a result of TYPE_TRANSITION
rules, if configured.

In SE-PostgreSQL:
A new database object is labeled based only subject's context.

A new schema object will inherit the context of database, or be labeled
using TYPE_TRANSITION rules on db_schema class and the database.

A new table, procedure ans sequence will inherit the context of database,
or be labeled using TYPE_TRANSITION rules on its class and the schema.

A new column and tuple will inherit the context of table, or be labeled
using TYPE_TRANSITION rules on its class and the table.

A new largeobject is a headache for me. It does not belong to any schema.
Currently, it inherits the context of database, or be labeled using
TYPE_TRANSITION rules on its class and the database.
One considerable idea is to propose a facility to store largeobjects
under certain schema, but it is not an issue in SELinux.

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.

[PATCH] Expose avc_netlink_loop() for applications (Re: Some ideas in SE-PostgreSQL enhancement)

[KaiGai Kohei]

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

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

The attached patch expose the following libselinux interfaces:
 - avc_netlink_open()
 - avc_netlink_close()
 - avc_netlink_loop()
and adds a new callback function on receiving a netlink message.

It enables to simplifies the implementation of userspace object
managers which need to have its own avc and state monitoring process.

The existing standard avc becomes to use the new callbacks,
so here is a limitation we cannot use them concurrently,
but it is not a realistic situation.

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

[-- Attachment #2: libselinux-expose-netlink-loop.patch --]
[-- Type: text/x-patch, Size: 8339 bytes --]

The attached patch expose the following libselinux interfaces:
 - avc_netlink_open()
 - avc_netlink_close()
 - avc_netlink_loop()
and adds a new callback function on receiving a netlink message.

It enables to simplifies the implementation of userspace object
managers which need to have its own avc and state monitoring process.

 Signed-off-by: KaiGai Kohei <kaigai@ak.jp.nec.com>
--
 libselinux/include/selinux/avc.h     |   18 ++++++++++
 libselinux/include/selinux/selinux.h |    3 ++
 libselinux/src/avc_internal.c        |   58 ++++++++++++++++++++++++----------
 libselinux/src/avc_internal.h        |   16 ++++++---
 libselinux/src/callbacks.c           |   17 ++++++++++
 libselinux/src/callbacks.h           |    3 ++
 6 files changed, 92 insertions(+), 23 deletions(-)

diff --git a/libselinux/include/selinux/avc.h b/libselinux/include/selinux/avc.h
index 1ea25a2..419901d 100644
--- a/libselinux/include/selinux/avc.h
+++ b/libselinux/include/selinux/avc.h
@@ -428,6 +428,16 @@ void avc_av_stats(void);
 void avc_sid_stats(void);
 
 /**
+ * avc_netlink_open - Opens netlink socket
+ */
+int avc_netlink_open(int blocking);
+
+/**
+ * avc_netlink_close - Close netlink socket
+ */
+void avc_netlink_close(void);
+
+/**
  * avc_netlink_acquire_fd - Acquire netlink socket fd.
  *
  * Allows the application to manage messages from the netlink socket in
@@ -443,6 +453,14 @@ int avc_netlink_acquire_fd(void);
 void avc_netlink_release_fd(void);
 
 /**
+ * avc_netlink_loop - Handle netlink message forever
+ *
+ * Called by the application to process kernel netlink events.
+ * It need to set up a callback to handle netlink events.
+ */
+void avc_netlink_loop(void);
+
+/**
  * avc_netlink_check_nb - Check netlink socket for new messages.
  *
  * Called by the application when using avc_netlink_acquire_fd() to
diff --git a/libselinux/include/selinux/selinux.h b/libselinux/include/selinux/selinux.h
index fab083e..e385661 100644
--- a/libselinux/include/selinux/selinux.h
+++ b/libselinux/include/selinux/selinux.h
@@ -153,11 +153,14 @@ __attribute__ ((format(printf, 2, 3)))
 			   char *msgbuf, size_t msgbufsize);
 	/* validate the supplied context, modifying if necessary */
 	int (*func_validate) (security_context_t *ctx);
+	/* notification of netlink messages */
+	int (*func_netlink) (int type, int code);
 };
 
 #define SELINUX_CB_LOG		0
 #define SELINUX_CB_AUDIT	1
 #define SELINUX_CB_VALIDATE	2
+#define SELINUX_CB_NETLINK	3
 
 extern union selinux_callback selinux_get_callback(int type);
 extern void selinux_set_callback(int type, union selinux_callback cb);
diff --git a/libselinux/src/avc_internal.c b/libselinux/src/avc_internal.c
index 7d6f33d..7da0870 100644
--- a/libselinux/src/avc_internal.c
+++ b/libselinux/src/avc_internal.c
@@ -91,6 +91,42 @@ void avc_netlink_close(void)
 	close(fd);
 }
 
+int avc_netlink_callback(int type, int code)
+{
+	int rc;
+
+	switch (type) {
+	case SELNL_MSG_SETENFORCE:
+		if (avc_setenforce)
+			break;
+		avc_enforcing = code;
+		if (avc_enforcing && (rc = avc_ss_reset(0)) < 0) {
+			avc_log(SELINUX_ERROR,
+				"%s:  cache reset returned %d (errno %d)\n",
+				avc_prefix, rc, errno);
+			return rc;
+		}
+		break;
+
+	case SELNL_MSG_POLICYLOAD:
+		rc = avc_ss_reset(code);
+		if (rc < 0) {
+			avc_log(SELINUX_ERROR,
+				"%s:  cache reset returned %d (errno %d)\n",
+				avc_prefix, rc, errno);
+			return rc;
+		}
+		break;
+
+	default:
+		avc_log(SELINUX_WARNING,
+			"%s:  warning: unknown netlink message %d\n",
+			avc_prefix, type);
+	}
+
+	return 0;
+}
+
 static int avc_netlink_receive(char *buf, unsigned buflen)
 {
 	int rc;
@@ -159,15 +195,7 @@ static int avc_netlink_process(char *buf)
 		avc_log(SELINUX_INFO,
 			"%s:  received setenforce notice (enforcing=%d)\n",
 			avc_prefix, msg->val);
-		if (avc_setenforce)
-			break;
-		avc_enforcing = msg->val;
-		if (avc_enforcing && (rc = avc_ss_reset(0)) < 0) {
-			avc_log(SELINUX_ERROR,
-				"%s:  cache reset returned %d (errno %d)\n",
-				avc_prefix, rc, errno);
-			return rc;
-		}
+		rc = selinux_netlink(SELNL_MSG_SETENFORCE, msg->val);
 		break;
 	}
 
@@ -176,13 +204,7 @@ static int avc_netlink_process(char *buf)
 		avc_log(SELINUX_INFO,
 			"%s:  received policyload notice (seqno=%d)\n",
 			avc_prefix, msg->seqno);
-		rc = avc_ss_reset(msg->seqno);
-		if (rc < 0) {
-			avc_log(SELINUX_ERROR,
-				"%s:  cache reset returned %d (errno %d)\n",
-				avc_prefix, rc, errno);
-			return rc;
-		}
+		rc = selinux_netlink(SELNL_MSG_POLICYLOAD, msg->seqno);
 		break;
 	}
 
@@ -190,8 +212,10 @@ static int avc_netlink_process(char *buf)
 		avc_log(SELINUX_WARNING,
 			"%s:  warning: unknown netlink message %d\n",
 			avc_prefix, nlh->nlmsg_type);
+		rc = selinux_netlink(nlh->nlmsg_type, 0);
+		break;
 	}
-	return 0;
+	return rc;
 }
 
 int avc_netlink_check_nb(void)
diff --git a/libselinux/src/avc_internal.h b/libselinux/src/avc_internal.h
index 986ea7c..195ea53 100644
--- a/libselinux/src/avc_internal.h
+++ b/libselinux/src/avc_internal.h
@@ -12,6 +12,7 @@
 #include <stdio.h>
 #include <stdlib.h>
 #include <string.h>
+#include <selinux/selinux.h>
 #include <selinux/avc.h>
 #include "callbacks.h"
 #include "dso.h"
@@ -44,11 +45,17 @@ extern void (*avc_func_get_lock) (void *)hidden;
 extern void (*avc_func_release_lock) (void *)hidden;
 extern void (*avc_func_free_lock) (void *)hidden;
 
+/* netlink kernel message code */
+extern int avc_netlink_trouble hidden;
+extern int avc_netlink_callback(int type, int code) hidden;
+
 static inline void set_callbacks(const struct avc_memory_callback *mem_cb,
 				 const struct avc_log_callback *log_cb,
 				 const struct avc_thread_callback *thread_cb,
 				 const struct avc_lock_callback *lock_cb)
 {
+	union selinux_callback cb;
+
 	if (mem_cb) {
 		avc_func_malloc = mem_cb->func_malloc;
 		avc_func_free = mem_cb->func_free;
@@ -68,6 +75,9 @@ static inline void set_callbacks(const struct avc_memory_callback *mem_cb,
 		avc_func_release_lock = lock_cb->func_release_lock;
 		avc_func_free_lock = lock_cb->func_free_lock;
 	}
+	/* default behavior in standard AVC */
+	cb.func_netlink = avc_netlink_callback;
+	selinux_set_callback(SELINUX_CB_NETLINK, cb);
 }
 
 /* message prefix and enforcing mode*/
@@ -182,12 +192,6 @@ int avc_ss_set_auditdeny(security_id_t ssid, security_id_t tsid,
 			 security_class_t tclass, access_vector_t perms,
 			 uint32_t seqno, uint32_t enable) hidden;
 
-/* netlink kernel message code */
-extern int avc_netlink_trouble hidden;
-int avc_netlink_open(int blocking) hidden;
-void avc_netlink_loop(void) hidden;
-void avc_netlink_close(void) hidden;
-
 hidden_proto(avc_av_stats)
     hidden_proto(avc_cleanup)
     hidden_proto(avc_reset)
diff --git a/libselinux/src/callbacks.c b/libselinux/src/callbacks.c
index 5acfd3d..95526f3 100644
--- a/libselinux/src/callbacks.c
+++ b/libselinux/src/callbacks.c
@@ -37,6 +37,13 @@ default_selinux_validate(security_context_t *ctx)
 	return security_check_context(*ctx);
 }
 
+static int
+default_selinux_netlink(int type __attribute__((unused)),
+			int code __attribute__((unused)))
+{
+	return 0;
+}
+
 /* callback pointers */
 int __attribute__ ((format(printf, 2, 3)))
 (*selinux_log)(int, const char *, ...) =
@@ -50,6 +57,10 @@ int
 (*selinux_validate)(security_context_t *ctx) =
 	default_selinux_validate;
 
+int
+(*selinux_netlink) (int type, int code) =
+	default_selinux_netlink;
+
 /* callback setting function */
 void
 selinux_set_callback(int type, union selinux_callback cb)
@@ -64,6 +75,9 @@ selinux_set_callback(int type, union selinux_callback cb)
 	case SELINUX_CB_VALIDATE:
 		selinux_validate = cb.func_validate;
 		break;
+	case SELINUX_CB_NETLINK:
+		selinux_netlink = cb.func_netlink;
+		break;
 	}
 }
 
@@ -83,6 +97,9 @@ selinux_get_callback(int type)
 	case SELINUX_CB_VALIDATE:
 		cb.func_validate = selinux_validate;
 		break;
+	case SELINUX_CB_NETLINK:
+		cb.func_netlink = selinux_netlink;
+		break;
 	default:
 		memset(&cb, 0, sizeof(cb));
 		errno = EINVAL;
diff --git a/libselinux/src/callbacks.h b/libselinux/src/callbacks.h
index 068fa9d..bf12d77 100644
--- a/libselinux/src/callbacks.h
+++ b/libselinux/src/callbacks.h
@@ -21,4 +21,7 @@ extern int
 extern int
 (*selinux_validate)(security_context_t *ctx) hidden;
 
+extern int
+(*selinux_netlink) (int type, int code) hidden;
+
 #endif				/* _SELINUX_CALLBACKS_H_ */

[PATCH] database audit integration (Re: Some ideas in SE-PostgreSQL enhancement)

[KaiGai Kohei]

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

Hello,

I'm a developer of SE-PostgreSQL which is an enhancement of
database security using SELinux. It enables to apply the
security policy of the operating system on accesses to
database objects also.
It makes an access control decision and audit messages, but
these are not written out to system audit mechanism.

I believe our preferable behavior is the system audit collects
all the audit messages come from SELinux, not a logfile of
PostgreSQL.

Currently, the audit-libs has an interface to write a message
come from userspace avc, but some of parameter is not suitable
for the reference monitor in database management system.

This patch adds a new interface as follows:
    int audit_log_database_message(int audit_fd, int type,
                                   const char *message,
                                   const char *hostname,
                                   const char *addr,
                                   const char *dbuser);

It is differ from audit_log_user_avc_message() in the point of
a new parameter of dbuser, instead of tty and uid.
I don't think these are meaningful information for DBMS, but
we would like to record what database user invokes this audit
record.

Please any comments.

Thanks,

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

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

[-- Attachment #2: audit-libs-database-message.patch --]
[-- Type: text/x-patch, Size: 2783 bytes --]

 Signed-off-by: KaiGai Kohei <kaigai@ak.jp.nec.com>
--
 audit_logging.c |   57 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 libaudit.h      |    3 ++
 2 files changed, 60 insertions(+)

Index: audit/lib/libaudit.h
===================================================================
--- audit/lib/libaudit.h	(revision 267)
+++ audit/lib/libaudit.h	(working copy)
@@ -562,6 +562,9 @@
 	const char *old_seuser, const char *old_role, const char *old_range,
 	const char *host, const char *addr,
         const char *tty, int result);
+extern int audit_log_database_message(int audit_fd, int type,
+	const char *message, const char *hostname, const char *addr,
+	const char *dbuser);
 extern int audit_log_user_command(int audit_fd, int type, const char *command,
         const char *tty, int result);
 
Index: audit/lib/audit_logging.c
===================================================================
--- audit/lib/audit_logging.c	(revision 267)
+++ audit/lib/audit_logging.c	(working copy)
@@ -623,6 +623,63 @@
 
 /*
  * This function will log a message to the audit system using a predefined
+ * message format. This function should be used by database management system
+ * as a SELinux object managers.
+ *
+ * audit_fd - The fd returned by audit_open
+ * type - type of message, ex: AUDIT_USER_AVC
+ * message - the message being sent
+ * hostname - the hostname if known
+ * addr - The network address of the client
+ * dbuser - The name of database user
+ *
+ * It returns the sequence number which is > 0 on success or <= 0 on error.
+ */
+int audit_log_database_message(int audit_fd, int type, const char *message,
+			const char *hostname, const char *addr, const char *dbuser)
+{
+	char buf[MAX_AUDIT_MESSAGE_LENGTH];
+	char addrbuf[INET6_ADDRSTRLEN];
+	int retval;
+
+	if (audit_fd < 0)
+		return 0;
+
+	if (hostname && *hostname == '\0')
+		hostname = NULL;
+	addrbuf[0] = '\0';
+
+	if (addr == NULL || strlen(addr) == 0)
+		_resolve_addr(addrbuf, hostname);
+	else
+		strncat(addrbuf, addr, sizeof(addrbuf)-1);
+
+	if (dbuser && *dbuser == '\0')
+		dbuser = NULL;
+
+	snprintf(buf, sizeof(buf),
+		 "%s: (dbuser=%s, hostname=%s, addr=%s)",
+		 message,
+		 dbuser ? dbuser : "?",
+		 hostname ? hostname : "?",
+		 addr ? addr : "?");
+
+	errno = 0;
+	retval = audit_send_user_message(audit_fd, type, REAL_ERR, buf);
+	if (retval == -EPERM && getuid != 0) {
+		syslog(LOG_ERR, "Can't send to audit system: %s %s",
+		       audit_msg_type_to_name(type), buf);
+		return 0;
+	}
+
+	if ((retval < 1) && errno == 0)
+		errno = retval;
+
+	return retval;
+}
+
+/*
+ * This function will log a message to the audit system using a predefined
  * message format. This function should be used by all console apps that do
  * not manipulate accounts or groups.
  *

[PATCH] database audit integration (Re: Some ideas in SE-PostgreSQL enhancement)

[KaiGai Kohei]

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

Hello,

I'm a developer of SE-PostgreSQL which is an enhancement of
database security using SELinux. It enables to apply the
security policy of the operating system on accesses to
database objects also.
It makes an access control decision and audit messages, but
these are not written out to system audit mechanism.

I believe our preferable behavior is the system audit collects
all the audit messages come from SELinux, not a logfile of
PostgreSQL.

Currently, the audit-libs has an interface to write a message
come from userspace avc, but some of parameter is not suitable
for the reference monitor in database management system.

This patch adds a new interface as follows:
    int audit_log_database_message(int audit_fd, int type,
                                   const char *message,
                                   const char *hostname,
                                   const char *addr,
                                   const char *dbuser);

It is differ from audit_log_user_avc_message() in the point of
a new parameter of dbuser, instead of tty and uid.
I don't think these are meaningful information for DBMS, but
we would like to record what database user invokes this audit
record.

Please any comments.

Thanks,

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

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

[-- Attachment #2: audit-libs-database-message.patch --]
[-- Type: text/x-patch, Size: 2783 bytes --]

 Signed-off-by: KaiGai Kohei <kaigai@ak.jp.nec.com>
--
 audit_logging.c |   57 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 libaudit.h      |    3 ++
 2 files changed, 60 insertions(+)

Index: audit/lib/libaudit.h
===================================================================
--- audit/lib/libaudit.h	(revision 267)
+++ audit/lib/libaudit.h	(working copy)
@@ -562,6 +562,9 @@
 	const char *old_seuser, const char *old_role, const char *old_range,
 	const char *host, const char *addr,
         const char *tty, int result);
+extern int audit_log_database_message(int audit_fd, int type,
+	const char *message, const char *hostname, const char *addr,
+	const char *dbuser);
 extern int audit_log_user_command(int audit_fd, int type, const char *command,
         const char *tty, int result);
 
Index: audit/lib/audit_logging.c
===================================================================
--- audit/lib/audit_logging.c	(revision 267)
+++ audit/lib/audit_logging.c	(working copy)
@@ -623,6 +623,63 @@
 
 /*
  * This function will log a message to the audit system using a predefined
+ * message format. This function should be used by database management system
+ * as a SELinux object managers.
+ *
+ * audit_fd - The fd returned by audit_open
+ * type - type of message, ex: AUDIT_USER_AVC
+ * message - the message being sent
+ * hostname - the hostname if known
+ * addr - The network address of the client
+ * dbuser - The name of database user
+ *
+ * It returns the sequence number which is > 0 on success or <= 0 on error.
+ */
+int audit_log_database_message(int audit_fd, int type, const char *message,
+			const char *hostname, const char *addr, const char *dbuser)
+{
+	char buf[MAX_AUDIT_MESSAGE_LENGTH];
+	char addrbuf[INET6_ADDRSTRLEN];
+	int retval;
+
+	if (audit_fd < 0)
+		return 0;
+
+	if (hostname && *hostname == '\0')
+		hostname = NULL;
+	addrbuf[0] = '\0';
+
+	if (addr == NULL || strlen(addr) == 0)
+		_resolve_addr(addrbuf, hostname);
+	else
+		strncat(addrbuf, addr, sizeof(addrbuf)-1);
+
+	if (dbuser && *dbuser == '\0')
+		dbuser = NULL;
+
+	snprintf(buf, sizeof(buf),
+		 "%s: (dbuser=%s, hostname=%s, addr=%s)",
+		 message,
+		 dbuser ? dbuser : "?",
+		 hostname ? hostname : "?",
+		 addr ? addr : "?");
+
+	errno = 0;
+	retval = audit_send_user_message(audit_fd, type, REAL_ERR, buf);
+	if (retval == -EPERM && getuid != 0) {
+		syslog(LOG_ERR, "Can't send to audit system: %s %s",
+		       audit_msg_type_to_name(type), buf);
+		return 0;
+	}
+
+	if ((retval < 1) && errno == 0)
+		errno = retval;
+
+	return retval;
+}
+
+/*
+ * This function will log a message to the audit system using a predefined
  * message format. This function should be used by all console apps that do
  * not manipulate accounts or groups.
  *

[-- Attachment #3: Type: text/plain, Size: 0 bytes --]

[PATCH] Permissive domain in userspace (Re: Some ideas in SE-PostgreSQL enhancement)

[KaiGai Kohei]

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

KaiGai Kohei wrote:
> 4. Permissive domain in userspace
> 
> It is an issue got sleep for a few months.
>   http://marc.info/?l=selinux&m=122337314619667&w=2

It was discussed at the past a bit, but left it for several months.

Now we have a new idea of permissive domain which allows certain
domains to work as if being in permissive mode.
The in-kernel SELinux can handle it well, but userspace object
managers could not handler it because we don't have an interface
to tell what domain is permissive.

The attached patches are for the kernel and libselinux.

The kernel patch adds a flags field on av_decision, and returns
it as the sixth parameter on the reply of /selinux/access.

The libselinux patch enhance libselinux to understand it, and
two new interfaces are added.
 - security_compute_av_flags()
 - security_compute_av_flags_raw()
It also adds a new flags field on av_decision, but it is not
touched when we use the existing interfaces due to the binary
compatibility.

The standard userspace avc uses _flags interface, instead of
existing one, so it enables to control permissive domain.

IIRC, Eamon pointed out that it is preferable to put a new field
of 'permissive' than general purpose 'flags'. But it will require
interface changes, if we need more state in the future.
So, I don't change the implementation.

Please comment anything.

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

[-- Attachment #2: libselinux-userspace-permissive-domain.patch --]
[-- Type: text/x-patch, Size: 7687 bytes --]

 Signed-off-by: KaiGai Kohei <kaigai@ak.jp.nec.com>
--
 libselinux/include/selinux/selinux.h |   15 ++++++
 libselinux/src/avc.c                 |   22 +++++---
 libselinux/src/compute_av.c          |   90 ++++++++++++++++++++++++++++------
 libselinux/src/selinux_internal.h    |    2 +
 4 files changed, 105 insertions(+), 24 deletions(-)

diff --git a/libselinux/include/selinux/selinux.h b/libselinux/include/selinux/selinux.h
index fab083e..7030f38 100644
--- a/libselinux/include/selinux/selinux.h
+++ b/libselinux/include/selinux/selinux.h
@@ -130,8 +130,12 @@ struct av_decision {
 	access_vector_t auditallow;
 	access_vector_t auditdeny;
 	unsigned int seqno;
+	unsigned int flags;
 };
 
+/* Definitions of av_decision.flags */
+#define SELINUX_AVD_FLAGS_PERMISSIVE	0x0001
+
 /* Structure for passing options, used by AVC and label subsystems */
 struct selinux_opt {
 	int type;
@@ -180,6 +184,17 @@ extern int security_compute_av_raw(security_context_t scon,
 				   access_vector_t requested,
 				   struct av_decision *avd);
 
+extern int security_compute_av_flags(security_context_t scon,
+				     security_context_t tcon,
+				     security_class_t tclass,
+				     access_vector_t requested,
+				     struct av_decision *avd);
+extern int security_compute_av_flags_raw(security_context_t scon,
+					 security_context_t tcon,
+					 security_class_t tclass,
+					 access_vector_t requested,
+					 struct av_decision *avd);
+
 /* Compute a labeling decision and set *newcon to refer to it.
    Caller must free via freecon. */
 extern int security_compute_create(security_context_t scon,
diff --git a/libselinux/src/avc.c b/libselinux/src/avc.c
index 1545dd3..f0e2d33 100644
--- a/libselinux/src/avc.c
+++ b/libselinux/src/avc.c
@@ -849,9 +849,9 @@ int avc_has_perm_noaudit(security_id_t ssid,
 				rc = -1;
 				goto out;
 			}
-			rc = security_compute_av_raw(ssid->ctx, tsid->ctx,
-						     tclass, requested,
-						     &entry.avd);
+			rc = security_compute_av_flags_raw(ssid->ctx, tsid->ctx,
+							   tclass, requested,
+							   &entry.avd);
 			if (rc)
 				goto out;
 			rc = avc_insert(ssid, tsid, tclass, &entry, aeref);
@@ -867,11 +867,13 @@ int avc_has_perm_noaudit(security_id_t ssid,
 	denied = requested & ~(ae->avd.allowed);
 
 	if (!requested || denied) {
-		if (avc_enforcing) {
+		if (!avc_enforcing ||
+		    (ae->avd.flags & SELINUX_AVD_FLAGS_PERMISSIVE))
+			ae->avd.allowed |= requested;
+		else {
 			errno = EACCES;
 			rc = -1;
-		} else
-			ae->avd.allowed |= requested;
+		}
 	}
 
       out:
@@ -885,9 +887,11 @@ int avc_has_perm(security_id_t ssid, security_id_t tsid,
 		 security_class_t tclass, access_vector_t requested,
 		 struct avc_entry_ref *aeref, void *auditdata)
 {
-	struct av_decision avd = { 0, 0, 0, 0, 0 };
+	struct av_decision avd;
 	int errsave, rc;
 
+	memset(&avd, 0, sizeof(avd));
+
 	rc = avc_has_perm_noaudit(ssid, tsid, tclass, requested, aeref, &avd);
 	errsave = errno;
 	avc_audit(ssid, tsid, tclass, requested, &avd, rc, auditdata);
@@ -917,8 +921,8 @@ int avc_compute_create(security_id_t ssid,  security_id_t tsid,
 	rc = avc_lookup(ssid, tsid, tclass, 0, &aeref);
 	if (rc) {
 		/* need to make a cache entry for this tuple */
-		rc = security_compute_av_raw(ssid->ctx, tsid->ctx,
-					     tclass, 0, &entry.avd);
+		rc = security_compute_av_flags_raw(ssid->ctx, tsid->ctx,
+						   tclass, 0, &entry.avd);
 		if (rc)
 			goto out;
 		rc = avc_insert(ssid, tsid, tclass, &entry, &aeref);
diff --git a/libselinux/src/compute_av.c b/libselinux/src/compute_av.c
index 45cd0db..a821d17 100644
--- a/libselinux/src/compute_av.c
+++ b/libselinux/src/compute_av.c
@@ -10,10 +10,11 @@
 #include "policy.h"
 #include "mapping.h"
 
-int security_compute_av_raw(security_context_t scon,
-			    security_context_t tcon,
-			    security_class_t tclass,
-			    access_vector_t requested, struct av_decision *avd)
+int security_compute_av_flags_raw(security_context_t scon,
+				  security_context_t tcon,
+				  security_class_t tclass,
+				  access_vector_t requested,
+				  struct av_decision *avd)
 {
 	char path[PATH_MAX];
 	char *buf;
@@ -49,12 +50,15 @@ int security_compute_av_raw(security_context_t scon,
 	if (ret < 0)
 		goto out2;
 
-	if (sscanf(buf, "%x %x %x %x %u", &avd->allowed,
-		   &avd->decided, &avd->auditallow, &avd->auditdeny,
-		   &avd->seqno) != 5) {
+	ret = sscanf(buf, "%x %x %x %x %u %x",
+		     &avd->allowed, &avd->decided,
+		     &avd->auditallow, &avd->auditdeny,
+		     &avd->seqno, &avd->flags);
+	if (ret < 5) {
 		ret = -1;
 		goto out2;
-	}
+	} else if (ret < 6)
+		avd->flags = 0;
 
 	map_decision(tclass, avd);
 
@@ -66,16 +70,44 @@ int security_compute_av_raw(security_context_t scon,
 	return ret;
 }
 
-hidden_def(security_compute_av_raw)
+hidden_def(security_compute_av_flags_raw)
 
-int security_compute_av(security_context_t scon,
-			security_context_t tcon,
-			security_class_t tclass,
-			access_vector_t requested, struct av_decision *avd)
+int security_compute_av_raw(security_context_t scon,
+			    security_context_t tcon,
+			    security_class_t tclass,
+			    access_vector_t requested,
+			    struct av_decision *avd)
 {
+	struct av_decision lavd;
 	int ret;
+
+	ret = security_compute_av_flags_raw(scon, tcon, tclass,
+					    requested, &lavd);
+	if (ret == 0) {
+		avd->allowed = lavd.allowed;
+		avd->decided = lavd.decided;
+		avd->auditallow = lavd.auditallow;
+		avd->auditdeny = lavd.auditdeny;
+		avd->seqno = lavd.seqno;
+		/* NOTE:
+		 * We should not return avd->flags via the interface
+		 * due to the binary compatibility.
+		 */
+	}
+	return ret;
+}
+
+hidden_def(security_compute_av_raw)
+
+int security_compute_av_flags(security_context_t scon,
+			      security_context_t tcon,
+			      security_class_t tclass,
+			      access_vector_t requested,
+			      struct av_decision *avd)
+{
 	security_context_t rscon = scon;
 	security_context_t rtcon = tcon;
+	int ret;
 
 	if (selinux_trans_to_raw_context(scon, &rscon))
 		return -1;
@@ -83,8 +115,8 @@ int security_compute_av(security_context_t scon,
 		freecon(rscon);
 		return -1;
 	}
-
-	ret = security_compute_av_raw(rscon, rtcon, tclass, requested, avd);
+	ret = security_compute_av_flags_raw(rscon, rtcon, tclass,
+					    requested, avd);
 
 	freecon(rscon);
 	freecon(rtcon);
@@ -92,4 +124,32 @@ int security_compute_av(security_context_t scon,
 	return ret;
 }
 
+hidden_def(security_compute_av_flags)
+
+int security_compute_av(security_context_t scon,
+			security_context_t tcon,
+			security_class_t tclass,
+			access_vector_t requested, struct av_decision *avd)
+{
+	struct av_decision lavd;
+	int ret;
+
+	ret = security_compute_av_flags(scon, tcon, tclass,
+					requested, &lavd);
+	if (ret == 0)
+	{
+		avd->allowed = lavd.allowed;
+		avd->decided = lavd.decided;
+		avd->auditallow = lavd.auditallow;
+		avd->auditdeny = lavd.auditdeny;
+		avd->seqno = lavd.seqno;
+		/* NOTE:
+		 * We should not return avd->flags via the interface
+		 * due to the binary compatibility.
+		 */
+	}
+
+	return ret;
+}
+
 hidden_def(security_compute_av)
diff --git a/libselinux/src/selinux_internal.h b/libselinux/src/selinux_internal.h
index 8b4c6d4..cfb18a5 100644
--- a/libselinux/src/selinux_internal.h
+++ b/libselinux/src/selinux_internal.h
@@ -16,6 +16,8 @@ hidden_proto(selinux_mkload_policy)
     hidden_proto(security_canonicalize_context_raw)
     hidden_proto(security_compute_av)
     hidden_proto(security_compute_av_raw)
+    hidden_proto(security_compute_av_flags)
+    hidden_proto(security_compute_av_flags_raw)
     hidden_proto(security_compute_user)
     hidden_proto(security_compute_user_raw)
     hidden_proto(security_compute_create)

[-- Attachment #3: kernel-userspace-permissive-domain.patch --]
[-- Type: text/x-patch, Size: 3348 bytes --]

 Signed-off-by: KaiGai Kohei <kaigai@ak.jp.nec.com>
--
 security/selinux/avc.c              |    2 +-
 security/selinux/include/security.h |    4 +++-
 security/selinux/selinuxfs.c        |    4 ++--
 security/selinux/ss/services.c      |   30 +++++-------------------------
 4 files changed, 11 insertions(+), 29 deletions(-)

diff --git a/security/selinux/avc.c b/security/selinux/avc.c
index 7f9b5fa..b2ab608 100644
--- a/security/selinux/avc.c
+++ b/security/selinux/avc.c
@@ -927,7 +927,7 @@ int avc_has_perm_noaudit(u32 ssid, u32 tsid,
 	if (denied) {
 		if (flags & AVC_STRICT)
 			rc = -EACCES;
-		else if (!selinux_enforcing || security_permissive_sid(ssid))
+		else if (!selinux_enforcing || (avd->flags & AVD_FLAGS_PERMISSIVE))
 			avc_update_node(AVC_CALLBACK_GRANT, requested, ssid,
 					tsid, tclass, avd->seqno);
 		else
diff --git a/security/selinux/include/security.h b/security/selinux/include/security.h
index 5c3434f..a7be3f0 100644
--- a/security/selinux/include/security.h
+++ b/security/selinux/include/security.h
@@ -91,9 +91,11 @@ struct av_decision {
 	u32 auditallow;
 	u32 auditdeny;
 	u32 seqno;
+	u32 flags;
 };
 
-int security_permissive_sid(u32 sid);
+/* definitions of av_decision.flags */
+#define AVD_FLAGS_PERMISSIVE	0x0001
 
 int security_compute_av(u32 ssid, u32 tsid,
 	u16 tclass, u32 requested,
diff --git a/security/selinux/selinuxfs.c b/security/selinux/selinuxfs.c
index d3c8b98..4d56ab1 100644
--- a/security/selinux/selinuxfs.c
+++ b/security/selinux/selinuxfs.c
@@ -594,10 +594,10 @@ static ssize_t sel_write_access(struct file *file, char *buf, size_t size)
 		goto out2;
 
 	length = scnprintf(buf, SIMPLE_TRANSACTION_LIMIT,
-			  "%x %x %x %x %u",
+			  "%x %x %x %x %u %x",
 			  avd.allowed, 0xffffffff,
 			  avd.auditallow, avd.auditdeny,
-			  avd.seqno);
+			  avd.seqno, avd.flags);
 out2:
 	kfree(tcon);
 out:
diff --git a/security/selinux/ss/services.c b/security/selinux/ss/services.c
index deeec6c..500e6f7 100644
--- a/security/selinux/ss/services.c
+++ b/security/selinux/ss/services.c
@@ -410,6 +410,7 @@ static int context_struct_compute_av(struct context *scontext,
 	avd->auditallow = 0;
 	avd->auditdeny = 0xffffffff;
 	avd->seqno = latest_granting;
+	avd->flags = 0;
 
 	/*
 	 * Check for all the invalid cases.
@@ -528,31 +529,6 @@ inval_class:
 	return 0;
 }
 
-/*
- * Given a sid find if the type has the permissive flag set
- */
-int security_permissive_sid(u32 sid)
-{
-	struct context *context;
-	u32 type;
-	int rc;
-
-	read_lock(&policy_rwlock);
-
-	context = sidtab_search(&sidtab, sid);
-	BUG_ON(!context);
-
-	type = context->type;
-	/*
-	 * we are intentionally using type here, not type-1, the 0th bit may
-	 * someday indicate that we are globally setting permissive in policy.
-	 */
-	rc = ebitmap_get_bit(&policydb.permissive_map, type);
-
-	read_unlock(&policy_rwlock);
-	return rc;
-}
-
 static int security_validtrans_handle_fail(struct context *ocontext,
 					   struct context *ncontext,
 					   struct context *tcontext,
@@ -767,6 +743,10 @@ int security_compute_av(u32 ssid,
 
 	rc = context_struct_compute_av(scontext, tcontext, tclass,
 				       requested, avd);
+
+	/* permissive domain? */
+	if (ebitmap_get_bit(&policydb.permissive_map, scontext->type))
+	    avd->flags |= AVD_FLAGS_PERMISSIVE;
 out:
 	read_unlock(&policy_rwlock);
 	return rc;

Re: [PATCH] database audit integration (Re: Some ideas in SE-PostgreSQL enhancement)

[John Dennis]

KaiGai Kohei wrote:
> Hello,
>
> I'm a developer of SE-PostgreSQL which is an enhancement of
> database security using SELinux. It enables to apply the
> security policy of the operating system on accesses to
> database objects also.
> It makes an access control decision and audit messages, but
> these are not written out to system audit mechanism.
>
> I believe our preferable behavior is the system audit collects
> all the audit messages come from SELinux, not a logfile of
> PostgreSQL.
>
> Currently, the audit-libs has an interface to write a message
> come from userspace avc, but some of parameter is not suitable
> for the reference monitor in database management system.
>   
In the past it has been stated the kernel audit system is not
appropriate for general application logging because the kernel audit
system is not easily extensible and is not the place to log general
application data. While it is true the kernel audit system does allow
for some user level application logging by design and intention it is
constrained to select events deemed worthy of exception.

There is a new project called IPA (Identity, Policy, Audit) under
development. IPA v1 has been released, but the initial v1 release
focused only on the "I" part of IPA. In v2 we plan on filling out the
"P" and "A" parts. One of the things we're introducing for the Audit
component is a library called ELAPI (Event Logging API) which allows
applications to generate logging event data which is recursively
structured with key/value pairs (which can also be reformatted into
traditional strings). The library is capable of "dispatching" the
structured events to a variety of destination "sinks" (i.e. syslog,
file, IPA central logging repository, etc.). The destination sink
processing is accomplished with loadable plugin's so it should be easy
to to support any destination you want once you start utilizing the
ELAPI to log information. We had been planning on adding the kernel
audit system as a possible destination sink until the philosophy in the
above paragraph was pointed out to us.

ELAPI can be installed independent of IPA. I just went looking for
external documentation on ELAPI but it appears as though the ELAPI
documentation is only on a non-public wiki at the moment. I will try to
get that issue fixed shortly. ELAPI is still in development, although I
would say it's reaching the point of an alpha release.

Thus you may want to consider ELAPI for logging Secure Postgresql
messages and we would be interested in having you as a third party
review and exercise the library.

-- 
John Dennis <jdennis@redhat.com>

Looking to carve out IT costs?
www.redhat.com/carveoutcosts/

Re: [PATCH] Expose avc_netlink_loop() for applications (Re: Some ideas in SE-PostgreSQL enhancement)

[Eamon Walsh]

KaiGai Kohei wrote:
>> 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.
>>     
>
> The attached patch expose the following libselinux interfaces:
>  - avc_netlink_open()
>  - avc_netlink_close()
>  - avc_netlink_loop()
> and adds a new callback function on receiving a netlink message.
>
> It enables to simplifies the implementation of userspace object
> managers which need to have its own avc and state monitoring process.
>
> The existing standard avc becomes to use the new callbacks,
> so here is a limitation we cannot use them concurrently,
> but it is not a realistic situation.
>
> Thanks,
>   



The userspace AVC already has support for a callback function whenever
the cache is reset: AVC_CALLBACK_RESET.

Why don't you simply run the normal userspace AVC in the
sepgsqlStateMonitorMain() process, and register a callback function for
reset. Then all the netlink stuff is hidden from you.

The only thing necessary is then to add an additional callback function
AVC_CALLBACK_SETENFORCE to handle the other case.



-- 
Eamon Walsh <ewalsh@tycho.nsa.gov>
National Security Agency


--
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: [PATCH] Expose avc_netlink_loop() for applications (Re: Some ideas in SE-PostgreSQL enhancement)

[Eamon Walsh]

KaiGai Kohei wrote:
>> 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.
>>     
>
> The attached patch expose the following libselinux interfaces:
>  - avc_netlink_open()
>  - avc_netlink_close()
>  - avc_netlink_loop()
> and adds a new callback function on receiving a netlink message.
>
> It enables to simplifies the implementation of userspace object
> managers which need to have its own avc and state monitoring process.
>
> The existing standard avc becomes to use the new callbacks,
> so here is a limitation we cannot use them concurrently,
> but it is not a realistic situation.
>
> Thanks,
>   

Also note the new functions avc_netlink_acquire_fd(),
avc_netlink_release_fd(), and avc_netlink_check_nb() that you can use to
obtain the netlink file descriptor out and use it in a loop with select(2).

This means you don't have to use the threading callbacks to launch a
worker thread to listen on netlink.

All said, this would be pseudo-code for your worker process:



reset_callback() {
do_reset_stuff;
}

setenforce_callback() {
do_setenforce_stuff;
}

sepgsqlStateMonitorMain() {

avc_set_callback(AVC_CALLBACK_RESET, reset_callback);
avc_set_callback(AVC_CALLBACK_SETENFORCE, setenforce_callback);
avc_open();

fd = avc_netlink_acquire_fd();
while (true) {
select(fd);
avc_netlink_check_nb();
}
}


-- 
Eamon Walsh <ewalsh@tycho.nsa.gov>
National Security Agency


--
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: [PATCH] Expose avc_netlink_loop() for applications (Re: Some ideas in SE-PostgreSQL enhancement)

[KaiGai Kohei]

Eamon Walsh wrote:
> KaiGai Kohei wrote:
>>> 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.
>>>     
>> The attached patch expose the following libselinux interfaces:
>>  - avc_netlink_open()
>>  - avc_netlink_close()
>>  - avc_netlink_loop()
>> and adds a new callback function on receiving a netlink message.
>>
>> It enables to simplifies the implementation of userspace object
>> managers which need to have its own avc and state monitoring process.
>>
>> The existing standard avc becomes to use the new callbacks,
>> so here is a limitation we cannot use them concurrently,
>> but it is not a realistic situation.
>>
>> Thanks,
>>   
> 
> Also note the new functions avc_netlink_acquire_fd(),
> avc_netlink_release_fd(), and avc_netlink_check_nb() that you can use to
> obtain the netlink file descriptor out and use it in a loop with select(2).
> 
> This means you don't have to use the threading callbacks to launch a
> worker thread to listen on netlink.
> 
> All said, this would be pseudo-code for your worker process:

I have two minor and major concern with this approach.

The minor one is it consumes unnecessary memory due to avc_init().
Because of some reasons, SE-PostgreSQL implements its own userspace
AVC, so this region is purely waste of space.

The major one is we cannot handle them in a sindle lock section.
When the application is callbacked via AVC_CALLBACK_SETENFORCE,
it will change the state of enforcing/permissive, and it resets
its own avc on AVC_CALLBACK_RESET. But I would like to handle
these operations in a single lock section.

If we reset the avc on AVC_CALLBACK_SETENFORCE, it finally
resets the avc twice on a single message. It is also unconfortable.

The design of callbacks (via selinux_set_callback()) can be
considerable, but I don't think it is a good idea to hide
the netlink stuff here.

In my patch, it adds SELINUX_CB_NETLINK for any messages.
But, if it would be SELINUX_CB_SETENFORCE and SELINUX_CB_POLICYLOAD,
we don't need to refer any netlink related stuffs from applications.

What is your opinion?

Thanks,

> reset_callback() {
> do_reset_stuff;
> }
> 
> setenforce_callback() {
> do_setenforce_stuff;
> }
> 
> sepgsqlStateMonitorMain() {
> 
> avc_set_callback(AVC_CALLBACK_RESET, reset_callback);
> avc_set_callback(AVC_CALLBACK_SETENFORCE, setenforce_callback);
> avc_open();
> 
> fd = avc_netlink_acquire_fd();
> while (true) {
> select(fd);
> avc_netlink_check_nb();
> }
> }

-- 
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: [PATCH] database audit integration (Re: Some ideas in SE-PostgreSQL enhancement)

[KaiGai Kohei]

Matthew Booth wrote:
> KaiGai Kohei wrote:
>> Hello,
>>
>> I'm a developer of SE-PostgreSQL which is an enhancement of
>> database security using SELinux. It enables to apply the
>> security policy of the operating system on accesses to
>> database objects also.
>> It makes an access control decision and audit messages, but
>> these are not written out to system audit mechanism.
>>
>> I believe our preferable behavior is the system audit collects
>> all the audit messages come from SELinux, not a logfile of
>> PostgreSQL.
>>
>> Currently, the audit-libs has an interface to write a message
>> come from userspace avc, but some of parameter is not suitable
>> for the reference monitor in database management system.
>>
>> This patch adds a new interface as follows:
>>     int audit_log_database_message(int audit_fd, int type,
>>                                    const char *message,
>>                                    const char *hostname,
>>                                    const char *addr,
>>                                    const char *dbuser);
>>
>> It is differ from audit_log_user_avc_message() in the point of
>> a new parameter of dbuser, instead of tty and uid.
>> I don't think these are meaningful information for DBMS, but
>> we would like to record what database user invokes this audit
>> record.
> 
> A few points:
> 
> When I have tried to use this mechanism in the past I have found the
> existing proliferation of user messages types confusing. If possible,
> please don't add a new custom message to the library. Instead, maybe it
> would be better to recognise that there will be continue to be new and
> unanticipated uses for structured audit data, and provide an api which
> allows that to be expressed.

What I would like to audit is AUDIT_USER_AVC type message, not a new
custome message type. But the current interface does not allow to
record some of meaningful information.
So, it was necessary to propose a new audit_log_database_message().
Perhaps, it might be misnamed. If confusable, it is possible to rename
it something like audit_log_db_avc_message().

> While where may be no tty as such, the idea is still meaningful.
> Specifically, one of the first things an auditor will want to know is
> where the user who performed a particular action logged on from. If you
> have that information, you should include it in the audit record.

In this case, all the audit record has same tty which is used by
the server process, independent from the client who performed a
particular action. :(

> A concept of a session ID would probably have meaning in this context.
> If you have one, or can create one, please include it in all messages,
> including login messages.

When a database client connects to the server via TCP/IP, we don't have
any valid session id. In addition, the server does not have a method to
know what session id is used for the client logged in.

> Lastly, please no freeform text! It should be possible to determine
> everything relevant about an event without looking at freeform text.

Yes, the expected style is same as ones for audit_log_user_avc_message(),
without any freedom text. The most significant purpose is to allow users
to use utilities such as audit2allow.

> I look forward to playing with this :)

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.

Re: [PATCH] database audit integration (Re: Some ideas in SE-PostgreSQL enhancement)

[KaiGai Kohei]

Matthew Booth wrote:
> KaiGai Kohei wrote:
>> Hello,
>>
>> I'm a developer of SE-PostgreSQL which is an enhancement of
>> database security using SELinux. It enables to apply the
>> security policy of the operating system on accesses to
>> database objects also.
>> It makes an access control decision and audit messages, but
>> these are not written out to system audit mechanism.
>>
>> I believe our preferable behavior is the system audit collects
>> all the audit messages come from SELinux, not a logfile of
>> PostgreSQL.
>>
>> Currently, the audit-libs has an interface to write a message
>> come from userspace avc, but some of parameter is not suitable
>> for the reference monitor in database management system.
>>
>> This patch adds a new interface as follows:
>>     int audit_log_database_message(int audit_fd, int type,
>>                                    const char *message,
>>                                    const char *hostname,
>>                                    const char *addr,
>>                                    const char *dbuser);
>>
>> It is differ from audit_log_user_avc_message() in the point of
>> a new parameter of dbuser, instead of tty and uid.
>> I don't think these are meaningful information for DBMS, but
>> we would like to record what database user invokes this audit
>> record.
> 
> A few points:
> 
> When I have tried to use this mechanism in the past I have found the
> existing proliferation of user messages types confusing. If possible,
> please don't add a new custom message to the library. Instead, maybe it
> would be better to recognise that there will be continue to be new and
> unanticipated uses for structured audit data, and provide an api which
> allows that to be expressed.

What I would like to audit is AUDIT_USER_AVC type message, not a new
custome message type. But the current interface does not allow to
record some of meaningful information.
So, it was necessary to propose a new audit_log_database_message().
Perhaps, it might be misnamed. If confusable, it is possible to rename
it something like audit_log_db_avc_message().

> While where may be no tty as such, the idea is still meaningful.
> Specifically, one of the first things an auditor will want to know is
> where the user who performed a particular action logged on from. If you
> have that information, you should include it in the audit record.

In this case, all the audit record has same tty which is used by
the server process, independent from the client who performed a
particular action. :(

> A concept of a session ID would probably have meaning in this context.
> If you have one, or can create one, please include it in all messages,
> including login messages.

When a database client connects to the server via TCP/IP, we don't have
any valid session id. In addition, the server does not have a method to
know what session id is used for the client logged in.

> Lastly, please no freeform text! It should be possible to determine
> everything relevant about an event without looking at freeform text.

Yes, the expected style is same as ones for audit_log_user_avc_message(),
without any freedom text. The most significant purpose is to allow users
to use utilities such as audit2allow.

> I look forward to playing with this :)

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

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

[KaiGai Kohei]

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

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>

[-- Attachment #2: refpolicy-sepgsql-rework.1.patch --]
[-- Type: text/x-patch, Size: 17303 bytes --]

Index: policy/flask/security_classes
===================================================================
--- policy/flask/security_classes	(revision 2936)
+++ policy/flask/security_classes	(working copy)
@@ -119,4 +119,9 @@
 # kernel services that need to override task security, e.g. cachefiles
 class kernel_service 
 
+# More Database stuff
+class db_catalog		# userspace
+class db_schema			# userspace
+class db_sequence		# userspace
+
 # FLASK
Index: policy/flask/access_vectors
===================================================================
--- policy/flask/access_vectors	(revision 2936)
+++ 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
@@ -793,3 +789,27 @@
 	use_as_override
 	create_files_as	
 }
+
+# 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
+}
Index: policy/modules/kernel/kernel.if
===================================================================
--- policy/modules/kernel/kernel.if	(revision 2936)
+++ policy/modules/kernel/kernel.if	(working copy)
@@ -2563,18 +2563,22 @@
 	gen_require(`
 		type unlabeled_t;
 		class db_database { setattr relabelfrom };
+		class db_schema { setattr relabelfrom };
 		class db_table { setattr relabelfrom };
 		class db_procedure { setattr relabelfrom };
 		class db_column { setattr relabelfrom };
 		class db_tuple { update relabelfrom };
+		class db_sequence { setattr relabelfrom };
 		class db_blob { setattr relabelfrom };
 	')
 
 	allow $1 unlabeled_t:db_database { setattr relabelfrom };
+	allow $1 unlabeled_t:db_schema { setattr relabelfrom };
 	allow $1 unlabeled_t:db_table { setattr relabelfrom };
 	allow $1 unlabeled_t:db_procedure { setattr relabelfrom };
 	allow $1 unlabeled_t:db_column { setattr relabelfrom };
 	allow $1 unlabeled_t:db_tuple { update relabelfrom };
+	allow $1 unlabeled_t:db_sequence { setattr relabelfrom };
 	allow $1 unlabeled_t:db_blob { setattr relabelfrom };
 ')
 
Index: policy/modules/services/postgresql.if
===================================================================
--- policy/modules/services/postgresql.if	(revision 2936)
+++ policy/modules/services/postgresql.if	(working copy)
@@ -24,7 +24,9 @@
 		class db_tuple all_db_tuple_perms;
 		class db_blob all_db_blob_perms;
 
-		attribute sepgsql_client_type, sepgsql_database_type;
+		attribute sepgsql_client_type;
+		attribute sepgsql_database_type;
+		attribute sepgsql_schema_type;
 		attribute sepgsql_sysobj_table_type;
 
 		type sepgsql_trusted_proc_exec_t, sepgsql_trusted_proc_t;
@@ -45,26 +47,28 @@
 	# Client local policy
 	#
 
+	type_transition $2 sepgsql_schema_type:db_table user_sepgsql_table_t;
+	type_transition $2 sepgsql_sysobj_t:db_tuple user_sepgsql_sysobj_t;
+	type_transition $2 sepgsql_schema_type:db_procedure user_sepgsql_proc_exec_t;
+	type_transition $2 sepgsql_schema_type:db_sequence user_sepgsql_sequence_t;
+	type_transition $2 sepgsql_database_type:db_blob user_sepgsql_blob_t;
+
 	tunable_policy(`sepgsql_enable_users_ddl',`
-		allow $2 user_sepgsql_table_t:db_table { create drop };
-		type_transition $2 sepgsql_database_type:db_table user_sepgsql_table_t;
-
-		allow $2 user_sepgsql_table_t:db_column { create drop };
-
-		allow $2 user_sepgsql_sysobj_t:db_tuple { update insert delete };
-		type_transition $2 sepgsql_sysobj_table_type:db_tuple user_sepgsql_sysobj_t;
+		allow $2 user_sepgsql_table_t:db_table { create drop setattr };
+		allow $2 user_sepgsql_table_t:db_column { create drop setattr };
+		allow $2 user_sepgsql_proc_exec_t:db_procedure { create drop setattr };
+		allow $2 user_sepgsql_sequence_t:db_sequence { create drop setattr };
 	')
+	allow $2 user_sepgsql_table_t:db_table  { getattr select update insert delete };
+	allow $2 user_sepgsql_table_t:db_column { getattr select update insert };
+	allow $2 user_sepgsql_table_t:db_tuple	{ select update insert delete };
+	allow $2 user_sepgsql_sysobj_t:db_tuple	{ select update insert delete };
 
-	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_proc_exec_t:db_procedure { getattr execute };
 
-	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;
+	allow $2 user_sepgsql_sequence_t:db_sequence { getattr get_value set_value };
 
-	allow $2 user_sepgsql_blob_t:db_blob { create drop getattr setattr read write };
-	type_transition $2 sepgsql_database_type:db_blob user_sepgsql_blob_t;
+	allow $2 user_sepgsql_blob_t:db_blob { create drop getattr setattr read write import export };
 
 	allow $2 sepgsql_trusted_proc_t:process transition;
 	type_transition $2 sepgsql_trusted_proc_exec_t:process sepgsql_trusted_proc_t;
@@ -108,6 +112,24 @@
 
 ########################################
 ## <summary>
+##	Marks as a SE-PostgreSQL schema object type
+## </summary>
+## <param name="type">
+##	<summary>
+##	Type marked as a schema object type.
+##	</summary>
+## </param>
+#
+interface(`postgresql_schema_object',`
+	gen_require(`
+		attribute sepgsql_schema_type;
+	')
+
+	typeattribute $1 sepgsql_schema_type;
+')
+
+########################################
+## <summary>
 ##	Marks as a SE-PostgreSQL table/column/tuple object type
 ## </summary>
 ## <param name="type">
@@ -163,6 +185,24 @@
 
 ########################################
 ## <summary>
+##	Marks as a SE-PostgreSQL sequence object type
+## </summary>
+## <param name="type">
+##	<summary>
+##	Type marked as a sequence object type.
+##	</summary>
+## </param>
+#
+interface(`postgresql_sequence_object',`
+	gen_require(`
+		attribute sepgsql_sequence_type;
+	')
+
+	typeattribute $1 sepgsql_sequence_type;
+')
+
+########################################
+## <summary>
 ##	Marks as a SE-PostgreSQL binary large object type
 ## </summary>
 ## <param name="type">
@@ -319,14 +359,16 @@
 
 		attribute sepgsql_client_type;
 
-		type sepgsql_db_t, sepgsql_table_t, sepgsql_proc_t, sepgsql_blob_t;
+		type sepgsql_db_t, sepgsql_schema_t;
+		type sepgsql_table_t, sepgsql_proc_t, sepgsql_sequence_t, sepgsql_blob_t;
 		type sepgsql_trusted_proc_t, sepgsql_trusted_proc_exec_t;
 	')
 
 	typeattribute $1 sepgsql_client_type;
 
-	type_transition $1 sepgsql_db_t:db_table sepgsql_table_t;
-	type_transition $1 sepgsql_db_t:db_procedure sepgsql_proc_t;
+	type_transition $1 sepgsql_schema_t:db_table sepgsql_table_t;
+	type_transition $1 sepgsql_schema_t:db_procedure sepgsql_proc_t;
+	type_transition $1 sepgsql_schema_t:db_sequence sepgsql_sequence_t;
 	type_transition $1 sepgsql_db_t:db_blob sepgsql_blob_t;
 
 	type_transition $1 sepgsql_trusted_proc_exec_t:process sepgsql_trusted_proc_t;
@@ -346,8 +388,30 @@
 #
 interface(`postgresql_unconfined',`
 	gen_require(`
+		class db_database { superuser };
+
 		attribute sepgsql_unconfined_type;
 	')
 
 	typeattribute $1 sepgsql_unconfined_type;
+	allow $1 $1 : db_database superuser;
 ')
+
+########################################
+## <summary>
+##	Allow the specified domain unconfined accesses without superuser
+##	to any database objects managed by SE-PostgreSQL,
+## </summary>
+## <param name="domain">
+##	<summary>
+##	Domain allowed access.
+##	</summary>
+## </param>
+#
+interface(`postgresql_unconfined_without_superuser',`
+	gen_require(`
+		attribute sepgsql_unconfined_type;
+	')
+
+	typeattribute $1 sepgsql_unconfined_type;
+')
Index: policy/modules/services/postgresql.te
===================================================================
--- policy/modules/services/postgresql.te	(revision 2936)
+++ policy/modules/services/postgresql.te	(working copy)
@@ -1,12 +1,14 @@
 
-policy_module(postgresql, 1.8.3)
+policy_module(postgresql, 1.9.1)
 
 gen_require(`
 	class db_database all_db_database_perms;
+	class db_schema all_db_schema_perms;
 	class db_table all_db_table_perms;
 	class db_procedure all_db_procedure_perms;
 	class db_column all_db_column_perms;
 	class db_tuple all_db_tuple_perms;
+	class db_sequence all_db_sequence_perms;
 	class db_blob all_db_blob_perms;
 ')
 
@@ -50,9 +52,11 @@
 
 # database objects attribute
 attribute sepgsql_database_type;
+attribute sepgsql_schema_type;
 attribute sepgsql_table_type;
 attribute sepgsql_sysobj_table_type;
 attribute sepgsql_procedure_type;
+attribute sepgsql_sequence_type;
 attribute sepgsql_blob_type;
 attribute sepgsql_module_type;
 
@@ -75,12 +79,18 @@
 type sepgsql_ro_table_t;
 postgresql_table_object(sepgsql_ro_table_t)
 
+type sepgsql_schema_t;
+postgresql_schema_object(sepgsql_schema_t)
+
 type sepgsql_secret_blob_t;
 postgresql_blob_object(sepgsql_secret_blob_t)
 
 type sepgsql_secret_table_t;
 postgresql_table_object(sepgsql_secret_table_t)
 
+type sepgsql_sequence_t;
+postgresql_sequence_object(sepgsql_sequence_t)
+
 type sepgsql_sysobj_t;
 postgresql_system_table_object(sepgsql_sysobj_t)
 
@@ -93,7 +103,7 @@
 # Trusted Procedure Domain
 type sepgsql_trusted_proc_t;
 domain_type(sepgsql_trusted_proc_t)
-postgresql_unconfined(sepgsql_trusted_proc_t)
+postgresql_unconfined_without_superuser(sepgsql_trusted_proc_t)
 role system_r types sepgsql_trusted_proc_t;
 
 type user_sepgsql_blob_t;
@@ -106,6 +116,11 @@
 typealias user_sepgsql_proc_exec_t alias { auditadm_sepgsql_proc_exec_t secadm_sepgsql_proc_exec_t };
 postgresql_procedure_object(user_sepgsql_proc_exec_t)
 
+type user_sepgsql_sequence_t;
+typealias user_sepgsql_sequence_t alias { staff_sepgsql_sequence_t sysadm_sepgsql_sequence_t };
+typealias user_sepgsql_sequence_t alias { auditadm_sepgsql_sequence_t secadm_sepgsql_sequence_t };
+postgresql_sequence_object(user_sepgsql_sequence_t)
+
 type user_sepgsql_sysobj_t;
 typealias user_sepgsql_sysobj_t alias { staff_sepgsql_sysobj_t sysadm_sepgsql_sysobj_t };
 typealias user_sepgsql_sysobj_t alias { auditadm_sepgsql_sysobj_t secadm_sepgsql_sysobj_t };
@@ -135,16 +150,22 @@
 allow postgresql_t sepgsql_database_type:db_database *;
 type_transition postgresql_t postgresql_t:db_database sepgsql_db_t;
 
+allow postgresql_t sepgsql_schema_type:db_schema *;
+type_transition postgresql_t sepgsql_database_type:db_schema sepgsql_schema_t;
+
 allow postgresql_t sepgsql_module_type:db_database install_module;
 # Database/Loadable module
 allow sepgsql_database_type sepgsql_module_type:db_database load_module;
 
 allow postgresql_t sepgsql_table_type:{ db_table db_column db_tuple } *;
-type_transition postgresql_t sepgsql_database_type:db_table sepgsql_sysobj_t;
+type_transition postgresql_t sepgsql_schema_type:db_table sepgsql_sysobj_t;
 
 allow postgresql_t sepgsql_procedure_type:db_procedure *;
-type_transition postgresql_t sepgsql_database_type:db_procedure sepgsql_proc_t;
+type_transition postgresql_t sepgsql_schema_type:db_procedure sepgsql_proc_t;
 
+allow postgresql_t sepgsql_sequence_type:db_sequence *;
+type_transition postgresql_t sepgsql_schema_type:db_sequence sepgsql_sequence_t;
+
 allow postgresql_t sepgsql_blob_type:db_blob *;
 type_transition postgresql_t sepgsql_database_type:db_blob sepgsql_blob_t;
 
@@ -281,27 +302,30 @@
 # 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_schema_t:db_schema { search };
+type_transition sepgsql_client_type sepgsql_schema_type:db_schema sepgsql_schema_t;
 
-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_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_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_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 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 };
+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,9 +345,10 @@
 # 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_schema_t:db_schema { add_object remove_object };
 	allow sepgsql_client_type sepgsql_table_t:db_table { create drop setattr };
 	allow sepgsql_client_type sepgsql_table_t:db_column { create drop setattr };
 	allow sepgsql_client_type sepgsql_sysobj_t:db_tuple { update insert delete };
@@ -334,20 +359,29 @@
 # Unconfined access to this module
 #
 
-allow sepgsql_unconfined_type sepgsql_database_type:db_database *;
+allow sepgsql_unconfined_type sepgsql_database_type:db_database ~{ superuser };
 type_transition sepgsql_unconfined_type sepgsql_unconfined_type:db_database sepgsql_db_t;
 
-type_transition sepgsql_unconfined_type sepgsql_database_type:db_table sepgsql_table_t;
-type_transition sepgsql_unconfined_type sepgsql_database_type:db_procedure sepgsql_proc_t;
+allow sepgsql_unconfined_type sepgsql_schema_type:db_schema *;
+type_transition sepgsql_unconfined_type sepgsql_database_type:db_schema sepgsql_schema_t;
+
+type_transition sepgsql_unconfined_type sepgsql_schema_type:db_table sepgsql_table_t;
+type_transition sepgsql_unconfined_type sepgsql_schema_type:db_procedure sepgsql_proc_t;
+type_transition sepgsql_unconfined_type sepgsql_schema_type:db_sequence sepgsql_sequence_t;
 type_transition sepgsql_unconfined_type sepgsql_database_type:db_blob sepgsql_blob_t;
 
 allow sepgsql_unconfined_type sepgsql_table_type:{ db_table db_column db_tuple } *;
 
 # unconfined domain is not allowed to invoke user defined procedure directly.
 # They have to confirm and relabel it at first.
-allow sepgsql_unconfined_type { sepgsql_proc_t sepgsql_trusted_proc_t }:db_procedure *;
-allow sepgsql_unconfined_type sepgsql_procedure_type:db_procedure { create drop getattr setattr relabelfrom relabelto };
+# In addition, trusted procedure should not installed as system internal procedure,
+# because it can be implicitly invoked.
+allow sepgsql_unconfined_type sepgsql_proc_t:db_procedure *;
+allow sepgsql_unconfined_type sepgsql_trusted_proc_t:db_procedure ~{ install };
+allow sepgsql_unconfined_type sepgsql_procedure_type:db_procedure ~{ execute install };
 
+allow sepgsql_unconfined_type sepgsql_sequence_type:db_sequence *;
+
 allow sepgsql_unconfined_type sepgsql_blob_type:db_blob *;
 
 allow sepgsql_unconfined_type sepgsql_module_type:db_database install_module;

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

Re: [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@tycho.nsa.gov with
> the words "unsubscribe selinux" without quotes as the message.
> 


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

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

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

[Andy Warner]

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



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@tycho.nsa.gov with
>> the words "unsubscribe selinux" without quotes as the message.
>>
>>     
>
>
>   

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

[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 

Re: [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>

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

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

[Joshua Brindle]

Andy Warner wrote:
> 
> 
> Joshua Brindle wrote:
>> Andy Warner wrote:
>>   
>>> KaiGai Kohei wrote:
>>>     
>>>> 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
>>>>   
>>>>       
>>> I would suggest that the SQL catalog object should also be supported. 
>>> Though not common in implementation, it is part of the SQL spec. Our 
>>> DBMS (Trusted RUBIX) supports it, and for us it is basically another 
>>> level in the naming. (database.catalog.schema.table). I would suggest 
>>> that a db_catalog object be included with the same basic semantics as 
>>> the db_schema object.
>>>
>>>     
>>
>> Is there more information available about how Trusted RUBIX uses SELinux? I see
>> on the webpage a brief mention of it but no detailed page like the other access
>> control models, nor in the security policy manager data sheet.
>>   
> 
> On our download page (http://rubix.com/cms/downloads) there is a pdf 
> called the Trusted RUBIX SELinux Guide.
> Because our SELinux integration is very new we have not updated our 
> website to reflect it yet. The above Guide is the best source of how we 
> use SELinux. I can also answer any questions you have.
> 
> In general, I created a concept called an "object set" which may be 
> created with SELinux interfaces. An object set is all DBMS objects under 
> (and including) a named catalog object. An object set may include any 
> number of schemata, tables, views, etc. An admin may create an object 
> set and roles to administer the object set. They may also use provided 
> interfaces to give a domain restricted SQL access to the access set 
> (e.g., full sql, select only, insert, update, DDL, etc.). The intent was 
> to partition security domains by database subtree and provide easy 
> interfaces for them to create roles and control SQL access.
> 

I see now. When the db object classes were proposed we hoped they would be
general enough to cover other dbms's, it looks like we weren't far off. I have
some comments for permission sets found in the document mentioned above, for
example:

CREATE TABLE: db_database {access}; dir {search} on catalog; dir {search
add_name} on schema; db_table {create} on table

you require dir search, add_name. What is the source context in this case? Is
Trusted RUBIX doing avc_has_perm calls with dir as the object class on behalf of
the connected client or is the server masquerading as the client and those
checks are done by SELinux? I don't think it is a good idea to muddle the object
class ownership concept by doing checks for classes which are owned by another
object manager (except in the case that you are proxying access for that object
manager, such as the case for samba).

Were the db object classes incomplete for you so you needed to use filesystem
object classes? I'm trying to get a feeling for what the motivation was behind
these checks.

Is Trusted RUBIX with these SELinux checks actually released, are the access
checks set in stone? I'd like to see as much consistency between dbms object
models as possible so that policy won't be dramatically different between them.

--
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: Some ideas in SE-PostgreSQL enhancement (Re: The status of SE-PostgreSQL)

[Andy Warner]

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



Joshua Brindle wrote:
> Andy Warner wrote:
>   
>> Joshua Brindle wrote:
>>     
>>> Andy Warner wrote:
>>>   
>>>       
>>>> KaiGai Kohei wrote:
>>>>     
>>>>         
>>>>> 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
>>>>>   
>>>>>       
>>>>>           
>>>> I would suggest that the SQL catalog object should also be supported. 
>>>> Though not common in implementation, it is part of the SQL spec. Our 
>>>> DBMS (Trusted RUBIX) supports it, and for us it is basically another 
>>>> level in the naming. (database.catalog.schema.table). I would suggest 
>>>> that a db_catalog object be included with the same basic semantics as 
>>>> the db_schema object.
>>>>
>>>>     
>>>>         
>>> Is there more information available about how Trusted RUBIX uses SELinux? I see
>>> on the webpage a brief mention of it but no detailed page like the other access
>>> control models, nor in the security policy manager data sheet.
>>>   
>>>       
>> On our download page (http://rubix.com/cms/downloads) there is a pdf 
>> called the Trusted RUBIX SELinux Guide.
>> Because our SELinux integration is very new we have not updated our 
>> website to reflect it yet. The above Guide is the best source of how we 
>> use SELinux. I can also answer any questions you have.
>>
>> In general, I created a concept called an "object set" which may be 
>> created with SELinux interfaces. An object set is all DBMS objects under 
>> (and including) a named catalog object. An object set may include any 
>> number of schemata, tables, views, etc. An admin may create an object 
>> set and roles to administer the object set. They may also use provided 
>> interfaces to give a domain restricted SQL access to the access set 
>> (e.g., full sql, select only, insert, update, DDL, etc.). The intent was 
>> to partition security domains by database subtree and provide easy 
>> interfaces for them to create roles and control SQL access.
>>
>>     
>
> I see now. When the db object classes were proposed we hoped they would be
> general enough to cover other dbms's, it looks like we weren't far off. 

Other than omitting the catalog and schema object classes, which are SQL
standard objects (though sparsely used and poorly defined), I would agree.
> I have
> some comments for permission sets found in the document mentioned above, for
> example:
>
> CREATE TABLE: db_database {access}; dir {search} on catalog; dir {search
> add_name} on schema; db_table {create} on table
>
> you require dir search, add_name. What is the source context in this case? Is
> Trusted RUBIX doing avc_has_perm calls with dir as the object class on behalf of
> the connected client or is the server masquerading as the client and those
> checks are done by SELinux? I don't think it is a good idea to muddle the object
> class ownership concept by doing checks for classes which are owned by another
> object manager (except in the case that you are proxying access for that object
> manager, such as the case for samba).
>   
Trusted RUBIX does all security decision checks using avc_has_perm on
behalf of the connected client. We use the SELinux mechanism for access
control decisions and never for enforcement (I am speaking of only DBMS
objects). All DBMS object contexts are maintained internally in the
database. RUBIX enforces all decisions. Note that the schema is not an
OS directory, it is purely an internal DBMS object. I only used the dir
object class because there was no support for the DBMS schema or catalog
objects. I believe there will be support for this in the future, at
which time we would replace the use of the dir class with the db_schema
or db_catalog.

So, internally, the access checks on the database and catalog are
performed when those objects are opened. During the actual create table
operation we have two calls to avc_has_perm, the first checks the
client's context, schema's context for dir {search add_name} and the
second checks the client's context, table's context for db_table {create}

Could you elaborate on what you mean by "I don't think it is a good idea
to muddle the object
class ownership concept by doing checks for classes which are owned by
another
object manager" ? In what way is an object class *owned* by an object
manager? I'm a newbie in this area and would appreciate some
constructive criticism.

> Were the db object classes incomplete for you so you needed to use filesystem
> object classes? I'm trying to get a feeling for what the motivation was behind
> these checks.
>   
Yes, if the db object classes supported schema and catalog I would not
use the dir. I'm not sure what to say for motivation, other than I felt
it important and useful to have security checks on our catalog and
schemata. And, since these objects function very closely to an OS
directory, and there was no support for the catalog and schema objects
in the selinux policy, and I decided not to modify the targeted/mls
policies as part of our release, I chose to use the dir object class.
Actually, I think I got the idea from an old post on this newsgroup. The
options presented in that post were to either modify the policy's object
class and permissions or overload a pre-existing object class. I chose
the latter. It was the lesser of two evils. I didn't want to have to
keep up with updates to the targeted/mls policies.
> Is Trusted RUBIX with these SELinux checks actually released, are the access
> checks set in stone? I'd like to see as much consistency between dbms object
> models as possible so that policy won't be dramatically different between them.
>   
Yes, Trusted RUBIX with these security checks is released. But no, they
are not set in stone. The minute a new policy is released supporting the
db_schema and db_catalog object classes will be the time I change our
product to use them, and stop using the dir object class.

To my knowledge there are only two DBMS's that integrate SELinux into
its product, SEPostgresql and Trusted RUBIX. I'm not so sure I would say
our DBMS object models are dramatically different. SEPostgresql does not
have a catalog object and chose not to have selinux control over their
schema object. From looking at KaiGai's work and posts I think in the
future they will support the schema object, in much the same way I tried
to in our current release.

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

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

[Joshua Brindle]

Andy Warner wrote:
> 
>> I see now. When the db object classes were proposed we hoped they would be
>> general enough to cover other dbms's, it looks like we weren't far off. 
> 
> Other than omitting the catalog and schema object classes, which are SQL 
> standard objects (though sparsely used and poorly defined), I would agree.
>> I have
>> some comments for permission sets found in the document mentioned above, for
>> example:
>>
>> CREATE TABLE: db_database {access}; dir {search} on catalog; dir {search
>> add_name} on schema; db_table {create} on table
>>
>> you require dir search, add_name. What is the source context in this case? Is
>> Trusted RUBIX doing avc_has_perm calls with dir as the object class on behalf of
>> the connected client or is the server masquerading as the client and those
>> checks are done by SELinux? I don't think it is a good idea to muddle the object
>> class ownership concept by doing checks for classes which are owned by another
>> object manager (except in the case that you are proxying access for that object
>> manager, such as the case for samba).
>>   
> Trusted RUBIX does all security decision checks using avc_has_perm on 
> behalf of the connected client. We use the SELinux mechanism for access 
> control decisions and never for enforcement (I am speaking of only DBMS 
> objects). All DBMS object contexts are maintained internally in the 
> database. RUBIX enforces all decisions. Note that the schema is not an 
> OS directory, it is purely an internal DBMS object. I only used the dir 
> object class because there was no support for the DBMS schema or catalog 
> objects. I believe there will be support for this in the future, at 
> which time we would replace the use of the dir class with the db_schema 
> or db_catalog.

I'd have hoped our community was seen as open enough to approach about the added
object classes and perms.

> 
> So, internally, the access checks on the database and catalog are 
> performed when those objects are opened. During the actual create table 
> operation we have two calls to avc_has_perm, the first checks the 
> client's context, schema's context for dir {search add_name} and the 
> second checks the client's context, table's context for db_table {create}
> 
> Could you elaborate on what you mean by "I don't think it is a good idea 
> to muddle the object
> class ownership concept by doing checks for classes which are owned by 
> another
> object manager" ? In what way is an object class *owned* by an object 
> manager? I'm a newbie in this area and would appreciate some 
> constructive criticism.
> 

So, overloading object classes leads to confusion and other issues. For example,
if an actual directory got labeled what the internal catalog was labeled then
the client would have access to that, even if that wasn't the intention. There
also may be conflicting type_transition rules because you end up wanting one
object label transition to be different from another when used on the different
kinds of objects.

The flask architecture was originally implemented in a microkernel where object
managers were services that enforced access per the security servers decision.
In that architecture an object manager would be responsible for the object class
it was enforcing access on. Stephen can correct me here if I'm wrong but I
object to object class overloading based on these issues.

>> Were the db object classes incomplete for you so you needed to use filesystem
>> object classes? I'm trying to get a feeling for what the motivation was behind
>> these checks.
>>   
> Yes, if the db object classes supported schema and catalog I would not 
> use the dir. I'm not sure what to say for motivation, other than I felt 
> it important and useful to have security checks on our catalog and 
> schemata. And, since these objects function very closely to an OS 
> directory, and there was no support for the catalog and schema objects 
> in the selinux policy, and I decided not to modify the targeted/mls 
> policies as part of our release, I chose to use the dir object class. 
> Actually, I think I got the idea from an old post on this newsgroup. The 
> options presented in that post were to either modify the policy's object 
> class and permissions or overload a pre-existing object class. I chose 
> the latter. It was the lesser of two evils. I didn't  want to have to 
> keep up with updates to the targeted/mls policies.

See above, you brought up another issue here where permissions being overloaded
may not have the same read/write mappings and therefore may be difficult to work
around with respect to the MLS policy. Approaching the community to work on a
common set of object classes/perms and getting them merged in to upstream
refpolicy is definitely the right answer.

>> Is Trusted RUBIX with these SELinux checks actually released, are the access
>> checks set in stone? I'd like to see as much consistency between dbms object
>> models as possible so that policy won't be dramatically different between them.
>>   
> Yes, Trusted RUBIX with these security checks is released. But no, they 
> are not set in stone. The minute a new policy is released supporting the 
> db_schema and db_catalog object classes will be the time I change our 
> product to use them, and stop using the dir object class.
> 

Good. Hopefully we can get this worked out between you guys and have a
consistent (and documented) set of permissions that make it easy to write policy
that works on both systems (as much as possible)

> To my knowledge there are only two DBMS's that integrate SELinux into 
> its product, SEPostgresql and Trusted RUBIX. I'm not so sure I would say 
> our DBMS object models are dramatically different.  SEPostgresql does 
> not have a catalog object and chose not to have selinux control over 
> their schema object. From looking at KaiGai's work and posts I think in 
> the future they will support the schema object, in much the same way I 
> tried to in our current release.

They chose not to for now, the initial set of permissions used by SEPostgres
looks like it is going to be minimal, unfortunately, but should evolve into
something more comprehensive.

I may be missing it but do you support 'domain-like' type_transitions for stored
procedures? This was one of the more interesting features in the initial
sepostgres patches IMHO because it allowed for trusted stored procedures that
can read tables the client couldn't necessarily read, and could do operations on
them before handing over the data (eg., fuzzing of coordinates)

--
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: Some ideas in SE-PostgreSQL enhancement (Re: The status of SE-PostgreSQL)

[Andy Warner]

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



Joshua Brindle wrote:
> Andy Warner wrote:
>   
>>> I see now. When the db object classes were proposed we hoped they would be
>>> general enough to cover other dbms's, it looks like we weren't far off. 
>>>       
>> Other than omitting the catalog and schema object classes, which are SQL 
>> standard objects (though sparsely used and poorly defined), I would agree.
>>     
>>> I have
>>> some comments for permission sets found in the document mentioned above, for
>>> example:
>>>
>>> CREATE TABLE: db_database {access}; dir {search} on catalog; dir {search
>>> add_name} on schema; db_table {create} on table
>>>
>>> you require dir search, add_name. What is the source context in this case? Is
>>> Trusted RUBIX doing avc_has_perm calls with dir as the object class on behalf of
>>> the connected client or is the server masquerading as the client and those
>>> checks are done by SELinux? I don't think it is a good idea to muddle the object
>>> class ownership concept by doing checks for classes which are owned by another
>>> object manager (except in the case that you are proxying access for that object
>>> manager, such as the case for samba).
>>>   
>>>       
>> Trusted RUBIX does all security decision checks using avc_has_perm on 
>> behalf of the connected client. We use the SELinux mechanism for access 
>> control decisions and never for enforcement (I am speaking of only DBMS 
>> objects). All DBMS object contexts are maintained internally in the 
>> database. RUBIX enforces all decisions. Note that the schema is not an 
>> OS directory, it is purely an internal DBMS object. I only used the dir 
>> object class because there was no support for the DBMS schema or catalog 
>> objects. I believe there will be support for this in the future, at 
>> which time we would replace the use of the dir class with the db_schema 
>> or db_catalog.
>>     
>
> I'd have hoped our community was seen as open enough to approach about the added
> object classes and perms.
>   

Please don't take my lack of asking for new object classes as anything
other than ignorance as to how things "work" in the open source
community. All of our previous work has been on proprietary MLS systems.
The idea of asking an OS vendor or community to add features for my
needs was foreign to me. Plus, my time constraints on the project may
not have allowed it. I have found this community to be very open and
helpful and always planned to give some input as to the need for these
object classes after my project was finished (which is now).
>   
>> So, internally, the access checks on the database and catalog are 
>> performed when those objects are opened. During the actual create table 
>> operation we have two calls to avc_has_perm, the first checks the 
>> client's context, schema's context for dir {search add_name} and the 
>> second checks the client's context, table's context for db_table {create}
>>
>> Could you elaborate on what you mean by "I don't think it is a good idea 
>> to muddle the object
>> class ownership concept by doing checks for classes which are owned by 
>> another
>> object manager" ? In what way is an object class *owned* by an object 
>> manager? I'm a newbie in this area and would appreciate some 
>> constructive criticism.
>>
>>     
>
> So, overloading object classes leads to confusion and other issues. For example,
> if an actual directory got labeled what the internal catalog was labeled then
> the client would have access to that, even if that wasn't the intention. There
> also may be conflicting type_transition rules because you end up wanting one
> object label transition to be different from another when used on the different
> kinds of objects.
>   
Yep, I can see that as an issue. Practically speaking, I would think the
new object classes will be added before any such real issue arose. But,
isn't there a similar issue, say, between a system with a sepostres
policy and a Trusted RUBIX installation on the same platform? I have
already bumped up against some of the type_transition rules for sepostgres.
> The flask architecture was originally implemented in a microkernel where object
> managers were services that enforced access per the security servers decision.
> In that architecture an object manager would be responsible for the object class
> it was enforcing access on. Stephen can correct me here if I'm wrong but I
> object to object class overloading based on these issues.
>   

In your terminology, because rubix is enforcing the policy, would it be
considered an object manager? And, if so, wouldn't seposgres also be
considered one? where they both enforce access to the same set of object
classes?
>   
>>> Were the db object classes incomplete for you so you needed to use filesystem
>>> object classes? I'm trying to get a feeling for what the motivation was behind
>>> these checks.
>>>   
>>>       
>> Yes, if the db object classes supported schema and catalog I would not 
>> use the dir. I'm not sure what to say for motivation, other than I felt 
>> it important and useful to have security checks on our catalog and 
>> schemata. And, since these objects function very closely to an OS 
>> directory, and there was no support for the catalog and schema objects 
>> in the selinux policy, and I decided not to modify the targeted/mls 
>> policies as part of our release, I chose to use the dir object class. 
>> Actually, I think I got the idea from an old post on this newsgroup. The 
>> options presented in that post were to either modify the policy's object 
>> class and permissions or overload a pre-existing object class. I chose 
>> the latter. It was the lesser of two evils. I didn't  want to have to 
>> keep up with updates to the targeted/mls policies.
>>     
>
> See above, you brought up another issue here where permissions being overloaded
> may not have the same read/write mappings and therefore may be difficult to work
> around with respect to the MLS policy. Approaching the community to work on a
> common set of object classes/perms and getting them merged in to upstream
> refpolicy is definitely the right answer.
>   
I agree completely.
>   
>>> Is Trusted RUBIX with these SELinux checks actually released, are the access
>>> checks set in stone? I'd like to see as much consistency between dbms object
>>> models as possible so that policy won't be dramatically different between them.
>>>   
>>>       
>> Yes, Trusted RUBIX with these security checks is released. But no, they 
>> are not set in stone. The minute a new policy is released supporting the 
>> db_schema and db_catalog object classes will be the time I change our 
>> product to use them, and stop using the dir object class.
>>
>>     
>
> Good. Hopefully we can get this worked out between you guys and have a
> consistent (and documented) set of permissions that make it easy to write policy
> that works on both systems (as much as possible)
>   
I think that is well on its way. One question out of curiosity. Would
you anticipate that I should or would use the seposgres TE rules that
already exist in the targeted/mls policy? I ask that from your comment
about writing policy that that works on both systems. With current state
of things this seems very difficult, though, I think a higher level
interface set, like the one we created for the object set, could be made
that, for the most part, worked for both systems.
>   
>> To my knowledge there are only two DBMS's that integrate SELinux into 
>> its product, SEPostgresql and Trusted RUBIX. I'm not so sure I would say 
>> our DBMS object models are dramatically different.  SEPostgresql does 
>> not have a catalog object and chose not to have selinux control over 
>> their schema object. From looking at KaiGai's work and posts I think in 
>> the future they will support the schema object, in much the same way I 
>> tried to in our current release.
>>     
>
> They chose not to for now, the initial set of permissions used by SEPostgres
> looks like it is going to be minimal, unfortunately, but should evolve into
> something more comprehensive.
>
> I may be missing it but do you support 'domain-like' type_transitions for stored
> procedures? This was one of the more interesting features in the initial
> sepostgres patches IMHO because it allowed for trusted stored procedures that
> can read tables the client couldn't necessarily read, and could do operations on
> them before handing over the data (eg., fuzzing of coordinates)
>   
We do not implement stored procedures at all, though this is a near
future possibility. As I said before, our background is MLS and often in
the EAL-5+ type (old B3). The group-think was always that stored
procedures were too insecure for such assurance levels. But, I have been
pushing the possibility in a EAL-4 type mode, for exactly the reasons
you mentioned above. With the selinux domain transition concept a stored
procedure becomes very interesting.
> --
> 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.
>
>   

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

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

[Joshua Brindle]

Andy Warner wrote:
> 
> 
> Please don't take my lack of asking for new object classes as anything 
> other than ignorance as to how things "work" in the open source 
> community. All of our previous work has been on proprietary MLS systems. 
> The idea of asking an OS vendor or community to add features for my 
> needs was foreign to me. Plus, my time constraints on the project may 
> not have allowed it. I have found this community to be very open and 
> helpful and always planned to give some input as to the need for these 
> object classes after my project was finished (which is now).
>>   

Fair enough. I'm happy to see additional efforts in this arena, regardless.

>>> So, internally, the access checks on the database and catalog are 
>>> performed when those objects are opened. During the actual create table 
>>> operation we have two calls to avc_has_perm, the first checks the 
>>> client's context, schema's context for dir {search add_name} and the 
>>> second checks the client's context, table's context for db_table {create}
>>>
>>> Could you elaborate on what you mean by "I don't think it is a good idea 
>>> to muddle the object
>>> class ownership concept by doing checks for classes which are owned by 
>>> another
>>> object manager" ? In what way is an object class *owned* by an object 
>>> manager? I'm a newbie in this area and would appreciate some 
>>> constructive criticism.
>>>
>>>     
>>
>> So, overloading object classes leads to confusion and other issues. For example,
>> if an actual directory got labeled what the internal catalog was labeled then
>> the client would have access to that, even if that wasn't the intention. There
>> also may be conflicting type_transition rules because you end up wanting one
>> object label transition to be different from another when used on the different
>> kinds of objects.
>>   
> Yep, I can see that as an issue. Practically speaking, I would think the 
> new object classes will be added before any such real issue arose. But, 
> isn't there a similar issue, say, between a system with a sepostres 
> policy and a Trusted RUBIX installation on the same platform? I have 
> already bumped up against some of the type_transition rules for sepostgres.
>> The flask architecture was originally implemented in a microkernel where object
>> managers were services that enforced access per the security servers decision.
>> In that architecture an object manager would be responsible for the object class
>> it was enforcing access on. Stephen can correct me here if I'm wrong but I
>> object to object class overloading based on these issues.
>>   
> 

You shouldn't really bump in to each other since the dbms domain and objects
should all be labeled differently, what have you seen happen?

> In your terminology, because rubix is enforcing the policy, would it be 
> considered an object manager? And, if so, wouldn't seposgres also be 
> considered one? where they both enforce access to the same set of object 
> classes?

Yes, both rubix and sepostgres are object managers. abstract object classes
where there isn't a single owner are interesting, I'd expect different object
labeling in most cases so it doesn't matter. In the case of the data in both
being equivalent from a security POV maybe it actually does make sense for them
to share labels and object classes (especially true if the database is primarily
enforcing an MLS policy)

>>   
>>>> Were the db object classes incomplete for you so you needed to use filesystem
>>>> object classes? I'm trying to get a feeling for what the motivation was behind
>>>> these checks.
>>>>   
>>>>       
>>> Yes, if the db object classes supported schema and catalog I would not 
>>> use the dir. I'm not sure what to say for motivation, other than I felt 
>>> it important and useful to have security checks on our catalog and 
>>> schemata. And, since these objects function very closely to an OS 
>>> directory, and there was no support for the catalog and schema objects 
>>> in the selinux policy, and I decided not to modify the targeted/mls 
>>> policies as part of our release, I chose to use the dir object class. 
>>> Actually, I think I got the idea from an old post on this newsgroup. The 
>>> options presented in that post were to either modify the policy's object 
>>> class and permissions or overload a pre-existing object class. I chose 
>>> the latter. It was the lesser of two evils. I didn't  want to have to 
>>> keep up with updates to the targeted/mls policies.
>>>     
>>
>> See above, you brought up another issue here where permissions being overloaded
>> may not have the same read/write mappings and therefore may be difficult to work
>> around with respect to the MLS policy. Approaching the community to work on a
>> common set of object classes/perms and getting them merged in to upstream
>> refpolicy is definitely the right answer.
>>   
> I agree completely.
>>   
>>>> Is Trusted RUBIX with these SELinux checks actually released, are the access
>>>> checks set in stone? I'd like to see as much consistency between dbms object
>>>> models as possible so that policy won't be dramatically different between them.
>>>>   
>>>>       
>>> Yes, Trusted RUBIX with these security checks is released. But no, they 
>>> are not set in stone. The minute a new policy is released supporting the 
>>> db_schema and db_catalog object classes will be the time I change our 
>>> product to use them, and stop using the dir object class.
>>>
>>>     
>>
>> Good. Hopefully we can get this worked out between you guys and have a
>> consistent (and documented) set of permissions that make it easy to write policy
>> that works on both systems (as much as possible)
>>   
> I think that is well on its way. One question out of curiosity. Would 
> you anticipate that I should or would use the seposgres TE rules that 
> already exist in the targeted/mls policy? I ask that from your comment 
> about writing policy that that works on both systems. With current state 
> of things this seems very difficult, though, I think a higher level 
> interface set, like the one we created for the object set, could be made 
> that, for the most part, worked for both systems.
>>   

Yes, I don't mean they'd be using an identical policy but shared
templates/interfaces that worked with both would certainly make it easier to
target both systems without really needing to know the intricacies of each
systems enforcement.

>>> To my knowledge there are only two DBMS's that integrate SELinux into 
>>> its product, SEPostgresql and Trusted RUBIX. I'm not so sure I would say 
>>> our DBMS object models are dramatically different.  SEPostgresql does 
>>> not have a catalog object and chose not to have selinux control over 
>>> their schema object. From looking at KaiGai's work and posts I think in 
>>> the future they will support the schema object, in much the same way I 
>>> tried to in our current release.
>>>     
>>
>> They chose not to for now, the initial set of permissions used by SEPostgres
>> looks like it is going to be minimal, unfortunately, but should evolve into
>> something more comprehensive.
>>
>> I may be missing it but do you support 'domain-like' type_transitions for stored
>> procedures? This was one of the more interesting features in the initial
>> sepostgres patches IMHO because it allowed for trusted stored procedures that
>> can read tables the client couldn't necessarily read, and could do operations on
>> them before handing over the data (eg., fuzzing of coordinates)
>>   
> We do not implement stored procedures at all, though this is a near 
> future possibility. As I said before, our background is MLS and often in 
> the EAL-5+ type (old B3). The group-think was always that stored 
> procedures were too insecure for such assurance levels. But, I have been 
> pushing the possibility in a EAL-4 type mode, for exactly the reasons 
> you mentioned above. With the selinux domain transition concept a stored 
> procedure becomes very interesting.
>> --


--
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: Some ideas in SE-PostgreSQL enhancement (Re: The status of SE-PostgreSQL)

[Andy Warner]

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



Joshua Brindle wrote:
> Andy Warner wrote:
>   
>> Please don't take my lack of asking for new object classes as anything 
>> other than ignorance as to how things "work" in the open source 
>> community. All of our previous work has been on proprietary MLS systems. 
>> The idea of asking an OS vendor or community to add features for my 
>> needs was foreign to me. Plus, my time constraints on the project may 
>> not have allowed it. I have found this community to be very open and 
>> helpful and always planned to give some input as to the need for these 
>> object classes after my project was finished (which is now).
>>     
>>>   
>>>       
>
> Fair enough. I'm happy to see additional efforts in this arena, regardless.
>
>   
>>>> So, internally, the access checks on the database and catalog are 
>>>> performed when those objects are opened. During the actual create table 
>>>> operation we have two calls to avc_has_perm, the first checks the 
>>>> client's context, schema's context for dir {search add_name} and the 
>>>> second checks the client's context, table's context for db_table {create}
>>>>
>>>> Could you elaborate on what you mean by "I don't think it is a good idea 
>>>> to muddle the object
>>>> class ownership concept by doing checks for classes which are owned by 
>>>> another
>>>> object manager" ? In what way is an object class *owned* by an object 
>>>> manager? I'm a newbie in this area and would appreciate some 
>>>> constructive criticism.
>>>>
>>>>     
>>>>         
>>> So, overloading object classes leads to confusion and other issues. For example,
>>> if an actual directory got labeled what the internal catalog was labeled then
>>> the client would have access to that, even if that wasn't the intention. There
>>> also may be conflicting type_transition rules because you end up wanting one
>>> object label transition to be different from another when used on the different
>>> kinds of objects.
>>>   
>>>       
>> Yep, I can see that as an issue. Practically speaking, I would think the 
>> new object classes will be added before any such real issue arose. But, 
>> isn't there a similar issue, say, between a system with a sepostres 
>> policy and a Trusted RUBIX installation on the same platform? I have 
>> already bumped up against some of the type_transition rules for sepostgres.
>>     
>>> The flask architecture was originally implemented in a microkernel where object
>>> managers were services that enforced access per the security servers decision.
>>> In that architecture an object manager would be responsible for the object class
>>> it was enforcing access on. Stephen can correct me here if I'm wrong but I
>>> object to object class overloading based on these issues.
>>>   
>>>       
>
> You shouldn't really bump in to each other since the dbms domain and objects
> should all be labeled differently, what have you seen happen?
>   
KaiGai and I talked about this a bit already, and I'll preface my
response by saying that my memory of it is poor. Also, this issue was
one of my first practical introductions to selinux, so I'm sure I was
shooting in the dark. But, the main issue revolved around the type
transition rule for the database object. It seems to me, what makes it
special is that it has no parent object. It seems equivalent to writing
a type transition rule for creating the OS root directory, except in our
DBMS case we can have more than one type (each dbms has their own).

A rule for sepostgres is:

type_transition sepgsql_client_type sepgsql_client_type : db_database
sepgsql_db_t;

Where I believe the standard user_t and such had the sepgsql_client_type
attribute. So, with that rule in place I think it was impossible for
rubix to have a similar rule, if our client_type's overlapped. Which
seems likely, as the user_t is a likely candidate for a client. For
instance, if I did this:

type_transition rubix_client_type rubix_client_type : db_database
rubix_db_t; (where rubix_client_type contained user_t)

I think it would not compile because its ambiguous, right? So, what I
did was write a rule like this:

type_transition rubix_client_type rubix_t : db_database rubix_db_t;

and hard-coded the rubix_t into the avc_compute_create call. The rubix_t
is actually the type of our server process. Prior to doing that, I could
not find a way to not have a database be created with a sepgsql_t type.

I see (now) that the reference policy also has the rule:

type_transition postgresql_t postgresql_t : db_database sepgsql_db_t;

Obviously, the above would never conflict with another dbms's rules. If
that single type transition rule satisfied all of seposgresql's needs,
then that would eliminate the need for the conflicting rule. Though, I
assume thats dependent on the internals of seposgresql.
>   
>> In your terminology, because rubix is enforcing the policy, would it be 
>> considered an object manager? And, if so, wouldn't seposgres also be 
>> considered one? where they both enforce access to the same set of object 
>> classes?
>>     
>
> Yes, both rubix and sepostgres are object managers. abstract object classes
> where there isn't a single owner are interesting, I'd expect different object
> labeling in most cases so it doesn't matter. In the case of the data in both
> being equivalent from a security POV maybe it actually does make sense for them
> to share labels and object classes (especially true if the database is primarily
> enforcing an MLS policy)
>
>   
>>>   
>>>       
>>>>> Were the db object classes incomplete for you so you needed to use filesystem
>>>>> object classes? I'm trying to get a feeling for what the motivation was behind
>>>>> these checks.
>>>>>   
>>>>>       
>>>>>           
>>>> Yes, if the db object classes supported schema and catalog I would not 
>>>> use the dir. I'm not sure what to say for motivation, other than I felt 
>>>> it important and useful to have security checks on our catalog and 
>>>> schemata. And, since these objects function very closely to an OS 
>>>> directory, and there was no support for the catalog and schema objects 
>>>> in the selinux policy, and I decided not to modify the targeted/mls 
>>>> policies as part of our release, I chose to use the dir object class. 
>>>> Actually, I think I got the idea from an old post on this newsgroup. The 
>>>> options presented in that post were to either modify the policy's object 
>>>> class and permissions or overload a pre-existing object class. I chose 
>>>> the latter. It was the lesser of two evils. I didn't  want to have to 
>>>> keep up with updates to the targeted/mls policies.
>>>>     
>>>>         
>>> See above, you brought up another issue here where permissions being overloaded
>>> may not have the same read/write mappings and therefore may be difficult to work
>>> around with respect to the MLS policy. Approaching the community to work on a
>>> common set of object classes/perms and getting them merged in to upstream
>>> refpolicy is definitely the right answer.
>>>   
>>>       
>> I agree completely.
>>     
>>>   
>>>       
>>>>> Is Trusted RUBIX with these SELinux checks actually released, are the access
>>>>> checks set in stone? I'd like to see as much consistency between dbms object
>>>>> models as possible so that policy won't be dramatically different between them.
>>>>>   
>>>>>       
>>>>>           
>>>> Yes, Trusted RUBIX with these security checks is released. But no, they 
>>>> are not set in stone. The minute a new policy is released supporting the 
>>>> db_schema and db_catalog object classes will be the time I change our 
>>>> product to use them, and stop using the dir object class.
>>>>
>>>>     
>>>>         
>>> Good. Hopefully we can get this worked out between you guys and have a
>>> consistent (and documented) set of permissions that make it easy to write policy
>>> that works on both systems (as much as possible)
>>>   
>>>       
>> I think that is well on its way. One question out of curiosity. Would 
>> you anticipate that I should or would use the seposgres TE rules that 
>> already exist in the targeted/mls policy? I ask that from your comment 
>> about writing policy that that works on both systems. With current state 
>> of things this seems very difficult, though, I think a higher level 
>> interface set, like the one we created for the object set, could be made 
>> that, for the most part, worked for both systems.
>>     
>>>   
>>>       
>
> Yes, I don't mean they'd be using an identical policy but shared
> templates/interfaces that worked with both would certainly make it easier to
> target both systems without really needing to know the intricacies of each
> systems enforcement.
>   
Sounds like a good goal.
>   
>>>> To my knowledge there are only two DBMS's that integrate SELinux into 
>>>> its product, SEPostgresql and Trusted RUBIX. I'm not so sure I would say 
>>>> our DBMS object models are dramatically different.  SEPostgresql does 
>>>> not have a catalog object and chose not to have selinux control over 
>>>> their schema object. From looking at KaiGai's work and posts I think in 
>>>> the future they will support the schema object, in much the same way I 
>>>> tried to in our current release.
>>>>     
>>>>         
>>> They chose not to for now, the initial set of permissions used by SEPostgres
>>> looks like it is going to be minimal, unfortunately, but should evolve into
>>> something more comprehensive.
>>>
>>> I may be missing it but do you support 'domain-like' type_transitions for stored
>>> procedures? This was one of the more interesting features in the initial
>>> sepostgres patches IMHO because it allowed for trusted stored procedures that
>>> can read tables the client couldn't necessarily read, and could do operations on
>>> them before handing over the data (eg., fuzzing of coordinates)
>>>   
>>>       
>> We do not implement stored procedures at all, though this is a near 
>> future possibility. As I said before, our background is MLS and often in 
>> the EAL-5+ type (old B3). The group-think was always that stored 
>> procedures were too insecure for such assurance levels. But, I have been 
>> pushing the possibility in a EAL-4 type mode, for exactly the reasons 
>> you mentioned above. With the selinux domain transition concept a stored 
>> procedure becomes very interesting.
>>     
>>> --
>>>       
>
>
>   

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

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

[Joshua Brindle]

Andy Warner wrote:
> 
>   
> KaiGai and I talked about this a bit already, and I'll preface my 
> response by saying that my memory of it is poor. Also, this issue was 
> one of my first practical introductions to selinux, so I'm sure I was 
> shooting in the dark. But, the main issue revolved around the type 
> transition rule for the database object. It seems to me, what makes it 
> special is that it has no parent object. It seems equivalent to writing 
> a type transition rule for creating the OS root directory, except in our 
> DBMS case we can have more than one type (each dbms has their own).
> 
> A rule for sepostgres is:
> 
> type_transition sepgsql_client_type sepgsql_client_type : db_database 
> sepgsql_db_t;
> 
> Where I believe the standard user_t and such had the sepgsql_client_type 
> attribute. So, with that rule in place I think it was impossible for 
> rubix to have a similar rule, if our client_type's overlapped. Which 
> seems likely, as the user_t is a likely candidate for a client. For 
> instance, if I did this:

strange, I thought he/we decided to use the domain of the dbms as the target for
that type_transition. That would solve this particular problem, I'd have to go
back in archives to understand why this path was chosen, or perhaps KaiGai
remembers.

> 
> type_transition rubix_client_type rubix_client_type : db_database 
> rubix_db_t; (where rubix_client_type contained user_t)
> 
> I think it would not compile because its ambiguous, right? So, what I 
> did was write a rule like this:
> 
> type_transition rubix_client_type rubix_t : db_database rubix_db_t;
> 
> and hard-coded the rubix_t into the avc_compute_create call. The rubix_t 
> is actually the type of our server process. Prior to doing that, I could 
> not find a way to not have a database be created with a sepgsql_t type.
> 

If you just used the dbms domain as the target you wouldn't need to hardcode
anything.

> I see (now) that the reference policy also has the rule:
> 
> type_transition postgresql_t postgresql_t : db_database sepgsql_db_t;
> 
> Obviously, the above would never conflict with another dbms's rules. If 
> that single type transition rule satisfied all of seposgresql's needs, 
> then that would eliminate the need for the conflicting rule. Though, I 
> assume thats dependent on  the internals of seposgresql.
>>

This is for internally created db objects? Why are both this and the client ->
client transitions needed?

<snip>
>>
>> Yes, I don't mean they'd be using an identical policy but shared
>> templates/interfaces that worked with both would certainly make it easier to
>> target both systems without really needing to know the intricacies of each
>> systems enforcement.
>>   
> Sounds like a good goal.
>

It may be a pipe dream, like having a common policy for all MTA's. At least if
there is some consensus on the internal object model, and since SQL is pretty
much the same everywhere this may actually stand a chance.



--
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: Some ideas in SE-PostgreSQL enhancement (Re: The status of SE-PostgreSQL)

[Andy Warner]

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



Joshua Brindle wrote:
> Andy Warner wrote:
>   
>>   
>> KaiGai and I talked about this a bit already, and I'll preface my 
>> response by saying that my memory of it is poor. Also, this issue was 
>> one of my first practical introductions to selinux, so I'm sure I was 
>> shooting in the dark. But, the main issue revolved around the type 
>> transition rule for the database object. It seems to me, what makes it 
>> special is that it has no parent object. It seems equivalent to writing 
>> a type transition rule for creating the OS root directory, except in our 
>> DBMS case we can have more than one type (each dbms has their own).
>>
>> A rule for sepostgres is:
>>
>> type_transition sepgsql_client_type sepgsql_client_type : db_database 
>> sepgsql_db_t;
>>
>> Where I believe the standard user_t and such had the sepgsql_client_type 
>> attribute. So, with that rule in place I think it was impossible for 
>> rubix to have a similar rule, if our client_type's overlapped. Which 
>> seems likely, as the user_t is a likely candidate for a client. For 
>> instance, if I did this:
>>     
>
> strange, I thought he/we decided to use the domain of the dbms as the target for
> that type_transition. That would solve this particular problem, I'd have to go
> back in archives to understand why this path was chosen, or perhaps KaiGai
> remembers.
>
>   
>> type_transition rubix_client_type rubix_client_type : db_database 
>> rubix_db_t; (where rubix_client_type contained user_t)
>>
>> I think it would not compile because its ambiguous, right? So, what I 
>> did was write a rule like this:
>>
>> type_transition rubix_client_type rubix_t : db_database rubix_db_t;
>>
>> and hard-coded the rubix_t into the avc_compute_create call. The rubix_t 
>> is actually the type of our server process. Prior to doing that, I could 
>> not find a way to not have a database be created with a sepgsql_t type.
>>
>>     
>
> If you just used the dbms domain as the target you wouldn't need to hardcode
> anything.
>   
Actually, thats what I did. My choice of words (hardcoding) wasn't the best
>   
>> I see (now) that the reference policy also has the rule:
>>
>> type_transition postgresql_t postgresql_t : db_database sepgsql_db_t;
>>
>> Obviously, the above would never conflict with another dbms's rules. If 
>> that single type transition rule satisfied all of seposgresql's needs, 
>> then that would eliminate the need for the conflicting rule. Though, I 
>> assume thats dependent on  the internals of seposgresql.
>>     
>
> This is for internally created db objects? Why are both this and the client ->
> client transitions needed?
>
> <snip>
>   
>>> Yes, I don't mean they'd be using an identical policy but shared
>>> templates/interfaces that worked with both would certainly make it easier to
>>> target both systems without really needing to know the intricacies of each
>>> systems enforcement.
>>>   
>>>       
>> Sounds like a good goal.
>>
>>     
>
> It may be a pipe dream, like having a common policy for all MTA's. At least if
> there is some consensus on the internal object model, and since SQL is pretty
> much the same everywhere this may actually stand a chance.
>   
I like to be in that loop
>
>
>   

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

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

[KaiGai Kohei]

Joshua Brindle wrote:
> Andy Warner wrote:
>>   
>> KaiGai and I talked about this a bit already, and I'll preface my 
>> response by saying that my memory of it is poor. Also, this issue was 
>> one of my first practical introductions to selinux, so I'm sure I was 
>> shooting in the dark. But, the main issue revolved around the type 
>> transition rule for the database object. It seems to me, what makes it 
>> special is that it has no parent object. It seems equivalent to writing 
>> a type transition rule for creating the OS root directory, except in our 
>> DBMS case we can have more than one type (each dbms has their own).
>>
>> A rule for sepostgres is:
>>
>> type_transition sepgsql_client_type sepgsql_client_type : db_database 
>> sepgsql_db_t;
>>
>> Where I believe the standard user_t and such had the sepgsql_client_type 
>> attribute. So, with that rule in place I think it was impossible for 
>> rubix to have a similar rule, if our client_type's overlapped. Which 
>> seems likely, as the user_t is a likely candidate for a client. For 
>> instance, if I did this:
> 
> strange, I thought he/we decided to use the domain of the dbms as the target for
> that type_transition. That would solve this particular problem, I'd have to go
> back in archives to understand why this path was chosen, or perhaps KaiGai
> remembers.

It had been a headache what is the target of TYPE_TRANSITION for the root
object.
At the initial design, as you pointed out, I used the domain of server
process as the target to decide the security context of database itself.
Then, I got a suggestion that we can use the following notation to
represent the security context of new object is determined by only
the context of subject.

  TYPE_TRANSITION <subject context> <subject context> : <class> <new context>;

I could understand as an analogy of permission checks on the kernel
capability classes.

>> type_transition rubix_client_type rubix_client_type : db_database 
>> rubix_db_t; (where rubix_client_type contained user_t)
>>
>> I think it would not compile because its ambiguous, right? So, what I 
>> did was write a rule like this:
>>
>> type_transition rubix_client_type rubix_t : db_database rubix_db_t;
>>
>> and hard-coded the rubix_t into the avc_compute_create call. The rubix_t 
>> is actually the type of our server process. Prior to doing that, I could 
>> not find a way to not have a database be created with a sepgsql_t type.
>>
> 
> If you just used the dbms domain as the target you wouldn't need to hardcode
> anything.

I also think we should not hold any hardcode context inside the DBMS.

>> I see (now) that the reference policy also has the rule:
>>
>> type_transition postgresql_t postgresql_t : db_database sepgsql_db_t;
>>
>> Obviously, the above would never conflict with another dbms's rules. If 
>> that single type transition rule satisfied all of seposgresql's needs, 
>> then that would eliminate the need for the conflicting rule. Though, I 
>> assume thats dependent on  the internals of seposgresql.
> 
> This is for internally created db objects? Why are both this and the client ->
> client transitions needed?

It is the case of deterministration for the root object.
When we set up the initial database, PostgreSQL with bootstraping mode also
performs as a client concurrently.
Please consider the "postgresql_t" represents the case when it performs
as a client, not only a server.

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: [PATCH] Expose avc_netlink_loop() for applications (Re: Some ideas in SE-PostgreSQL enhancement)

[Eamon Walsh]

KaiGai Kohei wrote:

[snip]

> I have two minor and major concern with this approach.
>
> The minor one is it consumes unnecessary memory due to avc_init().
> Because of some reasons, SE-PostgreSQL implements its own userspace
> AVC, so this region is purely waste of space.
>   

avc_init() does set up the cache but it remains empty since it is not
used by the worker process for any lookups. I don't think the memory
overhead of an empty cache should be that large. But see below.


> The major one is we cannot handle them in a sindle lock section.
> When the application is callbacked via AVC_CALLBACK_SETENFORCE,
> it will change the state of enforcing/permissive, and it resets
> its own avc on AVC_CALLBACK_RESET. But I would like to handle
> these operations in a single lock section.
>
> If we reset the avc on AVC_CALLBACK_SETENFORCE, it finally
> resets the avc twice on a single message. It is also unconfortable.
>
> The design of callbacks (via selinux_set_callback()) can be
> considerable, but I don't think it is a good idea to hide
> the netlink stuff here.
>
> In my patch, it adds SELINUX_CB_NETLINK for any messages.
> But, if it would be SELINUX_CB_SETENFORCE and SELINUX_CB_POLICYLOAD,
> we don't need to refer any netlink related stuffs from applications.
>
> What is your opinion?
>   


Considering your point, I'd rather create SETENFORCE and POLICYLOAD
callbacks for selinux_set_callback(). However, they should be called in
addition to the normal processing in avc_netlink_process(), not
replacing the code flow. The savings from not updating a few globals and
calling avc_ss_reset (which returns immediately if the userspace AVC is
not running) are not that big.

You could optionally make avc_netlink_open() and avc_netlink_close()
public functions, which would allow to avoid calling avc_init().



-- 
Eamon Walsh <ewalsh@tycho.nsa.gov>
National Security Agency


--
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: [PATCH] Expose avc_netlink_loop() for applications (Re: Some ideas in SE-PostgreSQL enhancement)

[KaiGai Kohei]

[snip]

>> The major one is we cannot handle them in a sindle lock section.
>> When the application is callbacked via AVC_CALLBACK_SETENFORCE,
>> it will change the state of enforcing/permissive, and it resets
>> its own avc on AVC_CALLBACK_RESET. But I would like to handle
>> these operations in a single lock section.
>>
>> If we reset the avc on AVC_CALLBACK_SETENFORCE, it finally
>> resets the avc twice on a single message. It is also unconfortable.
>>
>> The design of callbacks (via selinux_set_callback()) can be
>> considerable, but I don't think it is a good idea to hide
>> the netlink stuff here.
>>
>> In my patch, it adds SELINUX_CB_NETLINK for any messages.
>> But, if it would be SELINUX_CB_SETENFORCE and SELINUX_CB_POLICYLOAD,
>> we don't need to refer any netlink related stuffs from applications.
>>
>> What is your opinion?
>>   
> 
> 
> Considering your point, I'd rather create SETENFORCE and POLICYLOAD
> callbacks for selinux_set_callback(). However, they should be called in
> addition to the normal processing in avc_netlink_process(), not
> replacing the code flow. The savings from not updating a few globals and
> calling avc_ss_reset (which returns immediately if the userspace AVC is
> not running) are not that big.

It seems to me fair enough.

> You could optionally make avc_netlink_open() and avc_netlink_close()
> public functions, which would allow to avoid calling avc_init().

In addition, avc_netlink_loop() also.

I'll submit a revised patch on the Monday.
Please wait for a while.

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: [PATCH] Permissive domain in userspace (Re: Some ideas in SE-PostgreSQL enhancement)

[Eamon Walsh]

KaiGai Kohei wrote:
> KaiGai Kohei wrote:
>   
>> 4. Permissive domain in userspace
>>
>> It is an issue got sleep for a few months.
>>   http://marc.info/?l=selinux&m=122337314619667&w=2
>>     
>
> It was discussed at the past a bit, but left it for several months.
>
> Now we have a new idea of permissive domain which allows certain
> domains to work as if being in permissive mode.
> The in-kernel SELinux can handle it well, but userspace object
> managers could not handler it because we don't have an interface
> to tell what domain is permissive.
>
> The attached patches are for the kernel and libselinux.
>
> The kernel patch adds a flags field on av_decision, and returns
> it as the sixth parameter on the reply of /selinux/access.
>
> The libselinux patch enhance libselinux to understand it, and
> two new interfaces are added.
>  - security_compute_av_flags()
>  - security_compute_av_flags_raw()
> It also adds a new flags field on av_decision, but it is not
> touched when we use the existing interfaces due to the binary
> compatibility.
>
> The standard userspace avc uses _flags interface, instead of
> existing one, so it enables to control permissive domain.
>
> IIRC, Eamon pointed out that it is preferable to put a new field
> of 'permissive' than general purpose 'flags'. But it will require
> interface changes, if we need more state in the future.
> So, I don't change the implementation.
>
> Please comment anything.
>
> Thanks,
>   

Don't have any immediate issues with the libselinux patches. Will wait
on kernel acceptance.

Some general questions:

When the userspace AVC is configured in "enforcing" mode, which
overrides the kernel setting, how should permissive domains be treated?

When the entire system is in permissive mode, should the permissive flag
be returned as true for all domains?

/me wonders how long it will be before someone proposes permissive
classes, or permissions ("permissive permissions"). Or marking
individual tsid,ssid,tclass tuples as permissive. Just think of the
problems we could solve.

cc'ed Steve.

-- 
Eamon Walsh <ewalsh@tycho.nsa.gov>
National Security Agency


--
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: Some ideas in SE-PostgreSQL enhancement (Re: The status of SE-PostgreSQL)

[Andy Warner]

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



KaiGai Kohei wrote:
> Joshua Brindle wrote:
>   
>> Andy Warner wrote:
>>     
>>>   
>>> KaiGai and I talked about this a bit already, and I'll preface my 
>>> response by saying that my memory of it is poor. Also, this issue was 
>>> one of my first practical introductions to selinux, so I'm sure I was 
>>> shooting in the dark. But, the main issue revolved around the type 
>>> transition rule for the database object. It seems to me, what makes it 
>>> special is that it has no parent object. It seems equivalent to writing 
>>> a type transition rule for creating the OS root directory, except in our 
>>> DBMS case we can have more than one type (each dbms has their own).
>>>
>>> A rule for sepostgres is:
>>>
>>> type_transition sepgsql_client_type sepgsql_client_type : db_database 
>>> sepgsql_db_t;
>>>
>>> Where I believe the standard user_t and such had the sepgsql_client_type 
>>> attribute. So, with that rule in place I think it was impossible for 
>>> rubix to have a similar rule, if our client_type's overlapped. Which 
>>> seems likely, as the user_t is a likely candidate for a client. For 
>>> instance, if I did this:
>>>       
>> strange, I thought he/we decided to use the domain of the dbms as the target for
>> that type_transition. That would solve this particular problem, I'd have to go
>> back in archives to understand why this path was chosen, or perhaps KaiGai
>> remembers.
>>     
>
> It had been a headache what is the target of TYPE_TRANSITION for the root
> object.
> At the initial design, as you pointed out, I used the domain of server
> process as the target to decide the security context of database itself.
> Then, I got a suggestion that we can use the following notation to
> represent the security context of new object is determined by only
> the context of subject.
>
>   TYPE_TRANSITION <subject context> <subject context> : <class> <new context>;
>
> I could understand as an analogy of permission checks on the kernel
> capability classes.
>
>   
It seems if you decide the context of the database using only the
subject's attributes itself, there will always be potential conflict
with other DBMS's. There is nothing in the type transition that
identifies the rule as applying to a sepostgresql dbms as opposed to any
other. It seems a bad way to do it. I would propose either:

TYPE_TRANSITION <server context> <server context> : <class> <new context>;

or

TYPE_TRANSITION <subject context> <server context> : <class> <new context>;

Where the 1st has the potential to cover all permutations (but only one new context) and the latter opens the possibility to have different new contexts based upon the context of the subject, but could leave some permutations uncovered. I think the second case is more general and flexible and the first case could be viewed as a special case of the second.

>>> type_transition rubix_client_type rubix_client_type : db_database 
>>> rubix_db_t; (where rubix_client_type contained user_t)
>>>
>>> I think it would not compile because its ambiguous, right? So, what I 
>>> did was write a rule like this:
>>>
>>> type_transition rubix_client_type rubix_t : db_database rubix_db_t;
>>>
>>> and hard-coded the rubix_t into the avc_compute_create call. The rubix_t 
>>> is actually the type of our server process. Prior to doing that, I could 
>>> not find a way to not have a database be created with a sepgsql_t type.
>>>
>>>       
>> If you just used the dbms domain as the target you wouldn't need to hardcode
>> anything.
>>     
>
> I also think we should not hold any hardcode context inside the DBMS.
>
>   
>>> I see (now) that the reference policy also has the rule:
>>>
>>> type_transition postgresql_t postgresql_t : db_database sepgsql_db_t;
>>>
>>> Obviously, the above would never conflict with another dbms's rules. If 
>>> that single type transition rule satisfied all of seposgresql's needs, 
>>> then that would eliminate the need for the conflicting rule. Though, I 
>>> assume thats dependent on  the internals of seposgresql.
>>>       
>> This is for internally created db objects? Why are both this and the client ->
>> client transitions needed?
>>     
>
> It is the case of deterministration for the root object.
> When we set up the initial database, PostgreSQL with bootstraping mode also
> performs as a client concurrently.
> Please consider the "postgresql_t" represents the case when it performs
> as a client, not only a server.
>
> Thanks,
>   

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

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

[KaiGai Kohei]

>> It had been a headache what is the target of TYPE_TRANSITION for the root
>> object.
>> At the initial design, as you pointed out, I used the domain of server
>> process as the target to decide the security context of database itself.
>> Then, I got a suggestion that we can use the following notation to
>> represent the security context of new object is determined by only
>> the context of subject.
>>
>>   TYPE_TRANSITION <subject context> <subject context> : <class> <new context>;
>>
>> I could understand as an analogy of permission checks on the kernel
>> capability classes.
>>
>>   
> It seems if you decide the context of the database using only the 
> subject's attributes itself, there will always be potential conflict 
> with other DBMS's. There is nothing in the type transition that 
> identifies the rule as applying to a sepostgresql dbms as opposed to any 
> other. It seems a bad way to do it. I would propose either:
> 
> TYPE_TRANSITION <server context> <server context> : <class> <new context>;
> 
> or
> 
> TYPE_TRANSITION <subject context> <server context> : <class> <new context>;
> 
> Where the 1st has the potential to cover all permutations (but only one new context) and the latter opens the possibility to have different new contexts based upon the context of the subject, but could leave some permutations uncovered. I think the second case is more general and flexible and the first case could be viewed as a special case of the second.

I can understand your concern. Indeed, the combination of client context and
itself cannot handle the case when multiple DBMSs are installed.

My preference is the later one:
  TYPE_TRANSITION <subject context> <server context> : <class> <new context>;

In addition, an idea of configuration file can be considerable to set up
the default context of database objects, though I considered it is not
necessary in the past discussion.
If a user want to work the database server process as an unconfined domain,
like a legacy "disable_xxxx_trans" boolean doing, the <server context> as
the target of TYPE_TRANSITION breaks all the correct labeling.

If we have a /etc/selinux/$POLICYTYPE/contexts/db_{sepgsql|rubix}, as follows,
it can be used to specify the default context of special purpose database
object such as schemas to store temporary database objects, not only the
context of database as the root of type transition.
------------
database    *             system_u:object_r:sepgsql_db_t:s0
schema      pg_temp_*     system_u:object_r:sepgsql_temp_schema_t:s0
  :             :            :
------------

The libselinux has selabel_lookup(3) interface to implement them
for various kind of objects.

One concern is performance hit. If we need to open/lookup/close the file
for each INSERT statement, its pain will be unacceptable.

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.

Re: [PATCH] Permissive domain in userspace (Re: Some ideas in SE-PostgreSQL enhancement)

[KaiGai Kohei]

Eamon Walsh wrote:
> KaiGai Kohei wrote:
>> KaiGai Kohei wrote:
>>   
>>> 4. Permissive domain in userspace
>>>
>>> It is an issue got sleep for a few months.
>>>   http://marc.info/?l=selinux&m=122337314619667&w=2
>>>     
>> It was discussed at the past a bit, but left it for several months.
>>
>> Now we have a new idea of permissive domain which allows certain
>> domains to work as if being in permissive mode.
>> The in-kernel SELinux can handle it well, but userspace object
>> managers could not handler it because we don't have an interface
>> to tell what domain is permissive.
>>
>> The attached patches are for the kernel and libselinux.
>>
>> The kernel patch adds a flags field on av_decision, and returns
>> it as the sixth parameter on the reply of /selinux/access.
>>
>> The libselinux patch enhance libselinux to understand it, and
>> two new interfaces are added.
>>  - security_compute_av_flags()
>>  - security_compute_av_flags_raw()
>> It also adds a new flags field on av_decision, but it is not
>> touched when we use the existing interfaces due to the binary
>> compatibility.
>>
>> The standard userspace avc uses _flags interface, instead of
>> existing one, so it enables to control permissive domain.
>>
>> IIRC, Eamon pointed out that it is preferable to put a new field
>> of 'permissive' than general purpose 'flags'. But it will require
>> interface changes, if we need more state in the future.
>> So, I don't change the implementation.
>>
>> Please comment anything.
>>
>> Thanks,
>>   
> 
> Don't have any immediate issues with the libselinux patches. Will wait
> on kernel acceptance.
> 
> Some general questions:
> 
> When the userspace AVC is configured in "enforcing" mode, which
> overrides the kernel setting, how should permissive domains be treated?

>From an analogy of the kernel, the object manager (kernel) allows
the permissive domains to override security policy setting, even if
it is configured as "enforcing mode".
I think the object manager (X, DBMS) should also allow the permissive
domains to override their access controls, because of symmetry.

> When the entire system is in permissive mode, should the permissive flag
> be returned as true for all domains?

I don't think it is correct manner, because the permissive flag shows
the domain (subject context) is configured as permissive domain, not
the global system state.

> /me wonders how long it will be before someone proposes permissive
> classes, or permissions ("permissive permissions"). Or marking
> individual tsid,ssid,tclass tuples as permissive. Just think of the
> problems we could solve.

This patch marks the permissive flag for an individual pair of tsid,
ssid and tclass in the result, but its value is determined by only
the property of tsid.

I don't think we have to hold the flag with the pair of them, but
it is worthfull from the viewpoint of implementation.
In the kernel, the avc_has_perm_noaudit() calls security_permissive_sid()
which aquires "policy_rwlock" to check permissive domain. The lock
operatins need unchached memory operatins, so heavy iteration of locks
(even if it is reader lock) on SMP system hits performance.
If an avc entry has the flag, we can check whether the given domain
is permissive or not, without "policy_rwlock".

If we have an entry something like "/selinux/permissive" to return
whether the given domain is permissive or not, I think we don't need
to have the flags field on security_compute_av(). It can be checked
on the creation of userspace avc entry, and checked it on later access
controls.

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.

Re: [PATCH] Expose avc_netlink_loop() for applications (Re: Some ideas in SE-PostgreSQL enhancement)

[KaiGai Kohei]

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

The attached patch enables userspace object managers to handle notification
messages via netlink socket from SELinux.

* Two new callbacks were added to selinux_set_callback(3)
  - SELINUX_CB_SETENFORCE
     is invoked when it got SELNL_MSG_SETENFORCE message in the
     avc_netlink_process().
  - SELINUX_CB_POLICYLOAD
     is invoked when it got SELNL_MSG_POLICYLOAD message in the
     avc_netlink_process().

* Three functions were exposed to applications.
  - int avc_netlink_open(int blocking);
  - void avc_netlink_loop(void);
  - void avc_netlink_close(void);

Due to a few reasons, SE-PostgreSQL implements its own userspace
avc, so it needs to copy and paste some of avc_internal.c.
This update enables to share common part from such kind of application.

Please apply this patch.

Thanks,

KaiGai Kohei wrote:
> [snip]
> 
>>> The major one is we cannot handle them in a sindle lock section.
>>> When the application is callbacked via AVC_CALLBACK_SETENFORCE,
>>> it will change the state of enforcing/permissive, and it resets
>>> its own avc on AVC_CALLBACK_RESET. But I would like to handle
>>> these operations in a single lock section.
>>>
>>> If we reset the avc on AVC_CALLBACK_SETENFORCE, it finally
>>> resets the avc twice on a single message. It is also unconfortable.
>>>
>>> The design of callbacks (via selinux_set_callback()) can be
>>> considerable, but I don't think it is a good idea to hide
>>> the netlink stuff here.
>>>
>>> In my patch, it adds SELINUX_CB_NETLINK for any messages.
>>> But, if it would be SELINUX_CB_SETENFORCE and SELINUX_CB_POLICYLOAD,
>>> we don't need to refer any netlink related stuffs from applications.
>>>
>>> What is your opinion?
>>>   
>>
>> Considering your point, I'd rather create SETENFORCE and POLICYLOAD
>> callbacks for selinux_set_callback(). However, they should be called in
>> addition to the normal processing in avc_netlink_process(), not
>> replacing the code flow. The savings from not updating a few globals and
>> calling avc_ss_reset (which returns immediately if the userspace AVC is
>> not running) are not that big.
> 
> It seems to me fair enough.
> 
>> You could optionally make avc_netlink_open() and avc_netlink_close()
>> public functions, which would allow to avoid calling avc_init().
> 
> In addition, avc_netlink_loop() also.
> 
> I'll submit a revised patch on the Monday.
> Please wait for a while.
> 
> Thanks,


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

[-- Attachment #2: libselinux-expose-netlink-loop.2.patch --]
[-- Type: text/x-patch, Size: 9293 bytes --]

 Signed-off-by: KaiGai Kohei <kaigai@ak.jp.nec.com>
--
 libselinux/include/selinux/avc.h           |   15 ++++++++
 libselinux/include/selinux/selinux.h       |    6 +++
 libselinux/man/man3/avc_netlink_close.3    |    1 +
 libselinux/man/man3/avc_netlink_loop.3     |   49 ++++++++++++++++++++++++++++
 libselinux/man/man3/avc_netlink_open.3     |    1 +
 libselinux/man/man3/selinux_set_callback.3 |   26 +++++++++++++++
 libselinux/src/avc_internal.c              |    9 +++++
 libselinux/src/avc_internal.h              |    3 --
 libselinux/src/callbacks.c                 |   32 ++++++++++++++++++
 libselinux/src/callbacks.h                 |    6 +++
 10 files changed, 145 insertions(+), 3 deletions(-)

diff --git a/libselinux/include/selinux/avc.h b/libselinux/include/selinux/avc.h
index 1ea25a2..9ec23ab 100644
--- a/libselinux/include/selinux/avc.h
+++ b/libselinux/include/selinux/avc.h
@@ -428,6 +428,21 @@ void avc_av_stats(void);
 void avc_sid_stats(void);
 
 /**
+ * avc_netlink_open - Create a netlink socket and connect to the kernel.
+ */
+int avc_netlink_open(int blocking);
+
+/**
+ * avc_netlink_loop - Wait for netlink messages from the kernel
+ */
+void avc_netlink_loop(void);
+
+/**
+ * avc_netlink_close - Close the netlink socket
+ */
+void avc_netlink_close(void);
+
+/**
  * avc_netlink_acquire_fd - Acquire netlink socket fd.
  *
  * Allows the application to manage messages from the netlink socket in
diff --git a/libselinux/include/selinux/selinux.h b/libselinux/include/selinux/selinux.h
index fab083e..73f5db0 100644
--- a/libselinux/include/selinux/selinux.h
+++ b/libselinux/include/selinux/selinux.h
@@ -153,11 +153,17 @@ __attribute__ ((format(printf, 2, 3)))
 			   char *msgbuf, size_t msgbufsize);
 	/* validate the supplied context, modifying if necessary */
 	int (*func_validate) (security_context_t *ctx);
+	/* netlink callback for setenforce message */
+	int (*func_setenforce) (int enforcing);
+	/* netlink callback for policyload message */
+	int (*func_policyload) (int seqno);
 };
 
 #define SELINUX_CB_LOG		0
 #define SELINUX_CB_AUDIT	1
 #define SELINUX_CB_VALIDATE	2
+#define SELINUX_CB_SETENFORCE	3
+#define SELINUX_CB_POLICYLOAD	4
 
 extern union selinux_callback selinux_get_callback(int type);
 extern void selinux_set_callback(int type, union selinux_callback cb);
diff --git a/libselinux/man/man3/avc_netlink_close.3 b/libselinux/man/man3/avc_netlink_close.3
index e69de29..293a947 100644
--- a/libselinux/man/man3/avc_netlink_close.3
+++ b/libselinux/man/man3/avc_netlink_close.3
@@ -0,0 +1 @@
+.so man3/avc_netlink_loop.3
diff --git a/libselinux/man/man3/avc_netlink_loop.3 b/libselinux/man/man3/avc_netlink_loop.3
index e69de29..0fcf3c4 100644
--- a/libselinux/man/man3/avc_netlink_loop.3
+++ b/libselinux/man/man3/avc_netlink_loop.3
@@ -0,0 +1,49 @@
+.\" Hey Emacs! This file is -*- nroff -*- source.
+.\"
+.\" Author: KaiGai Kohei (kaigai@ak.jp.nec.com) 2009
+.TH "avc_netlink_loop" "3" "30 Mar 2009" "" "SELinux API documentation"
+.SH "NAME"
+avc_netlink_open, avc_netlink_loop, avc_netlink_close
+.SH "SYNOPSIS"
+.B #include <selinux/selinux.h>
+
+.B #include <selinux/avc.h>
+.sp
+.BI "void avc_netlink_open(int " blocking ");"
+.sp
+.BI "void avc_netlink_loop(void);"
+.sp
+.BI "void avc_netlink_close(void);"
+.sp
+.SH "DESCRIPTION"
+These functions enable applications to handle notification events via
+kernel netlink socket. 
+
+.B avc_netlink_open
+opens a netlink socket to receive notifications from SELinux.
+It socket file descriptor is stored internally, and application
+can aquire it using
+.B avc_netlink_acquire_fd (3)
+
+.B avc_netlink_loop
+waits for notification messages via the netlink socket opened,
+and invokes callback functions set up using
+.B selinux_set_callback (3)
+before invocation of the function. It never returns to the caller
+unless it got an error. On error, it closes the netlink socket and
+returns to the caller.
+
+.B avc_netlink_close
+close the netlink socket opend.
+
+.SH "OPTIONS"
+If the
+.B blocking
+of the
+.B avc_netlink_open (3)
+is not zero, it configures the socket on non-blocking mode.
+
+.SH "SEE ALSO"
+.BR avc_open (3),
+.BR selinux_set_callback (3),
+.BR selinux (8)
diff --git a/libselinux/man/man3/avc_netlink_open.3 b/libselinux/man/man3/avc_netlink_open.3
index e69de29..293a947 100644
--- a/libselinux/man/man3/avc_netlink_open.3
+++ b/libselinux/man/man3/avc_netlink_open.3
@@ -0,0 +1 @@
+.so man3/avc_netlink_loop.3
diff --git a/libselinux/man/man3/selinux_set_callback.3 b/libselinux/man/man3/selinux_set_callback.3
index 6d6a723..3398af7 100644
--- a/libselinux/man/man3/selinux_set_callback.3
+++ b/libselinux/man/man3/selinux_set_callback.3
@@ -79,6 +79,31 @@ should be set to
 .B EINVAL
 to indicate an invalid context.
 
+.TP
+.B SELINUX_CB_SETENFORCE
+.BI "int (*" func_setenforce ") (int " enforcing ");"
+
+This callback is used to receive a setenforce notification via netlink socket.
+It is invoked when the system enforcing state (enforceing or permissive).
+The
+.I enforcing
+shows the new system enforcing state. It shows
+.I 1
+if enforcing mode, and
+.I 0
+for permissive mode.
+
+.TP
+.B SELINUX_CB_POLICYLOAD
+.BI "int (*" func_policyload ") (int " seqno ");"
+
+This callback is used to receive a policyload notification via netlink socket.
+It is invoked when the security policy is reloaded, any boolean is changed and
+others.
+The
+.I seqno
+shows the currect sequential number of the policy generation in the system.
+
 .SH "RETURN VALUE"
 None.
 
@@ -91,5 +116,6 @@ Eamon Walsh <ewalsh@tycho.nsa.gov>
 .SH "SEE ALSO"
 .BR selabel_open (3),
 .BR avc_init (3),
+.BR avc_netlink_open(3),
 .BR selinux (8)
 
diff --git a/libselinux/src/avc_internal.c b/libselinux/src/avc_internal.c
index 7d6f33d..71a4578 100644
--- a/libselinux/src/avc_internal.c
+++ b/libselinux/src/avc_internal.c
@@ -19,6 +19,7 @@
 #include <sys/socket.h>
 #include <linux/types.h>
 #include <linux/netlink.h>
+#include "callbacks.h"
 #include "selinux_netlink.h"
 #include "avc_internal.h"
 
@@ -159,6 +160,10 @@ static int avc_netlink_process(char *buf)
 		avc_log(SELINUX_INFO,
 			"%s:  received setenforce notice (enforcing=%d)\n",
 			avc_prefix, msg->val);
+		rc = selinux_netlink_setenforce(msg->val);
+		if (rc < 0)
+			return rc;
+
 		if (avc_setenforce)
 			break;
 		avc_enforcing = msg->val;
@@ -176,6 +181,10 @@ static int avc_netlink_process(char *buf)
 		avc_log(SELINUX_INFO,
 			"%s:  received policyload notice (seqno=%d)\n",
 			avc_prefix, msg->seqno);
+		rc = selinux_netlink_policyload(msg->seqno);
+		if (rc < 0)
+			return rc;
+
 		rc = avc_ss_reset(msg->seqno);
 		if (rc < 0) {
 			avc_log(SELINUX_ERROR,
diff --git a/libselinux/src/avc_internal.h b/libselinux/src/avc_internal.h
index 986ea7c..e9e5772 100644
--- a/libselinux/src/avc_internal.h
+++ b/libselinux/src/avc_internal.h
@@ -184,9 +184,6 @@ int avc_ss_set_auditdeny(security_id_t ssid, security_id_t tsid,
 
 /* netlink kernel message code */
 extern int avc_netlink_trouble hidden;
-int avc_netlink_open(int blocking) hidden;
-void avc_netlink_loop(void) hidden;
-void avc_netlink_close(void) hidden;
 
 hidden_proto(avc_av_stats)
     hidden_proto(avc_cleanup)
diff --git a/libselinux/src/callbacks.c b/libselinux/src/callbacks.c
index 5acfd3d..b245364 100644
--- a/libselinux/src/callbacks.c
+++ b/libselinux/src/callbacks.c
@@ -37,6 +37,18 @@ default_selinux_validate(security_context_t *ctx)
 	return security_check_context(*ctx);
 }
 
+static int
+default_selinux_setenforce(int enforcing __attribute__((unused)))
+{
+	return 0;
+}
+
+static int
+default_selinux_policyload(int seqno __attribute__((unused)))
+{
+	return 0;
+}
+
 /* callback pointers */
 int __attribute__ ((format(printf, 2, 3)))
 (*selinux_log)(int, const char *, ...) =
@@ -50,6 +62,14 @@ int
 (*selinux_validate)(security_context_t *ctx) =
 	default_selinux_validate;
 
+int
+(*selinux_netlink_setenforce) (int enforcing) =
+	default_selinux_setenforce;
+
+int
+(*selinux_netlink_policyload) (int seqno) =
+	default_selinux_policyload;
+
 /* callback setting function */
 void
 selinux_set_callback(int type, union selinux_callback cb)
@@ -64,6 +84,12 @@ selinux_set_callback(int type, union selinux_callback cb)
 	case SELINUX_CB_VALIDATE:
 		selinux_validate = cb.func_validate;
 		break;
+	case SELINUX_CB_SETENFORCE:
+		selinux_netlink_setenforce = cb.func_setenforce;
+		break;
+	case SELINUX_CB_POLICYLOAD:
+		selinux_netlink_policyload = cb.func_policyload;
+		break;
 	}
 }
 
@@ -83,6 +109,12 @@ selinux_get_callback(int type)
 	case SELINUX_CB_VALIDATE:
 		cb.func_validate = selinux_validate;
 		break;
+	case SELINUX_CB_SETENFORCE:
+		cb.func_setenforce = selinux_netlink_setenforce;
+		break;
+	case SELINUX_CB_POLICYLOAD:
+		cb.func_policyload = selinux_netlink_policyload;
+		break;
 	default:
 		memset(&cb, 0, sizeof(cb));
 		errno = EINVAL;
diff --git a/libselinux/src/callbacks.h b/libselinux/src/callbacks.h
index 068fa9d..52ad555 100644
--- a/libselinux/src/callbacks.h
+++ b/libselinux/src/callbacks.h
@@ -21,4 +21,10 @@ extern int
 extern int
 (*selinux_validate)(security_context_t *ctx) hidden;
 
+extern int
+(*selinux_netlink_setenforce) (int enforcing) hidden;
+
+extern int
+(*selinux_netlink_policyload) (int seqno) hidden;
+
 #endif				/* _SELINUX_CALLBACKS_H_ */

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

[KaiGai Kohei]

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

KaiGai Kohei wrote:
> My preference is the later one:
>   TYPE_TRANSITION <subject context> <server context> : <class> <new context>;
> 
> In addition, an idea of configuration file can be considerable to set up
> the default context of database objects, though I considered it is not
> necessary in the past discussion.
> If a user want to work the database server process as an unconfined domain,
> like a legacy "disable_xxxx_trans" boolean doing, the <server context> as
> the target of TYPE_TRANSITION breaks all the correct labeling.
> 
> If we have a /etc/selinux/$POLICYTYPE/contexts/db_{sepgsql|rubix}, as follows,
> it can be used to specify the default context of special purpose database
> object such as schemas to store temporary database objects, not only the
> context of database as the root of type transition.
> ------------
> database    *             system_u:object_r:sepgsql_db_t:s0
> schema      pg_temp_*     system_u:object_r:sepgsql_temp_schema_t:s0
>   :             :            :
> ------------
> 
> The libselinux has selabel_lookup(3) interface to implement them
> for various kind of objects.

The attached patch is a proof of the concept.
It adds the forth backend of selabel_lookup(3) interface.

Under the enhancement, we should the following rules to determine what
security context is assigned on the newly created database object.

1. An explicitly specified security context by users.
   e.g)  CREATE TABLE t (a int, b text)
             SECURITY_LABEL = 'system_u:object_r:sepgsql_table_t:SystemHigh';

2. A matched entry in the configuration file which can be lookup up
   by selabel_lookup(3).
   e.g)  schema  pg_temp_*  system_u:object_r:sepgsql_temp_schema_t:s0
                 ^^^^^^^^^ --> if the new object name and type are matched.

3. The result of security_compute_av() or avc_compute_create() which can
   return the result of TYPE_TRANSITION rules.

The second step is newly suggested in this patch.
Needless to say, the determinded security context has to be checked
by the security policy.

> One concern is performance hit. If we need to open/lookup/close the file
> for each INSERT statement, its pain will be unacceptable.

This patch does not support db_tuple class, because of headach in performance
and its characteristic that database tuples have no name to identify itself.

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

[-- Attachment #2: libselinux-database-label-lookup.1.patch --]
[-- Type: text/x-patch, Size: 9189 bytes --]

 libselinux/include/selinux/label.h   |   10 ++
 libselinux/include/selinux/selinux.h |    1 +
 libselinux/src/file_path_suffixes.h  |    1 +
 libselinux/src/label.c               |    3 +-
 libselinux/src/label_db.c            |  207 ++++++++++++++++++++++++++++++++++
 libselinux/src/label_internal.h      |    2 +
 libselinux/src/selinux_config.c      |   10 ++-
 libselinux/src/selinux_internal.h    |    1 +
 8 files changed, 233 insertions(+), 2 deletions(-)

diff --git a/libselinux/include/selinux/label.h b/libselinux/include/selinux/label.h
index 82f4e13..e167508 100644
--- a/libselinux/include/selinux/label.h
+++ b/libselinux/include/selinux/label.h
@@ -29,6 +29,8 @@ struct selabel_handle;
 #define SELABEL_CTX_MEDIA	1
 /* x contexts */
 #define SELABEL_CTX_X		2
+/* database contexts */
+#define SELABEL_CTX_DB		3
 
 /*
  * Available options
@@ -116,6 +118,14 @@ void selabel_stats(struct selabel_handle *handle);
 #define SELABEL_X_POLYPROP	6
 #define SELABEL_X_POLYSELN	7
 
+/* Database backend */
+#define SELABEL_DB_DATABASE	1
+#define SELABEL_DB_CATALOG	2
+#define SELABEL_DB_SCHEMA	3
+#define SELABEL_DB_TABLE	4
+#define SELABEL_DB_COLUMN	5
+#define SELABEL_DB_PROCEDURE	6
+#define SELABEL_DB_SEQUENCE	7
 
 #ifdef __cplusplus
 }
diff --git a/libselinux/include/selinux/selinux.h b/libselinux/include/selinux/selinux.h
index fab083e..8d60b40 100644
--- a/libselinux/include/selinux/selinux.h
+++ b/libselinux/include/selinux/selinux.h
@@ -460,6 +460,7 @@ extern const char *selinux_file_context_local_path(void);
 extern const char *selinux_homedir_context_path(void);
 extern const char *selinux_media_context_path(void);
 extern const char *selinux_x_context_path(void);
+extern const char *selinux_db_context_path(void);
 extern const char *selinux_contexts_path(void);
 extern const char *selinux_securetty_types_path(void);
 extern const char *selinux_booleans_path(void);
diff --git a/libselinux/src/file_path_suffixes.h b/libselinux/src/file_path_suffixes.h
index 8d207c9..30c613d 100644
--- a/libselinux/src/file_path_suffixes.h
+++ b/libselinux/src/file_path_suffixes.h
@@ -20,3 +20,4 @@ S_(BINPOLICY, "/policy/policy")
     S_(FILE_CONTEXTS_LOCAL, "/contexts/files/file_contexts.local")
     S_(X_CONTEXTS, "/contexts/x_contexts")
     S_(COLORS, "/secolor.conf")
+    S_(DB_CONTEXTS, "/contexts/db_contexts")
diff --git a/libselinux/src/label.c b/libselinux/src/label.c
index f7418d6..1a7b13c 100644
--- a/libselinux/src/label.c
+++ b/libselinux/src/label.c
@@ -20,7 +20,8 @@ typedef int (*selabel_initfunc)(struct selabel_handle *rec,
 static selabel_initfunc initfuncs[] = {
 	&selabel_file_init,
 	&selabel_media_init,
-	&selabel_x_init
+	&selabel_x_init,
+	&selabel_db_init,
 };
 
 /*
diff --git a/libselinux/src/label_db.c b/libselinux/src/label_db.c
index e69de29..974770b 100644
--- a/libselinux/src/label_db.c
+++ b/libselinux/src/label_db.c
@@ -0,0 +1,207 @@
+/*
+ * Media contexts backend for Database contexts
+ *
+ * Author: KaiGai Kohei <kaigai@ak.jp.nec.com>
+ */
+#include <sys/stat.h>
+#include <string.h>
+#include <stdio.h>
+#include <stdio_ext.h>
+#include <ctype.h>
+#include <errno.h>
+#include <fnmatch.h>
+#include "callbacks.h"
+#include "label_internal.h"
+
+struct dbctx_entry {
+	struct dbctx_entry *next;
+
+	int type;
+	struct selabel_lookup_rec lr;
+	char *key;
+
+	int matches;
+};
+
+static void selabel_db_close(struct selabel_handle *rec)
+{
+	struct dbctx_entry *entry = rec->data;
+	struct dbctx_entry *next;
+
+	while (entry != NULL) {
+		next = entry->next;
+		free(entry->key);
+		free(entry->lr.ctx_raw);
+		free(entry->lr.ctx_trans);
+		entry = next;
+	}
+}
+
+static struct selabel_lookup_rec *
+selabel_db_lookup(struct selabel_handle *rec, const char *key, int type)
+{
+	struct dbctx_entry *entry = rec->data;
+
+	while (entry != NULL) {
+		if (entry->type == type &&
+		    !fnmatch(entry->key, key, 0)) {
+			entry->matches++;
+                        return &entry->lr;
+		}
+		entry = entry->next;
+	}
+
+	return NULL;
+}
+
+static int process_line(struct selabel_handle *rec, struct dbctx_entry **tail,
+			char *line_buf, const char *path, unsigned lineno)
+{
+	struct dbctx_entry *entry;
+	char *type, *key, *context;
+	int items;
+
+	/* Skip empty lines */
+	while (isspace(*line_buf))
+		line_buf++;
+	if (*line_buf == '#' || *line_buf == '\0')
+		return 0;
+
+	/* Read <type> <key> <context> pair */
+	entry = malloc(sizeof(struct dbctx_entry));
+	if (!entry)
+		return -1;
+	memset(entry, 0, sizeof(struct dbctx_entry));
+
+	items = sscanf(line_buf, "%as %as %as", &type, &key, &context);
+	if (items < 3) {
+		selinux_log(SELINUX_WARNING,
+			    "%s:  line %d is missing fields, skipping\n",
+			    path, lineno);
+		free(entry);
+		if (items > 0)
+			free(type);
+		if (items > 1)
+			free(key);
+		return 0;
+	}
+
+	if (!strcmp(type, "database"))
+		entry->type = SELABEL_DB_DATABASE;
+	else if (!strcmp(type, "catalog"))
+		entry->type = SELABEL_DB_CATALOG;
+	else if (!strcmp(type, "schema"))
+		entry->type = SELABEL_DB_SCHEMA;
+	else if (!strcmp(type, "table"))
+		entry->type = SELABEL_DB_TABLE;
+	else if (!strcmp(type, "column"))
+		entry->type = SELABEL_DB_COLUMN;
+	else if (!strcmp(type, "procedure"))
+		entry->type = SELABEL_DB_PROCEDURE;
+	else if (!strcmp(type, "sequence"))
+		entry->type = SELABEL_DB_SEQUENCE;
+	else {
+		selinux_log(SELINUX_WARNING,
+			    "%s:  line %d has invalid object type %s\n",
+			    path, lineno, type);
+		free(type);
+		free(key);
+		free(context);
+		return 0;
+	}
+	entry->next = NULL;
+	entry->key = key;
+	entry->lr.ctx_raw = context;
+	free(type);
+
+	if (*tail == NULL)
+		rec->data = entry;
+	else
+		(*tail)->next = entry;
+	*tail = entry;
+
+	return 0;
+}
+
+static int selabel_db_open(struct selabel_handle *rec,
+			   struct selinux_opt *opts, unsigned nopts)
+{
+	FILE *filp;
+	const char *path = NULL;
+	char *line_buf = NULL;
+	size_t line_len = 0;
+	struct dbctx_entry *tail = NULL;
+	struct stat sb;
+	int status = -1;
+	int lineno = 0;
+
+	/* Process arguments */
+	while (nopts--) {
+		switch (opts[nopts].type) {
+		case SELABEL_OPT_PATH:
+			path = opts[nopts].value;
+			break;
+		}
+
+	}
+
+	/* Open the specification file */
+	if (!path)
+		path = selinux_db_context_path();
+	if ((filp = fopen(path, "r")) == NULL)
+		return -1;
+	__fsetlocking(filp, FSETLOCKING_BYCALLER);
+
+	if (fstat(fileno(filp), &sb) < 0)
+		goto out;
+	if (!S_ISREG(sb.st_mode)) {
+		errno = EINVAL;
+		goto out;
+	}
+
+	/* Read specfile */
+	while (getline(&line_buf, &line_len, filp) > 0)
+	{
+		lineno++;
+
+		if (process_line(rec, &tail, line_buf, path, lineno))
+		{
+			/* release all the list */
+			selabel_db_close(rec);
+			free(line_buf);
+			goto out;
+		}
+	}
+	free(line_buf);
+
+	status = 0;
+out:
+	fclose(filp);
+	return status;
+}
+
+static void selabel_db_stats(struct selabel_handle *rec)
+{
+	struct dbctx_entry *entry;
+	int count =0, total = 0;
+
+	entry = rec->data;
+	while (entry != NULL) {
+		count++;
+		total += entry->matches;
+	}
+
+	selinux_log(SELINUX_INFO, "%u entries, %u matches made\n",
+		    count, total);
+}
+
+int selabel_db_init(struct selabel_handle *rec,
+		    struct selinux_opt *opts, unsigned nopts)
+{
+	rec->data = NULL;
+	rec->func_close = &selabel_db_close;
+	rec->func_lookup = &selabel_db_lookup;
+	rec->func_stats = &selabel_db_stats;
+
+	return selabel_db_open(rec, opts, nopts);
+}
diff --git a/libselinux/src/label_internal.h b/libselinux/src/label_internal.h
index 27a1f06..0f3a3d9 100644
--- a/libselinux/src/label_internal.h
+++ b/libselinux/src/label_internal.h
@@ -23,6 +23,8 @@ int selabel_media_init(struct selabel_handle *rec, struct selinux_opt *opts,
 		      unsigned nopts) hidden;
 int selabel_x_init(struct selabel_handle *rec, struct selinux_opt *opts,
 		   unsigned nopts) hidden;
+int selabel_db_init(struct selabel_handle *rec, struct selinux_opt *opts,
+		    unsigned nopts) hidden;
 
 /*
  * Labeling internal structures
diff --git a/libselinux/src/selinux_config.c b/libselinux/src/selinux_config.c
index dec5426..8870dc8 100644
--- a/libselinux/src/selinux_config.c
+++ b/libselinux/src/selinux_config.c
@@ -40,7 +40,8 @@
 #define SECURETTY_TYPES   18
 #define X_CONTEXTS        19
 #define COLORS            20
-#define NEL               21
+#define DB_CONTEXTS       21
+#define NEL               22
 
 /* New layout is relative to SELINUXDIR/policytype. */
 static char *file_paths[NEL];
@@ -391,3 +392,10 @@ const char *selinux_x_context_path()
 }
 
 hidden_def(selinux_x_context_path)
+
+const char *selinux_db_context_path()
+{
+	return get_path(DB_CONTEXTS);
+}
+
+hidden_def(selinux_db_context_path)
diff --git a/libselinux/src/selinux_internal.h b/libselinux/src/selinux_internal.h
index 8b4c6d4..d0e5191 100644
--- a/libselinux/src/selinux_internal.h
+++ b/libselinux/src/selinux_internal.h
@@ -66,6 +66,7 @@ hidden_proto(selinux_mkload_policy)
     hidden_proto(selinux_customizable_types_path)
     hidden_proto(selinux_media_context_path)
     hidden_proto(selinux_x_context_path)
+    hidden_proto(selinux_db_context_path)
     hidden_proto(selinux_path)
     hidden_proto(selinux_check_passwd_access)
     hidden_proto(selinux_check_securetty_context)

[-- Attachment #3: dblabel.c --]
[-- Type: text/plain, Size: 1399 bytes --]

#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <errno.h>
#include <selinux/selinux.h>
#include <selinux/label.h>

int main(int argc, char *argv[])
{
    security_context_t context;
    struct selabel_handle *hnd;
    const char *typename;
    const char *keyword;
    int type;

    if (!argv[1] || !argv[2]) {
	fprintf(stderr, "usage: %s <type> <key>\n", argv[0]);
	return 1;
    }

    typename = argv[1];
    keyword = argv[2];

    if (!strcmp(typename, "database"))
	type = SELABEL_DB_DATABASE;
    else if (!strcmp(typename, "catalog"))
	type = SELABEL_DB_CATALOG;
    else if (!strcmp(typename, "schema"))
	type = SELABEL_DB_SCHEMA;
    else if (!strcmp(typename, "table"))
	type = SELABEL_DB_TABLE;
    else if (!strcmp(typename, "column"))
	type = SELABEL_DB_COLUMN;
    else if (!strcmp(typename, "procedure"))
	type = SELABEL_DB_PROCEDURE;
    else if (!strcmp(typename, "sequence"))
	type = SELABEL_DB_SEQUENCE;
    else {
	fprintf(stderr, "invalid object type: %s\n", argv[1]);
	return 1;
    }

    hnd = selabel_open(SELABEL_CTX_DB, NULL, 0);
    if (!hnd) {
	fprintf(stderr, "selabel_open failed : %s\n", strerror(errno));
	return 1;
    }

    if (selabel_lookup(hnd, &context, keyword, type) < 0)
	printf("No valid context for (%s,%s)\n", typename, keyword);
    else
	printf("lookup: %s for (%s,%s)\n", context, typename, keyword);

    selabel_close(hnd);
}

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

[Andy Warner]

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



KaiGai Kohei wrote:
>>> It had been a headache what is the target of TYPE_TRANSITION for the root
>>> object.
>>> At the initial design, as you pointed out, I used the domain of server
>>> process as the target to decide the security context of database itself.
>>> Then, I got a suggestion that we can use the following notation to
>>> represent the security context of new object is determined by only
>>> the context of subject.
>>>
>>>   TYPE_TRANSITION <subject context> <subject context> : <class> <new context>;
>>>
>>> I could understand as an analogy of permission checks on the kernel
>>> capability classes.
>>>
>>>   
>>>       
>> It seems if you decide the context of the database using only the 
>> subject's attributes itself, there will always be potential conflict 
>> with other DBMS's. There is nothing in the type transition that 
>> identifies the rule as applying to a sepostgresql dbms as opposed to any 
>> other. It seems a bad way to do it. I would propose either:
>>
>> TYPE_TRANSITION <server context> <server context> : <class> <new context>;
>>
>> or
>>
>> TYPE_TRANSITION <subject context> <server context> : <class> <new context>;
>>
>> Where the 1st has the potential to cover all permutations (but only one new context) and the latter opens the possibility to have different new contexts based upon the context of the subject, but could leave some permutations uncovered. I think the second case is more general and flexible and the first case could be viewed as a special case of the second.
>>     
>
> I can understand your concern. Indeed, the combination of client context and
> itself cannot handle the case when multiple DBMSs are installed.
>   
Won't the issue exist even if SEPostresql is not installed, as the
policy transition rules (client context and itself) are still there by
default? Or, did you mean if the DBMS policy is installed? I guess one
solution for me could have been to uninstall the sepostgresql policy
module (?).
> My preference is the later one:
>   TYPE_TRANSITION <subject context> <server context> : <class> <new context>;
>   
This one is also my preference.
> In addition, an idea of configuration file can be considerable to set up
> the default context of database objects, though I considered it is not
> necessary in the past discussion.
> If a user want to work the database server process as an unconfined domain,
> like a legacy "disable_xxxx_trans" boolean doing, the <server context> as
> the target of TYPE_TRANSITION breaks all the correct labeling.
>
> If we have a /etc/selinux/$POLICYTYPE/contexts/db_{sepgsql|rubix}, as follows,
> it can be used to specify the default context of special purpose database
> object such as schemas to store temporary database objects, not only the
> context of database as the root of type transition.
> ------------
> database    *             system_u:object_r:sepgsql_db_t:s0
> schema      pg_temp_*     system_u:object_r:sepgsql_temp_schema_t:s0
>   :             :            :
> ------------
>
> The libselinux has selabel_lookup(3) interface to implement them
> for various kind of objects.
>
> One concern is performance hit. If we need to open/lookup/close the file
> for each INSERT statement, its pain will be unacceptable.
>   
I agree it's interesting but potentially a performance hit. For my
purposes, I don't see this as needed because once the db object
transition rule is settled in a way that is friendly to all DBMS's, all
of the functionality I need exists (at this time). It would be
interestung to know the extend of the performance hit expected.
> Thanks,
>   

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

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

[Andy Warner]

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



KaiGai Kohei wrote:
> KaiGai Kohei wrote:
>   
>> My preference is the later one:
>>   TYPE_TRANSITION <subject context> <server context> : <class> <new context>;
>>
>> In addition, an idea of configuration file can be considerable to set up
>> the default context of database objects, though I considered it is not
>> necessary in the past discussion.
>> If a user want to work the database server process as an unconfined domain,
>> like a legacy "disable_xxxx_trans" boolean doing, the <server context> as
>> the target of TYPE_TRANSITION breaks all the correct labeling.
>>
>> If we have a /etc/selinux/$POLICYTYPE/contexts/db_{sepgsql|rubix}, as follows,
>> it can be used to specify the default context of special purpose database
>> object such as schemas to store temporary database objects, not only the
>> context of database as the root of type transition.
>> ------------
>> database    *             system_u:object_r:sepgsql_db_t:s0
>> schema      pg_temp_*     system_u:object_r:sepgsql_temp_schema_t:s0
>>   :             :            :
>> ------------
>>
>> The libselinux has selabel_lookup(3) interface to implement them
>> for various kind of objects.
>>     
>
> The attached patch is a proof of the concept.
> It adds the forth backend of selabel_lookup(3) interface.
>
> Under the enhancement, we should the following rules to determine what
> security context is assigned on the newly created database object.
>
> 1. An explicitly specified security context by users.
>    e.g)  CREATE TABLE t (a int, b text)
>              SECURITY_LABEL = 'system_u:object_r:sepgsql_table_t:SystemHigh';
>
> 2. A matched entry in the configuration file which can be lookup up
>    by selabel_lookup(3).
>    e.g)  schema  pg_temp_*  system_u:object_r:sepgsql_temp_schema_t:s0
>                  ^^^^^^^^^ --> if the new object name and type are matched.
>
> 3. The result of security_compute_av() or avc_compute_create() which can
>    return the result of TYPE_TRANSITION rules.
>
> The second step is newly suggested in this patch.
> Needless to say, the determinded security context has to be checked
> by the security policy.
>
>   
>> One concern is performance hit. If we need to open/lookup/close the file
>> for each INSERT statement, its pain will be unacceptable.
>>     
>
> This patch does not support db_tuple class, because of headach in performance
> and its characteristic that database tuples have no name to identify itself.
>   
Good decision about not including the tuple. I'm guessing that without
the tuple, the lookup would generally have small impact on overall
performance.

Is it standard in SELinux to have the selabel_lookup have higher
priority over any type transition rule? I was always curious about that.
> Thanks,
>   

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

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

[KaiGai Kohei]

>> Under the enhancement, we should the following rules to determine what
>> security context is assigned on the newly created database object.
>>
>> 1. An explicitly specified security context by users.
>>    e.g)  CREATE TABLE t (a int, b text)
>>              SECURITY_LABEL = 'system_u:object_r:sepgsql_table_t:SystemHigh';
>>
>> 2. A matched entry in the configuration file which can be lookup up
>>    by selabel_lookup(3).
>>    e.g)  schema  pg_temp_*  system_u:object_r:sepgsql_temp_schema_t:s0
>>                  ^^^^^^^^^ --> if the new object name and type are matched.
>>
>> 3. The result of security_compute_av() or avc_compute_create() which can
>>    return the result of TYPE_TRANSITION rules.
>>
>> The second step is newly suggested in this patch.
>> Needless to say, the determinded security context has to be checked
>> by the security policy.
>>
>>   
>>> One concern is performance hit. If we need to open/lookup/close the file
>>> for each INSERT statement, its pain will be unacceptable.
>>>     
>>
>> This patch does not support db_tuple class, because of headach in performance
>> and its characteristic that database tuples have no name to identify itself.
>>   
> Good decision about not including the tuple. I'm guessing that without 
> the tuple, the lookup would generally have small impact on overall 
> performance.
> 
> Is it standard in SELinux to have the selabel_lookup have higher 
> priority over any type transition rule? I was always curious about that.

Please note that the security policy has to allow the client db_xxxx:{create}
privilege on creation of database object independent from its labeling
strategy. Don't confound the way to specify an explicit label and permission
to create a database object. :-)

>From an analogy of filesystem, if we can put a valid security context on
/proc/self/attr/fscreate, it enables us to *try to create* a file with
discretionary label, but it does not mean that the file:{create} permission
is always allowed on any given labels.

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: [PATCH] Permissive domain in userspace (Re: Some ideas in SE-PostgreSQL enhancement)

[KaiGai Kohei]

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

KaiGai Kohei wrote:
> If we have an entry something like "/selinux/permissive" to return
> whether the given domain is permissive or not, I think we don't need
> to have the flags field on security_compute_av(). It can be checked
> on the creation of userspace avc entry, and checked it on later access
> controls.

The attached patch exposes a new entry in selinuxfs, which enables
userspace stuff to make a query whether the given context is permissive
domain, or not.
If the given context is permissive domain, userspace stuffs can mark
its entry as a permissive one on creation of avc entries, to avoid
policy enforcement on permissive domains.

It now checks security:{check_context} permission, but it should be
discussed what permission to be checked here.

The attached check_permissive.c is an example to use the interface.

  [kaigai@saba ~]$ ./check_permissive staff_u:staff_r:staff_t:s0
  staff_u:staff_r:staff_t:s0 is a permissive domain
  [kaigai@saba ~]$ ./check_permissive user_u:user_r:user_t:s0
  user_u:user_r:user_t:s0 is NOT a permissive domain

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

[-- Attachment #2: kernel-interface-permissive-domain.1.patch --]
[-- Type: text/x-patch, Size: 2679 bytes --]

 Signed-off-by: KaiGai Kohei <kaigai@ak.jp.nec.com>
--
 security/selinux/selinuxfs.c |   24 ++++++++++++++++++++++++
 1 files changed, 24 insertions(+), 0 deletions(-)

diff --git a/security/selinux/selinuxfs.c b/security/selinux/selinuxfs.c
index d3c8b98..10accc0 100644
--- a/security/selinux/selinuxfs.c
+++ b/security/selinux/selinuxfs.c
@@ -122,6 +122,7 @@ enum sel_inos {
 	SEL_COMPAT_NET,	/* whether to use old compat network packet controls */
 	SEL_REJECT_UNKNOWN, /* export unknown reject handling to userspace */
 	SEL_DENY_UNKNOWN, /* export unknown deny handling to userspace */
+	SEL_PERMISSIVE,	/* check whether permissive domain or not */
 	SEL_INO_NEXT,	/* The next inode number to use */
 };
 
@@ -513,6 +514,7 @@ static ssize_t sel_write_create(struct file *file, char *buf, size_t size);
 static ssize_t sel_write_relabel(struct file *file, char *buf, size_t size);
 static ssize_t sel_write_user(struct file *file, char *buf, size_t size);
 static ssize_t sel_write_member(struct file *file, char *buf, size_t size);
+static ssize_t sel_write_permissive(struct file *file, char *buf, size_t size);
 
 static ssize_t (*write_op[])(struct file *, char *, size_t) = {
 	[SEL_ACCESS] = sel_write_access,
@@ -521,6 +523,7 @@ static ssize_t (*write_op[])(struct file *, char *, size_t) = {
 	[SEL_USER] = sel_write_user,
 	[SEL_MEMBER] = sel_write_member,
 	[SEL_CONTEXT] = sel_write_context,
+	[SEL_PERMISSIVE] = sel_write_permissive,
 };
 
 static ssize_t selinux_transaction_write(struct file *file, const char __user *buf, size_t size, loff_t *pos)
@@ -841,6 +844,26 @@ out:
 	return length;
 }
 
+static ssize_t sel_write_permissive(struct file *file, char *buf, size_t size)
+{
+	u32 sid;
+	ssize_t rc;
+
+	/*
+	 * MEMO: Is it correct to check security:{check_context} here?
+	 * Or, we should add something like security:{check_permissive}?
+	 */
+	rc = task_has_security(current, SECURITY__CHECK_CONTEXT);
+	if (rc)
+		return rc;
+
+	rc = security_context_to_sid(buf, size, &sid);
+	if (rc < 0)
+		return rc;
+
+	return security_permissive_sid(sid);
+}
+
 static struct inode *sel_make_inode(struct super_block *sb, int mode)
 {
 	struct inode *ret = new_inode(sb);
@@ -1668,6 +1691,7 @@ static int sel_fill_super(struct super_block *sb, void *data, int silent)
 		[SEL_COMPAT_NET] = {"compat_net", &sel_compat_net_ops, S_IRUGO|S_IWUSR},
 		[SEL_REJECT_UNKNOWN] = {"reject_unknown", &sel_handle_unknown_ops, S_IRUGO},
 		[SEL_DENY_UNKNOWN] = {"deny_unknown", &sel_handle_unknown_ops, S_IRUGO},
+		[SEL_PERMISSIVE] = {"permissive", &transaction_ops, S_IRUGO|S_IWUGO},
 		/* last one */ {""}
 	};
 	ret = simple_fill_super(sb, SELINUX_MAGIC, selinux_files);

[-- Attachment #3: check_permissive.c --]
[-- Type: text/plain, Size: 758 bytes --]

#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <errno.h>
#include <fcntl.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <selinux/selinux.h>

int main(int argc, char *argv[])
{
	const char *path = "/selinux/permissive";
	int fd, rc;

	if (argv[1] == NULL) {
		fprintf(stderr, "usage: %s <context>\n", argv[0]);
		return -1;
	}

	fd = open(path, O_RDWR);
	if (fd < 0) {
		fprintf(stderr, "could not open %s (%s)\n",
			path, strerror(errno));
		return -1;
	}

	rc = write(fd, argv[1], strlen(argv[1]));
	if (rc < 0) {
		fprintf(stderr, "error: write('%s', '%s') (%s)\n",
			path, argv[1], strerror(errno));
		return -1;
	}

	printf("%s is %s permissive domain\n",
	       argv[1], rc ? "a" : "NOT a");

	close(fd);

	return 0;
}

Re: [PATCH] Permissive domain in userspace (Re: Some ideas in SE-PostgreSQL enhancement)

[Stephen Smalley]

On Tue, 2009-03-31 at 10:45 +0900, KaiGai Kohei wrote:
> KaiGai Kohei wrote:
> > If we have an entry something like "/selinux/permissive" to return
> > whether the given domain is permissive or not, I think we don't need
> > to have the flags field on security_compute_av(). It can be checked
> > on the creation of userspace avc entry, and checked it on later access
> > controls.
> 
> The attached patch exposes a new entry in selinuxfs, which enables
> userspace stuff to make a query whether the given context is permissive
> domain, or not.
> If the given context is permissive domain, userspace stuffs can mark
> its entry as a permissive one on creation of avc entries, to avoid
> policy enforcement on permissive domains.
> 
> It now checks security:{check_context} permission, but it should be
> discussed what permission to be checked here.
> 
> The attached check_permissive.c is an example to use the interface.
> 
>   [kaigai@saba ~]$ ./check_permissive staff_u:staff_r:staff_t:s0
>   staff_u:staff_r:staff_t:s0 is a permissive domain
>   [kaigai@saba ~]$ ./check_permissive user_u:user_r:user_t:s0
>   user_u:user_r:user_t:s0 is NOT a permissive domain
> 
> Thanks,

I actually preferred your earlier patch - making the permissive
determination as part of the compute_av.  I'd suggest posting your
earlier kernel patch as a separate posting with the patch inline,
following the usual guidelines, and make sure you cc James and Eric.

-- 
Stephen Smalley
National Security Agency


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

[PATCH] Permissive domain in userspace object manager

[KaiGai Kohei]

This patch enables applications to handle permissive domain correctly.

Since the v2.6.26 kernel, SELinux has supported an idea of permissive
domain which allows certain processes to work as if permissive mode,
even if the global setting is enforcing mode.
However, we don't have an application program interface to inform
what domains are permissive one, and what domains are not.
It means applications focuses on SELinux (XACE/SELinux, SE-PostgreSQL
and so on) cannot handle permissive domain correctly.

This patch add the sixth field (flags) on the reply of the /selinux/access
interface which is used to make an access control decision from userspace.
If the first bit of the flags field is positive, it means the required
access control decision is on permissive domain, so application should
allow any required actions, as the kernel doing.

This patch also has a side benefit. The av_decision.flags is set at
context_struct_compute_av(). It enables to check required permissions
without read_lock(&policy_rwlock).

 Signed-off-by: KaiGai Kohei <kaigai@ak.jp.nec.com>
--
 security/selinux/avc.c              |    2 +-
 security/selinux/include/security.h |    4 +++-
 security/selinux/selinuxfs.c        |    4 ++--
 security/selinux/ss/services.c      |   30 +++++-------------------------
 4 files changed, 11 insertions(+), 29 deletions(-)

diff --git a/security/selinux/avc.c b/security/selinux/avc.c
index 7f9b5fa..b2ab608 100644
--- a/security/selinux/avc.c
+++ b/security/selinux/avc.c
@@ -927,7 +927,7 @@ int avc_has_perm_noaudit(u32 ssid, u32 tsid,
 	if (denied) {
 		if (flags & AVC_STRICT)
 			rc = -EACCES;
-		else if (!selinux_enforcing || security_permissive_sid(ssid))
+		else if (!selinux_enforcing || (avd->flags & AVD_FLAGS_PERMISSIVE))
 			avc_update_node(AVC_CALLBACK_GRANT, requested, ssid,
 					tsid, tclass, avd->seqno);
 		else
diff --git a/security/selinux/include/security.h b/security/selinux/include/security.h
index 5c3434f..a7be3f0 100644
--- a/security/selinux/include/security.h
+++ b/security/selinux/include/security.h
@@ -91,9 +91,11 @@ struct av_decision {
 	u32 auditallow;
 	u32 auditdeny;
 	u32 seqno;
+	u32 flags;
 };

-int security_permissive_sid(u32 sid);
+/* definitions of av_decision.flags */
+#define AVD_FLAGS_PERMISSIVE	0x0001

 int security_compute_av(u32 ssid, u32 tsid,
 	u16 tclass, u32 requested,
diff --git a/security/selinux/selinuxfs.c b/security/selinux/selinuxfs.c
index d3c8b98..4d56ab1 100644
--- a/security/selinux/selinuxfs.c
+++ b/security/selinux/selinuxfs.c
@@ -594,10 +594,10 @@ static ssize_t sel_write_access(struct file *file, char *buf, size_t size)
 		goto out2;

 	length = scnprintf(buf, SIMPLE_TRANSACTION_LIMIT,
-			  "%x %x %x %x %u",
+			  "%x %x %x %x %u %x",
 			  avd.allowed, 0xffffffff,
 			  avd.auditallow, avd.auditdeny,
-			  avd.seqno);
+			  avd.seqno, avd.flags);
 out2:
 	kfree(tcon);
 out:
diff --git a/security/selinux/ss/services.c b/security/selinux/ss/services.c
index deeec6c..500e6f7 100644
--- a/security/selinux/ss/services.c
+++ b/security/selinux/ss/services.c
@@ -410,6 +410,7 @@ static int context_struct_compute_av(struct context *scontext,
 	avd->auditallow = 0;
 	avd->auditdeny = 0xffffffff;
 	avd->seqno = latest_granting;
+	avd->flags = 0;

 	/*
 	 * Check for all the invalid cases.
@@ -528,31 +529,6 @@ inval_class:
 	return 0;
 }

-/*
- * Given a sid find if the type has the permissive flag set
- */
-int security_permissive_sid(u32 sid)
-{
-	struct context *context;
-	u32 type;
-	int rc;
-
-	read_lock(&policy_rwlock);
-
-	context = sidtab_search(&sidtab, sid);
-	BUG_ON(!context);
-
-	type = context->type;
-	/*
-	 * we are intentionally using type here, not type-1, the 0th bit may
-	 * someday indicate that we are globally setting permissive in policy.
-	 */
-	rc = ebitmap_get_bit(&policydb.permissive_map, type);
-
-	read_unlock(&policy_rwlock);
-	return rc;
-}
-
 static int security_validtrans_handle_fail(struct context *ocontext,
 					   struct context *ncontext,
 					   struct context *tcontext,
@@ -767,6 +743,10 @@ int security_compute_av(u32 ssid,

 	rc = context_struct_compute_av(scontext, tcontext, tclass,
 				       requested, avd);
+
+	/* permissive domain? */
+	if (ebitmap_get_bit(&policydb.permissive_map, scontext->type))
+	    avd->flags |= AVD_FLAGS_PERMISSIVE;
 out:
 	read_unlock(&policy_rwlock);
 	return rc;


-- 
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: [PATCH] Permissive domain in userspace object manager

[KaiGai Kohei]

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

The attached patch is for libselinux.
Most of part is unchanged from the previous one, expect for manpage.

KaiGai Kohei wrote:
> This patch enables applications to handle permissive domain correctly.
> 
> Since the v2.6.26 kernel, SELinux has supported an idea of permissive
> domain which allows certain processes to work as if permissive mode,
> even if the global setting is enforcing mode.
> However, we don't have an application program interface to inform
> what domains are permissive one, and what domains are not.
> It means applications focuses on SELinux (XACE/SELinux, SE-PostgreSQL
> and so on) cannot handle permissive domain correctly.
> 
> This patch add the sixth field (flags) on the reply of the /selinux/access
> interface which is used to make an access control decision from userspace.
> If the first bit of the flags field is positive, it means the required
> access control decision is on permissive domain, so application should
> allow any required actions, as the kernel doing.
> 
> This patch also has a side benefit. The av_decision.flags is set at
> context_struct_compute_av(). It enables to check required permissions
> without read_lock(&policy_rwlock).
> 
>  Signed-off-by: KaiGai Kohei <kaigai@ak.jp.nec.com>
> --
>  security/selinux/avc.c              |    2 +-
>  security/selinux/include/security.h |    4 +++-
>  security/selinux/selinuxfs.c        |    4 ++--
>  security/selinux/ss/services.c      |   30 +++++-------------------------
>  4 files changed, 11 insertions(+), 29 deletions(-)
> 
> diff --git a/security/selinux/avc.c b/security/selinux/avc.c
> index 7f9b5fa..b2ab608 100644
> --- a/security/selinux/avc.c
> +++ b/security/selinux/avc.c
> @@ -927,7 +927,7 @@ int avc_has_perm_noaudit(u32 ssid, u32 tsid,
>  	if (denied) {
>  		if (flags & AVC_STRICT)
>  			rc = -EACCES;
> -		else if (!selinux_enforcing || security_permissive_sid(ssid))
> +		else if (!selinux_enforcing || (avd->flags & AVD_FLAGS_PERMISSIVE))
>  			avc_update_node(AVC_CALLBACK_GRANT, requested, ssid,
>  					tsid, tclass, avd->seqno);
>  		else
> diff --git a/security/selinux/include/security.h b/security/selinux/include/security.h
> index 5c3434f..a7be3f0 100644
> --- a/security/selinux/include/security.h
> +++ b/security/selinux/include/security.h
> @@ -91,9 +91,11 @@ struct av_decision {
>  	u32 auditallow;
>  	u32 auditdeny;
>  	u32 seqno;
> +	u32 flags;
>  };
> 
> -int security_permissive_sid(u32 sid);
> +/* definitions of av_decision.flags */
> +#define AVD_FLAGS_PERMISSIVE	0x0001
> 
>  int security_compute_av(u32 ssid, u32 tsid,
>  	u16 tclass, u32 requested,
> diff --git a/security/selinux/selinuxfs.c b/security/selinux/selinuxfs.c
> index d3c8b98..4d56ab1 100644
> --- a/security/selinux/selinuxfs.c
> +++ b/security/selinux/selinuxfs.c
> @@ -594,10 +594,10 @@ static ssize_t sel_write_access(struct file *file, char *buf, size_t size)
>  		goto out2;
> 
>  	length = scnprintf(buf, SIMPLE_TRANSACTION_LIMIT,
> -			  "%x %x %x %x %u",
> +			  "%x %x %x %x %u %x",
>  			  avd.allowed, 0xffffffff,
>  			  avd.auditallow, avd.auditdeny,
> -			  avd.seqno);
> +			  avd.seqno, avd.flags);
>  out2:
>  	kfree(tcon);
>  out:
> diff --git a/security/selinux/ss/services.c b/security/selinux/ss/services.c
> index deeec6c..500e6f7 100644
> --- a/security/selinux/ss/services.c
> +++ b/security/selinux/ss/services.c
> @@ -410,6 +410,7 @@ static int context_struct_compute_av(struct context *scontext,
>  	avd->auditallow = 0;
>  	avd->auditdeny = 0xffffffff;
>  	avd->seqno = latest_granting;
> +	avd->flags = 0;
> 
>  	/*
>  	 * Check for all the invalid cases.
> @@ -528,31 +529,6 @@ inval_class:
>  	return 0;
>  }
> 
> -/*
> - * Given a sid find if the type has the permissive flag set
> - */
> -int security_permissive_sid(u32 sid)
> -{
> -	struct context *context;
> -	u32 type;
> -	int rc;
> -
> -	read_lock(&policy_rwlock);
> -
> -	context = sidtab_search(&sidtab, sid);
> -	BUG_ON(!context);
> -
> -	type = context->type;
> -	/*
> -	 * we are intentionally using type here, not type-1, the 0th bit may
> -	 * someday indicate that we are globally setting permissive in policy.
> -	 */
> -	rc = ebitmap_get_bit(&policydb.permissive_map, type);
> -
> -	read_unlock(&policy_rwlock);
> -	return rc;
> -}
> -
>  static int security_validtrans_handle_fail(struct context *ocontext,
>  					   struct context *ncontext,
>  					   struct context *tcontext,
> @@ -767,6 +743,10 @@ int security_compute_av(u32 ssid,
> 
>  	rc = context_struct_compute_av(scontext, tcontext, tclass,
>  				       requested, avd);
> +
> +	/* permissive domain? */
> +	if (ebitmap_get_bit(&policydb.permissive_map, scontext->type))
> +	    avd->flags |= AVD_FLAGS_PERMISSIVE;
>  out:
>  	read_unlock(&policy_rwlock);
>  	return rc;
> 
> 


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

[-- Attachment #2: libselinux-userspace-permissive-domain.2.patch --]
[-- Type: text/x-patch, Size: 10147 bytes --]

 Signed-off-by: KaiGai Kohei <kaigai@ak.jp.nec.com>
--
 libselinux/include/selinux/selinux.h            |   15 ++++
 libselinux/man/man3/security_compute_av.3       |   23 ++++++-
 libselinux/man/man3/security_compute_av_flags.3 |    1 +
 libselinux/src/avc.c                            |   22 +++--
 libselinux/src/compute_av.c                     |   90 +++++++++++++++++++----
 libselinux/src/selinux_internal.h               |    2 +
 6 files changed, 128 insertions(+), 25 deletions(-)

diff --git a/libselinux/include/selinux/selinux.h b/libselinux/include/selinux/selinux.h
index fab083e..7030f38 100644
--- a/libselinux/include/selinux/selinux.h
+++ b/libselinux/include/selinux/selinux.h
@@ -130,8 +130,12 @@ struct av_decision {
 	access_vector_t auditallow;
 	access_vector_t auditdeny;
 	unsigned int seqno;
+	unsigned int flags;
 };
 
+/* Definitions of av_decision.flags */
+#define SELINUX_AVD_FLAGS_PERMISSIVE	0x0001
+
 /* Structure for passing options, used by AVC and label subsystems */
 struct selinux_opt {
 	int type;
@@ -180,6 +184,17 @@ extern int security_compute_av_raw(security_context_t scon,
 				   access_vector_t requested,
 				   struct av_decision *avd);
 
+extern int security_compute_av_flags(security_context_t scon,
+				     security_context_t tcon,
+				     security_class_t tclass,
+				     access_vector_t requested,
+				     struct av_decision *avd);
+extern int security_compute_av_flags_raw(security_context_t scon,
+					 security_context_t tcon,
+					 security_class_t tclass,
+					 access_vector_t requested,
+					 struct av_decision *avd);
+
 /* Compute a labeling decision and set *newcon to refer to it.
    Caller must free via freecon. */
 extern int security_compute_create(security_context_t scon,
diff --git a/libselinux/man/man3/security_compute_av.3 b/libselinux/man/man3/security_compute_av.3
index 885719f..e759c4b 100644
--- a/libselinux/man/man3/security_compute_av.3
+++ b/libselinux/man/man3/security_compute_av.3
@@ -1,6 +1,6 @@
 .TH "security_compute_av" "3" "1 January 2004" "russell@coker.com.au" "SELinux API documentation"
 .SH "NAME"
-security_compute_av, security_compute_create, security_compute_relabel,
+security_compute_av, security_compute_av_flags, security_compute_create, security_compute_relabel,
 security_compute_member, security_compute_user, security_get_initial_context \- query
 the SELinux policy database in the kernel.
 
@@ -11,6 +11,8 @@ the SELinux policy database in the kernel.
 .sp
 .BI "int security_compute_av(security_context_t "scon ", security_context_t "tcon ", security_class_t "tclass ", access_vector_t "requested ", struct av_decision *" avd );
 .sp
+.BI "int security_compute_av_flags(security_context_t "scon ", security_context_t "tcon ", security_class_t "tclass ", access_vector_t "requested ", struct av_decision *" avd );
+.sp
 .BI "int security_compute_create(security_context_t "scon ", security_context_t "tcon ", security_class_t "tclass ", security_context_t *" newcon );
 .sp
 .BI "int security_compute_relabel(security_context_t "scon ", security_context_t "tcon ", security_class_t "tclass ", security_context_t *" newcon );
@@ -35,6 +37,25 @@ via class
 with the
 .B requested
 access vector. See the cron source for a usage example.
+Please note that it does not set up the
+.B flags
+of
+.B av_decision
+because of binary compatibility.
+
+.B security_compute_av_flags
+provides identical functionality with
+.B security_compute_av
+expect for the
+.B flags
+of
+.B av_decision
+to be set correctly.
+Now we have only a flag:
+.B SELINUX_AVD_FLAGS_PERMISSIVE
+which means the returned
+.B av_decision
+is computed on permissive domain.
 
 .B security_compute_create
 is used to compute a context to use for labeling a new object in a particular
diff --git a/libselinux/man/man3/security_compute_av_flags.3 b/libselinux/man/man3/security_compute_av_flags.3
index e69de29..a60bca4 100644
--- a/libselinux/man/man3/security_compute_av_flags.3
+++ b/libselinux/man/man3/security_compute_av_flags.3
@@ -0,0 +1 @@
+.so man3/security_compute_av.3
diff --git a/libselinux/src/avc.c b/libselinux/src/avc.c
index 1545dd3..f0e2d33 100644
--- a/libselinux/src/avc.c
+++ b/libselinux/src/avc.c
@@ -849,9 +849,9 @@ int avc_has_perm_noaudit(security_id_t ssid,
 				rc = -1;
 				goto out;
 			}
-			rc = security_compute_av_raw(ssid->ctx, tsid->ctx,
-						     tclass, requested,
-						     &entry.avd);
+			rc = security_compute_av_flags_raw(ssid->ctx, tsid->ctx,
+							   tclass, requested,
+							   &entry.avd);
 			if (rc)
 				goto out;
 			rc = avc_insert(ssid, tsid, tclass, &entry, aeref);
@@ -867,11 +867,13 @@ int avc_has_perm_noaudit(security_id_t ssid,
 	denied = requested & ~(ae->avd.allowed);
 
 	if (!requested || denied) {
-		if (avc_enforcing) {
+		if (!avc_enforcing ||
+		    (ae->avd.flags & SELINUX_AVD_FLAGS_PERMISSIVE))
+			ae->avd.allowed |= requested;
+		else {
 			errno = EACCES;
 			rc = -1;
-		} else
-			ae->avd.allowed |= requested;
+		}
 	}
 
       out:
@@ -885,9 +887,11 @@ int avc_has_perm(security_id_t ssid, security_id_t tsid,
 		 security_class_t tclass, access_vector_t requested,
 		 struct avc_entry_ref *aeref, void *auditdata)
 {
-	struct av_decision avd = { 0, 0, 0, 0, 0 };
+	struct av_decision avd;
 	int errsave, rc;
 
+	memset(&avd, 0, sizeof(avd));
+
 	rc = avc_has_perm_noaudit(ssid, tsid, tclass, requested, aeref, &avd);
 	errsave = errno;
 	avc_audit(ssid, tsid, tclass, requested, &avd, rc, auditdata);
@@ -917,8 +921,8 @@ int avc_compute_create(security_id_t ssid,  security_id_t tsid,
 	rc = avc_lookup(ssid, tsid, tclass, 0, &aeref);
 	if (rc) {
 		/* need to make a cache entry for this tuple */
-		rc = security_compute_av_raw(ssid->ctx, tsid->ctx,
-					     tclass, 0, &entry.avd);
+		rc = security_compute_av_flags_raw(ssid->ctx, tsid->ctx,
+						   tclass, 0, &entry.avd);
 		if (rc)
 			goto out;
 		rc = avc_insert(ssid, tsid, tclass, &entry, &aeref);
diff --git a/libselinux/src/compute_av.c b/libselinux/src/compute_av.c
index 45cd0db..a821d17 100644
--- a/libselinux/src/compute_av.c
+++ b/libselinux/src/compute_av.c
@@ -10,10 +10,11 @@
 #include "policy.h"
 #include "mapping.h"
 
-int security_compute_av_raw(security_context_t scon,
-			    security_context_t tcon,
-			    security_class_t tclass,
-			    access_vector_t requested, struct av_decision *avd)
+int security_compute_av_flags_raw(security_context_t scon,
+				  security_context_t tcon,
+				  security_class_t tclass,
+				  access_vector_t requested,
+				  struct av_decision *avd)
 {
 	char path[PATH_MAX];
 	char *buf;
@@ -49,12 +50,15 @@ int security_compute_av_raw(security_context_t scon,
 	if (ret < 0)
 		goto out2;
 
-	if (sscanf(buf, "%x %x %x %x %u", &avd->allowed,
-		   &avd->decided, &avd->auditallow, &avd->auditdeny,
-		   &avd->seqno) != 5) {
+	ret = sscanf(buf, "%x %x %x %x %u %x",
+		     &avd->allowed, &avd->decided,
+		     &avd->auditallow, &avd->auditdeny,
+		     &avd->seqno, &avd->flags);
+	if (ret < 5) {
 		ret = -1;
 		goto out2;
-	}
+	} else if (ret < 6)
+		avd->flags = 0;
 
 	map_decision(tclass, avd);
 
@@ -66,16 +70,44 @@ int security_compute_av_raw(security_context_t scon,
 	return ret;
 }
 
-hidden_def(security_compute_av_raw)
+hidden_def(security_compute_av_flags_raw)
 
-int security_compute_av(security_context_t scon,
-			security_context_t tcon,
-			security_class_t tclass,
-			access_vector_t requested, struct av_decision *avd)
+int security_compute_av_raw(security_context_t scon,
+			    security_context_t tcon,
+			    security_class_t tclass,
+			    access_vector_t requested,
+			    struct av_decision *avd)
 {
+	struct av_decision lavd;
 	int ret;
+
+	ret = security_compute_av_flags_raw(scon, tcon, tclass,
+					    requested, &lavd);
+	if (ret == 0) {
+		avd->allowed = lavd.allowed;
+		avd->decided = lavd.decided;
+		avd->auditallow = lavd.auditallow;
+		avd->auditdeny = lavd.auditdeny;
+		avd->seqno = lavd.seqno;
+		/* NOTE:
+		 * We should not return avd->flags via the interface
+		 * due to the binary compatibility.
+		 */
+	}
+	return ret;
+}
+
+hidden_def(security_compute_av_raw)
+
+int security_compute_av_flags(security_context_t scon,
+			      security_context_t tcon,
+			      security_class_t tclass,
+			      access_vector_t requested,
+			      struct av_decision *avd)
+{
 	security_context_t rscon = scon;
 	security_context_t rtcon = tcon;
+	int ret;
 
 	if (selinux_trans_to_raw_context(scon, &rscon))
 		return -1;
@@ -83,8 +115,8 @@ int security_compute_av(security_context_t scon,
 		freecon(rscon);
 		return -1;
 	}
-
-	ret = security_compute_av_raw(rscon, rtcon, tclass, requested, avd);
+	ret = security_compute_av_flags_raw(rscon, rtcon, tclass,
+					    requested, avd);
 
 	freecon(rscon);
 	freecon(rtcon);
@@ -92,4 +124,32 @@ int security_compute_av(security_context_t scon,
 	return ret;
 }
 
+hidden_def(security_compute_av_flags)
+
+int security_compute_av(security_context_t scon,
+			security_context_t tcon,
+			security_class_t tclass,
+			access_vector_t requested, struct av_decision *avd)
+{
+	struct av_decision lavd;
+	int ret;
+
+	ret = security_compute_av_flags(scon, tcon, tclass,
+					requested, &lavd);
+	if (ret == 0)
+	{
+		avd->allowed = lavd.allowed;
+		avd->decided = lavd.decided;
+		avd->auditallow = lavd.auditallow;
+		avd->auditdeny = lavd.auditdeny;
+		avd->seqno = lavd.seqno;
+		/* NOTE:
+		 * We should not return avd->flags via the interface
+		 * due to the binary compatibility.
+		 */
+	}
+
+	return ret;
+}
+
 hidden_def(security_compute_av)
diff --git a/libselinux/src/selinux_internal.h b/libselinux/src/selinux_internal.h
index 8b4c6d4..cfb18a5 100644
--- a/libselinux/src/selinux_internal.h
+++ b/libselinux/src/selinux_internal.h
@@ -16,6 +16,8 @@ hidden_proto(selinux_mkload_policy)
     hidden_proto(security_canonicalize_context_raw)
     hidden_proto(security_compute_av)
     hidden_proto(security_compute_av_raw)
+    hidden_proto(security_compute_av_flags)
+    hidden_proto(security_compute_av_flags_raw)
     hidden_proto(security_compute_user)
     hidden_proto(security_compute_user_raw)
     hidden_proto(security_compute_create)

Correct manner to handler undefined classes/permissions? (Re: Some ideas in SE-PostgreSQL enhancement)

[KaiGai Kohei]

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

This topic has been left for a week.

How should it be handled when we cannot find required classes or
permissions in the security policy?

The kernel allows anything or nothing for undefined object classes
based on policydb.allow_unknown. However, if the security policy
does not have a definition of the required access vector, it is
always denied (due to lack of explicit permission).

My preference is filling up the undefined access vectores with
policydb.allow_unknown. It seems to me quite natural.

Userspace object managers also have same issue.
Now it's unclear for me what is the preferable behavior.
For example, how should it handle the db_database:{superuser}
on the older security policy?

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.

Re: [PATCH] Permissive domain in userspace object manager

[Stephen Smalley]

On Wed, 2009-04-01 at 10:07 +0900, KaiGai Kohei wrote:
> This patch enables applications to handle permissive domain correctly.
> 
> Since the v2.6.26 kernel, SELinux has supported an idea of permissive
> domain which allows certain processes to work as if permissive mode,
> even if the global setting is enforcing mode.
> However, we don't have an application program interface to inform
> what domains are permissive one, and what domains are not.
> It means applications focuses on SELinux (XACE/SELinux, SE-PostgreSQL
> and so on) cannot handle permissive domain correctly.
> 
> This patch add the sixth field (flags) on the reply of the /selinux/access
> interface which is used to make an access control decision from userspace.
> If the first bit of the flags field is positive, it means the required
> access control decision is on permissive domain, so application should
> allow any required actions, as the kernel doing.
> 
> This patch also has a side benefit. The av_decision.flags is set at
> context_struct_compute_av(). It enables to check required permissions
> without read_lock(&policy_rwlock).
> 
>  Signed-off-by: KaiGai Kohei <kaigai@ak.jp.nec.com>

Acked-by:  Stephen Smalley <sds@tycho.nsa.gov>

> --
>  security/selinux/avc.c              |    2 +-
>  security/selinux/include/security.h |    4 +++-
>  security/selinux/selinuxfs.c        |    4 ++--
>  security/selinux/ss/services.c      |   30 +++++-------------------------
>  4 files changed, 11 insertions(+), 29 deletions(-)
> 
> diff --git a/security/selinux/avc.c b/security/selinux/avc.c
> index 7f9b5fa..b2ab608 100644
> --- a/security/selinux/avc.c
> +++ b/security/selinux/avc.c
> @@ -927,7 +927,7 @@ int avc_has_perm_noaudit(u32 ssid, u32 tsid,
>  	if (denied) {
>  		if (flags & AVC_STRICT)
>  			rc = -EACCES;
> -		else if (!selinux_enforcing || security_permissive_sid(ssid))
> +		else if (!selinux_enforcing || (avd->flags & AVD_FLAGS_PERMISSIVE))
>  			avc_update_node(AVC_CALLBACK_GRANT, requested, ssid,
>  					tsid, tclass, avd->seqno);
>  		else
> diff --git a/security/selinux/include/security.h b/security/selinux/include/security.h
> index 5c3434f..a7be3f0 100644
> --- a/security/selinux/include/security.h
> +++ b/security/selinux/include/security.h
> @@ -91,9 +91,11 @@ struct av_decision {
>  	u32 auditallow;
>  	u32 auditdeny;
>  	u32 seqno;
> +	u32 flags;
>  };
> 
> -int security_permissive_sid(u32 sid);
> +/* definitions of av_decision.flags */
> +#define AVD_FLAGS_PERMISSIVE	0x0001
> 
>  int security_compute_av(u32 ssid, u32 tsid,
>  	u16 tclass, u32 requested,
> diff --git a/security/selinux/selinuxfs.c b/security/selinux/selinuxfs.c
> index d3c8b98..4d56ab1 100644
> --- a/security/selinux/selinuxfs.c
> +++ b/security/selinux/selinuxfs.c
> @@ -594,10 +594,10 @@ static ssize_t sel_write_access(struct file *file, char *buf, size_t size)
>  		goto out2;
> 
>  	length = scnprintf(buf, SIMPLE_TRANSACTION_LIMIT,
> -			  "%x %x %x %x %u",
> +			  "%x %x %x %x %u %x",
>  			  avd.allowed, 0xffffffff,
>  			  avd.auditallow, avd.auditdeny,
> -			  avd.seqno);
> +			  avd.seqno, avd.flags);
>  out2:
>  	kfree(tcon);
>  out:
> diff --git a/security/selinux/ss/services.c b/security/selinux/ss/services.c
> index deeec6c..500e6f7 100644
> --- a/security/selinux/ss/services.c
> +++ b/security/selinux/ss/services.c
> @@ -410,6 +410,7 @@ static int context_struct_compute_av(struct context *scontext,
>  	avd->auditallow = 0;
>  	avd->auditdeny = 0xffffffff;
>  	avd->seqno = latest_granting;
> +	avd->flags = 0;
> 
>  	/*
>  	 * Check for all the invalid cases.
> @@ -528,31 +529,6 @@ inval_class:
>  	return 0;
>  }
> 
> -/*
> - * Given a sid find if the type has the permissive flag set
> - */
> -int security_permissive_sid(u32 sid)
> -{
> -	struct context *context;
> -	u32 type;
> -	int rc;
> -
> -	read_lock(&policy_rwlock);
> -
> -	context = sidtab_search(&sidtab, sid);
> -	BUG_ON(!context);
> -
> -	type = context->type;
> -	/*
> -	 * we are intentionally using type here, not type-1, the 0th bit may
> -	 * someday indicate that we are globally setting permissive in policy.
> -	 */
> -	rc = ebitmap_get_bit(&policydb.permissive_map, type);
> -
> -	read_unlock(&policy_rwlock);
> -	return rc;
> -}
> -
>  static int security_validtrans_handle_fail(struct context *ocontext,
>  					   struct context *ncontext,
>  					   struct context *tcontext,
> @@ -767,6 +743,10 @@ int security_compute_av(u32 ssid,
> 
>  	rc = context_struct_compute_av(scontext, tcontext, tclass,
>  				       requested, avd);
> +
> +	/* permissive domain? */
> +	if (ebitmap_get_bit(&policydb.permissive_map, scontext->type))
> +	    avd->flags |= AVD_FLAGS_PERMISSIVE;
>  out:
>  	read_unlock(&policy_rwlock);
>  	return rc;
> 
> 
-- 
Stephen Smalley
National Security Agency


--
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: Correct manner to handler undefined classes/permissions? (Re: Some ideas in SE-PostgreSQL enhancement)

[Stephen Smalley]

On Wed, 2009-04-01 at 16:26 +0900, KaiGai Kohei wrote:
> > 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.
> 
> This topic has been left for a week.
> 
> How should it be handled when we cannot find required classes or
> permissions in the security policy?
> 
> The kernel allows anything or nothing for undefined object classes
> based on policydb.allow_unknown. However, if the security policy
> does not have a definition of the required access vector, it is
> always denied (due to lack of explicit permission).
> 
> My preference is filling up the undefined access vectores with
> policydb.allow_unknown. It seems to me quite natural.

I believe that is what the kernel does during policy load, by defining
the policydb->undefined_perms[] array.

> Userspace object managers also have same issue.
> Now it's unclear for me what is the preferable behavior.
> For example, how should it handle the db_database:{superuser}
> on the older security policy?
> 
> Thanks,
-- 
Stephen Smalley
National Security Agency


--
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: [PATCH] Permissive domain in userspace object manager

[Eric Paris]

On Wed, 2009-04-01 at 08:34 -0400, Stephen Smalley wrote:
> On Wed, 2009-04-01 at 10:07 +0900, KaiGai Kohei wrote:
> > This patch enables applications to handle permissive domain correctly.
> > 
> > Since the v2.6.26 kernel, SELinux has supported an idea of permissive
> > domain which allows certain processes to work as if permissive mode,
> > even if the global setting is enforcing mode.
> > However, we don't have an application program interface to inform
> > what domains are permissive one, and what domains are not.
> > It means applications focuses on SELinux (XACE/SELinux, SE-PostgreSQL
> > and so on) cannot handle permissive domain correctly.
> > 
> > This patch add the sixth field (flags) on the reply of the /selinux/access
> > interface which is used to make an access control decision from userspace.
> > If the first bit of the flags field is positive, it means the required
> > access control decision is on permissive domain, so application should
> > allow any required actions, as the kernel doing.
> > 
> > This patch also has a side benefit. The av_decision.flags is set at
> > context_struct_compute_av(). It enables to check required permissions
> > without read_lock(&policy_rwlock).
> > 
> >  Signed-off-by: KaiGai Kohei <kaigai@ak.jp.nec.com>
> 
> Acked-by:  Stephen Smalley <sds@tycho.nsa.gov>

I initially didn't want to use the space (u32 for every avc_node) or
waste the time doing the ebitmap check when 99% of the time on a
properly functioning system we aren't ever going to use this result.

But your code is a lot cleaner and really an ebitmap check on compute
can't be all that bad.  On my local machine we are talking about wasting
maybe 3k in memory (policy is over 3M so what's 3k?)  All in all, it
looks ok to me.

Acked-by: Eric Paris <eparis@redhat.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: [PATCH] Permissive domain in userspace object manager

[James Morris]

On Wed, 1 Apr 2009, KaiGai Kohei wrote:

> This patch enables applications to handle permissive domain correctly.
> 
> Since the v2.6.26 kernel, SELinux has supported an idea of permissive
> domain which allows certain processes to work as if permissive mode,
> even if the global setting is enforcing mode.
> However, we don't have an application program interface to inform
> what domains are permissive one, and what domains are not.
> It means applications focuses on SELinux (XACE/SELinux, SE-PostgreSQL
> and so on) cannot handle permissive domain correctly.
> 
> This patch add the sixth field (flags) on the reply of the /selinux/access
> interface which is used to make an access control decision from userspace.
> If the first bit of the flags field is positive, it means the required
> access control decision is on permissive domain, so application should
> allow any required actions, as the kernel doing.
> 
> This patch also has a side benefit. The av_decision.flags is set at
> context_struct_compute_av(). It enables to check required permissions
> without read_lock(&policy_rwlock).
> 
>  Signed-off-by: KaiGai Kohei <kaigai@ak.jp.nec.com>

Applied.


-- 
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: Correct manner to handler undefined classes/permissions? (Re: Some ideas in SE-PostgreSQL enhancement)

[KaiGai Kohei]

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

Stephen Smalley wrote:
>> My preference is filling up the undefined access vectores with
>> policydb.allow_unknown. It seems to me quite natural.
> 
> I believe that is what the kernel does during policy load, by defining
> the policydb->undefined_perms[] array.

Oops, I misread the kernel code.

>> Userspace object managers also have same issue.
>> Now it's unclear for me what is the preferable behavior.
>> For example, how should it handle the db_database:{superuser}
>> on the older security policy?

It is useful for userspace object manager, if libselinux has an
interface something like: int security_deny_unknown(void);

This interface can suggest applications preferable behavior when
string_to_security_class() or string_to_av_perm() returns invalid
value which means the security policy does not define required
ones.

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

[-- Attachment #2: libselinux-security_deny_unknown.patch --]
[-- Type: text/x-patch, Size: 3415 bytes --]

 Signed-off-by: KaiGai Kohei <kaigai@ak.jp.nec.com>
--
 libselinux/include/selinux/selinux.h        |    3 ++
 libselinux/man/man3/security_deny_unknown.3 |   21 ++++++++++++++
 libselinux/src/deny_unknown.c               |   40 +++++++++++++++++++++++++++
 libselinux/src/selinux_internal.h           |    1 +
 4 files changed, 65 insertions(+), 0 deletions(-)

diff --git a/libselinux/include/selinux/selinux.h b/libselinux/include/selinux/selinux.h
index fab083e..01a8912 100644
--- a/libselinux/include/selinux/selinux.h
+++ b/libselinux/include/selinux/selinux.h
@@ -301,6 +301,9 @@ extern int security_disable(void);
 /* Get the policy version number. */
 extern int security_policyvers(void);
 
+/* Get the behavior for undefined classes/permissions */
+extern int security_deny_unknown(void);
+
 /* Get the boolean names */
 extern int security_get_boolean_names(char ***names, int *len);
 
diff --git a/libselinux/man/man3/security_deny_unknown.3 b/libselinux/man/man3/security_deny_unknown.3
index e69de29..1fce3eb 100644
--- a/libselinux/man/man3/security_deny_unknown.3
+++ b/libselinux/man/man3/security_deny_unknown.3
@@ -0,0 +1,21 @@
+.TH "security_deny_unknown" "3" "2 April 2009" "kaigai@ak.jp.nec.com" "SELinux API documentation"
+.SH "NAME"
+security_deny_unknown \- get the preferable behavior on undefined object classes and access vectores
+.SH "SYNOPSIS"
+.B #include <selinux/selinux.h>
+.sp
+.B int security_deny_unknown(void);
+
+.SH "DESCRIPTION"
+.B security_deny_unknown
+returns 0 if SELinux allows undefined actions or actions on undefined object classes, 1 if not allowed, and -1 on error.
+Application should perform according to the result when
+.B string_to_security_class
+or
+.B string_to_av_perm
+return invalid value which means the current policy does not support required ones.
+
+.SH "SEE ALSO"
+.BR string_to_security_class (3),
+.BR string_to_av_perm (3),
+.BR selinux (8)
diff --git a/libselinux/src/deny_unknown.c b/libselinux/src/deny_unknown.c
index e69de29..c93998a 100644
--- a/libselinux/src/deny_unknown.c
+++ b/libselinux/src/deny_unknown.c
@@ -0,0 +1,40 @@
+#include <unistd.h>
+#include <sys/types.h>
+#include <fcntl.h>
+#include <stdlib.h>
+#include <errno.h>
+#include <string.h>
+#include "selinux_internal.h"
+#include "policy.h"
+#include <stdio.h>
+#include <limits.h>
+
+int security_deny_unknown(void)
+{
+	int fd, ret, deny_unknown = 0;
+	char path[PATH_MAX];
+	char buf[20];
+
+	if (!selinux_mnt) {
+		errno = ENOENT;
+		return -1;
+	}
+
+	snprintf(path, sizeof(path), "%s/deny_unknown", selinux_mnt);
+	fd = open(path, O_RDONLY);
+	if (fd < 0)
+		return -1;
+
+	memset(buf, 0, sizeof(buf));
+	ret = read(fd, buf, sizeof(buf) - 1);
+	close(fd);
+	if (ret < 0)
+		return -1;
+
+	if (sscanf(buf, "%d", &deny_unknown) != 1)
+		return -1;
+
+	return deny_unknown;
+}
+
+hidden_def(security_deny_unknown);
diff --git a/libselinux/src/selinux_internal.h b/libselinux/src/selinux_internal.h
index 8b4c6d4..5c551d4 100644
--- a/libselinux/src/selinux_internal.h
+++ b/libselinux/src/selinux_internal.h
@@ -51,6 +51,7 @@ hidden_proto(selinux_mkload_policy)
     hidden_proto(setsockcreatecon_raw)
     hidden_proto(security_getenforce)
     hidden_proto(security_setenforce)
+    hidden_proto(security_deny_unknown)
     hidden_proto(selinux_binary_policy_path)
     hidden_proto(selinux_default_context_path)
     hidden_proto(selinux_securetty_types_path)

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

[Eamon Walsh]

KaiGai Kohei wrote:
> KaiGai Kohei wrote:
>   
>> My preference is the later one:
>>   TYPE_TRANSITION <subject context> <server context> : <class> <new context>;
>>
>> In addition, an idea of configuration file can be considerable to set up
>> the default context of database objects, though I considered it is not
>> necessary in the past discussion.
>> If a user want to work the database server process as an unconfined domain,
>> like a legacy "disable_xxxx_trans" boolean doing, the <server context> as
>> the target of TYPE_TRANSITION breaks all the correct labeling.
>>
>> If we have a /etc/selinux/$POLICYTYPE/contexts/db_{sepgsql|rubix}, as follows,
>> it can be used to specify the default context of special purpose database
>> object such as schemas to store temporary database objects, not only the
>> context of database as the root of type transition.
>> ------------
>> database    *             system_u:object_r:sepgsql_db_t:s0
>> schema      pg_temp_*     system_u:object_r:sepgsql_temp_schema_t:s0
>>   :             :            :
>> ------------
>>
>> The libselinux has selabel_lookup(3) interface to implement them
>> for various kind of objects.
>>     
>
> The attached patch is a proof of the concept.
> It adds the forth backend of selabel_lookup(3) interface.
>
> Under the enhancement, we should the following rules to determine what
> security context is assigned on the newly created database object.
>
> 1. An explicitly specified security context by users.
>    e.g)  CREATE TABLE t (a int, b text)
>              SECURITY_LABEL = 'system_u:object_r:sepgsql_table_t:SystemHigh';
>
> 2. A matched entry in the configuration file which can be lookup up
>    by selabel_lookup(3).
>    e.g)  schema  pg_temp_*  system_u:object_r:sepgsql_temp_schema_t:s0
>                  ^^^^^^^^^ --> if the new object name and type are matched.
>
> 3. The result of security_compute_av() or avc_compute_create() which can
>    return the result of TYPE_TRANSITION rules.
>
> The second step is newly suggested in this patch.
> Needless to say, the determinded security context has to be checked
> by the security policy.
>
>   
>> One concern is performance hit. If we need to open/lookup/close the file
>> for each INSERT statement, its pain will be unacceptable.
>>     
>
> This patch does not support db_tuple class, because of headach in performance
> and its characteristic that database tuples have no name to identify itself.
>
> Thanks,
>   


First, regarding the problem of labeling the top-level (root) database
object, why can't you specify this through a command line argument (to
"createdb") or extra argument to CREATE DATABASE? I see above that a
"SECURITY_LABEL" arg is supported for CREATE TABLE. Just use something
similar for CREATE DATABASE and default to the <subject> <subject> type
transition if none is specified.


But let's step back and take a look at how the file system uses file
contexts. Files are labeled in three ways:

1. The normal, preferred way, through a type transition on a subject
(domain) and target (parent directory). The database analog to this:
through a type transition on a subject (domain) and target (parent
table, schema, or other object).

2. For files that are NOT persistent, such as /proc and /sys, by
genfscon rules, which are basically the same as file_contexts. So if
there are non-persistent database objects (such as the pg_temp
mentioned) and there really is no parent object to label from in a type
transition, using selabel lookups could make sense.

3. By a trusted relabeler, such as fixfiles. Here again the proposal may
be useful, if you wanted to keep a default set of labels and have some
offline relabeler program that would go through the whole database and
fix up the labels. This program would be some trusted client that
changes all the labels.


So other than a single case, which is non-persistent database objects,
selabel lookups should not be required. By analogy, the filesystem does
not consult the file_contexts file every time a new file is created. In
your priority list defined above, step 2 (selabel) should be after step
3 (type transition) and should be qualified with "only when type
transition is not possible because object is non-persistent."

Does this make sense or am I missing something fundamental about the
database environment?



-- 
Eamon Walsh <ewalsh@tycho.nsa.gov>
National Security Agency


--
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: Some ideas in SE-PostgreSQL enhancement (Re: The status of SE-PostgreSQL)

[KaiGai Kohei]

Eamon Walsh wrote:
> KaiGai Kohei wrote:
>> KaiGai Kohei wrote:
>>   
>>> My preference is the later one:
>>>   TYPE_TRANSITION <subject context> <server context> : <class> <new context>;
>>>
>>> In addition, an idea of configuration file can be considerable to set up
>>> the default context of database objects, though I considered it is not
>>> necessary in the past discussion.
>>> If a user want to work the database server process as an unconfined domain,
>>> like a legacy "disable_xxxx_trans" boolean doing, the <server context> as
>>> the target of TYPE_TRANSITION breaks all the correct labeling.
>>>
>>> If we have a /etc/selinux/$POLICYTYPE/contexts/db_{sepgsql|rubix}, as follows,
>>> it can be used to specify the default context of special purpose database
>>> object such as schemas to store temporary database objects, not only the
>>> context of database as the root of type transition.
>>> ------------
>>> database    *             system_u:object_r:sepgsql_db_t:s0
>>> schema      pg_temp_*     system_u:object_r:sepgsql_temp_schema_t:s0
>>>   :             :            :
>>> ------------
>>>
>>> The libselinux has selabel_lookup(3) interface to implement them
>>> for various kind of objects.
>>>     
>> The attached patch is a proof of the concept.
>> It adds the forth backend of selabel_lookup(3) interface.
>>
>> Under the enhancement, we should the following rules to determine what
>> security context is assigned on the newly created database object.
>>
>> 1. An explicitly specified security context by users.
>>    e.g)  CREATE TABLE t (a int, b text)
>>              SECURITY_LABEL = 'system_u:object_r:sepgsql_table_t:SystemHigh';
>>
>> 2. A matched entry in the configuration file which can be lookup up
>>    by selabel_lookup(3).
>>    e.g)  schema  pg_temp_*  system_u:object_r:sepgsql_temp_schema_t:s0
>>                  ^^^^^^^^^ --> if the new object name and type are matched.
>>
>> 3. The result of security_compute_av() or avc_compute_create() which can
>>    return the result of TYPE_TRANSITION rules.
>>
>> The second step is newly suggested in this patch.
>> Needless to say, the determinded security context has to be checked
>> by the security policy.
>>
>>   
>>> One concern is performance hit. If we need to open/lookup/close the file
>>> for each INSERT statement, its pain will be unacceptable.
>>>     
>> This patch does not support db_tuple class, because of headach in performance
>> and its characteristic that database tuples have no name to identify itself.
>>
>> Thanks,
>>   
> 
> 
> First, regarding the problem of labeling the top-level (root) database
> object, why can't you specify this through a command line argument (to
> "createdb") or extra argument to CREATE DATABASE? I see above that a
> "SECURITY_LABEL" arg is supported for CREATE TABLE. Just use something
> similar for CREATE DATABASE and default to the <subject> <subject> type
> transition if none is specified.

It is not preferable to enforce the "SECURITY_LABEL=xxx" option for all
the case due to the SQL compatibility, so I would like to focus on the
default behavior.
The <subject> <subject> type transition works correctly to compute the
root of the database objects, if we have only SELinux aware DBMSs.
However, at least, RUBIX appeared in other than SE-PostgreSQL.

So, we want to determine the security context of the root object depending
on the database obejct manager.

I have one other idea which applies a common security policy for all the
SE- DBMSs, but I guess it is not good because of differences in their
specifications and functionalities.
(E.g PostgreSQL creates schema objects under a database directly, but
RUBIX has a catalog object between them.)

> But let's step back and take a look at how the file system uses file
> contexts. Files are labeled in three ways:
> 
> 1. The normal, preferred way, through a type transition on a subject
> (domain) and target (parent directory). The database analog to this:
> through a type transition on a subject (domain) and target (parent
> table, schema, or other object).

Yes, we can basically cover all the database object which have its
parent object. But the root database obejct does not have its parent.
It is the first issue.

> 2. For files that are NOT persistent, such as /proc and /sys, by
> genfscon rules, which are basically the same as file_contexts. So if
> there are non-persistent database objects (such as the pg_temp
> mentioned) and there really is no parent object to label from in a type
> transition, using selabel lookups could make sense.

I think the setfscreatecon is better analogy than the genfscon.
A schema object is deployed under a database object, so we can compute
a default security context using type transition rules, but I also want
to set a characteristic default on pg_temp due to its feature.
It is the second issue how individual security contexts can be set on
objects within same object class.
(Or, defines db_schema_temp class? I'm not sure whether other DBMSs
shares the concept of schamas to store temporary objects.)

> 3. By a trusted relabeler, such as fixfiles. Here again the proposal may
> be useful, if you wanted to keep a default set of labels and have some
> offline relabeler program that would go through the whole database and
> fix up the labels. This program would be some trusted client that
> changes all the labels.

Yes, we don't have this kind of utility now, but I believe a similar
command will be desirable.

> So other than a single case, which is non-persistent database objects,
> selabel lookups should not be required. By analogy, the filesystem does
> not consult the file_contexts file every time a new file is created. In
> your priority list defined above, step 2 (selabel) should be after step
> 3 (type transition) and should be qualified with "only when type
> transition is not possible because object is non-persistent."
> 
> Does this make sense or am I missing something fundamental about the
> database environment?

The selabel_lookup(3) for database tries to solve two issues in same time.
The one is the default to the root of database objects which does not have
any parent object. The other is also the default to certain characteristic
objects.
If we can consider the selabel as analogy of setfscreatecon (automatically
set up) for the second issue, I don't think its priority should be moved
to the behind of type transition.

An aside, the pg_temp schema is implicitly created when CREATE TEMP TABLE
statement is given, so we cannot apply SECURITY_LABEL=xxx here. :(

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.

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

[Eamon Walsh]

KaiGai Kohei wrote:
> Eamon Walsh wrote:
>   
>> KaiGai Kohei wrote:
>>     
>>> KaiGai Kohei wrote:
>>>   
>>>       
>>>> My preference is the later one:
>>>>   TYPE_TRANSITION <subject context> <server context> : <class> <new context>;
>>>>
>>>> In addition, an idea of configuration file can be considerable to set up
>>>> the default context of database objects, though I considered it is not
>>>> necessary in the past discussion.
>>>> If a user want to work the database server process as an unconfined domain,
>>>> like a legacy "disable_xxxx_trans" boolean doing, the <server context> as
>>>> the target of TYPE_TRANSITION breaks all the correct labeling.
>>>>
>>>> If we have a /etc/selinux/$POLICYTYPE/contexts/db_{sepgsql|rubix}, as follows,
>>>> it can be used to specify the default context of special purpose database
>>>> object such as schemas to store temporary database objects, not only the
>>>> context of database as the root of type transition.
>>>> ------------
>>>> database    *             system_u:object_r:sepgsql_db_t:s0
>>>> schema      pg_temp_*     system_u:object_r:sepgsql_temp_schema_t:s0
>>>>   :             :            :
>>>> ------------
>>>>
>>>> The libselinux has selabel_lookup(3) interface to implement them
>>>> for various kind of objects.
>>>>     
>>>>         
>>> The attached patch is a proof of the concept.
>>> It adds the forth backend of selabel_lookup(3) interface.
>>>
>>> Under the enhancement, we should the following rules to determine what
>>> security context is assigned on the newly created database object.
>>>
>>> 1. An explicitly specified security context by users.
>>>    e.g)  CREATE TABLE t (a int, b text)
>>>              SECURITY_LABEL = 'system_u:object_r:sepgsql_table_t:SystemHigh';
>>>
>>> 2. A matched entry in the configuration file which can be lookup up
>>>    by selabel_lookup(3).
>>>    e.g)  schema  pg_temp_*  system_u:object_r:sepgsql_temp_schema_t:s0
>>>                  ^^^^^^^^^ --> if the new object name and type are matched.
>>>
>>> 3. The result of security_compute_av() or avc_compute_create() which can
>>>    return the result of TYPE_TRANSITION rules.
>>>
>>> The second step is newly suggested in this patch.
>>> Needless to say, the determinded security context has to be checked
>>> by the security policy.
>>>
>>>   
>>>       
>>>> One concern is performance hit. If we need to open/lookup/close the file
>>>> for each INSERT statement, its pain will be unacceptable.
>>>>     
>>>>         
>>> This patch does not support db_tuple class, because of headach in performance
>>> and its characteristic that database tuples have no name to identify itself.
>>>
>>> Thanks,
>>>   
>>>       
>> First, regarding the problem of labeling the top-level (root) database
>> object, why can't you specify this through a command line argument (to
>> "createdb") or extra argument to CREATE DATABASE? I see above that a
>> "SECURITY_LABEL" arg is supported for CREATE TABLE. Just use something
>> similar for CREATE DATABASE and default to the <subject> <subject> type
>> transition if none is specified.
>>     
>
> It is not preferable to enforce the "SECURITY_LABEL=xxx" option for all
> the case due to the SQL compatibility, so I would like to focus on the
> default behavior.
> The <subject> <subject> type transition works correctly to compute the
> root of the database objects, if we have only SELinux aware DBMSs.
> However, at least, RUBIX appeared in other than SE-PostgreSQL.
>
> So, we want to determine the security context of the root object depending
> on the database obejct manager.
>
> I have one other idea which applies a common security policy for all the
> SE- DBMSs, but I guess it is not good because of differences in their
> specifications and functionalities.
> (E.g PostgreSQL creates schema objects under a database directly, but
> RUBIX has a catalog object between them.)
>
>   
>> But let's step back and take a look at how the file system uses file
>> contexts. Files are labeled in three ways:
>>
>> 1. The normal, preferred way, through a type transition on a subject
>> (domain) and target (parent directory). The database analog to this:
>> through a type transition on a subject (domain) and target (parent
>> table, schema, or other object).
>>     
>
> Yes, we can basically cover all the database object which have its
> parent object. But the root database obejct does not have its parent.
> It is the first issue.
>   

How are databases stored on disk? Is there a file or directory that
could serve as the parent object?


>   
>> 2. For files that are NOT persistent, such as /proc and /sys, by
>> genfscon rules, which are basically the same as file_contexts. So if
>> there are non-persistent database objects (such as the pg_temp
>> mentioned) and there really is no parent object to label from in a type
>> transition, using selabel lookups could make sense.
>>     
>
> I think the setfscreatecon is better analogy than the genfscon.
>   

I don't agree here - setfscreatecon is analogous to SECURITY_LABEL=xxx,
where the client (not the object manager) can override the default
context for its own purposes. Label lookups, on the other hand, come
from a fixed configuration file in /etc/selinux and they are done by the
object manager, not the client. It's more like a matchpathcon() or a
genfscon.

That said, I don't have a strong objection to this and I do think the
selabel support has some valid uses for Postgres.


> A schema object is deployed under a database object, so we can compute
> a default security context using type transition rules, but I also want
> to set a characteristic default on pg_temp due to its feature.
> It is the second issue how individual security contexts can be set on
> objects within same object class.
>   

SE-Postgres should be able to detect when a temp table is being created
and only do the selabel lookup in that case.

Actually, if the temp tables are visible to other clients you may need
to do an selabel lookup followed by a type transition. Such as
temp_schema_t (from lookup) -> type transition -> user_temp_schema_t.
Otherwise the temp table could be accessible to other domains. Another
alternative would be to use UBAC. If the temp table is not shared
between sessions then it doesn't matter.




> (Or, defines db_schema_temp class? I'm not sure whether other DBMSs
> shares the concept of schamas to store temporary objects.)
>   

This may work. Whether to define a separate object class depends on the
complexity it would add to the policy writing and object manager code,
versus looking it up in selabel. I wouldn't worry about whether other
DBMS would use the class. If they don't need it they can simply ignore it.


>   
>> 3. By a trusted relabeler, such as fixfiles. Here again the proposal may
>> be useful, if you wanted to keep a default set of labels and have some
>> offline relabeler program that would go through the whole database and
>> fix up the labels. This program would be some trusted client that
>> changes all the labels.
>>     
>
> Yes, we don't have this kind of utility now, but I believe a similar
> command will be desirable.
>
>   
>> So other than a single case, which is non-persistent database objects,
>> selabel lookups should not be required. By analogy, the filesystem does
>> not consult the file_contexts file every time a new file is created. In
>> your priority list defined above, step 2 (selabel) should be after step
>> 3 (type transition) and should be qualified with "only when type
>> transition is not possible because object is non-persistent."
>>
>> Does this make sense or am I missing something fundamental about the
>> database environment?
>>     
>
> The selabel_lookup(3) for database tries to solve two issues in same time.
> The one is the default to the root of database objects which does not have
> any parent object. The other is also the default to certain characteristic
> objects.
> If we can consider the selabel as analogy of setfscreatecon (automatically
> set up) for the second issue, I don't think its priority should be moved
> to the behind of type transition.
>
> An aside, the pg_temp schema is implicitly created when CREATE TEMP TABLE
> statement is given, so we cannot apply SECURITY_LABEL=xxx here. :(
>   

Understood.

I'll probably push the patch next week sometime, unless I hear otherwise.



-- 
Eamon Walsh <ewalsh@tycho.nsa.gov>
National Security Agency


--
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: Some ideas in SE-PostgreSQL enhancement (Re: The status of SE-PostgreSQL)

[KaiGai Kohei]

Sorry for late reply due to the spring vacation season in Japan.

>>> But let's step back and take a look at how the file system uses file
>>> contexts. Files are labeled in three ways:
>>>
>>> 1. The normal, preferred way, through a type transition on a subject
>>> (domain) and target (parent directory). The database analog to this:
>>> through a type transition on a subject (domain) and target (parent
>>> table, schema, or other object).
>>>     
>> Yes, we can basically cover all the database object which have its
>> parent object. But the root database obejct does not have its parent.
>> It is the first issue.
>>   
> 
> How are databases stored on disk? Is there a file or directory that
> could serve as the parent object?

In PostgreSQL, all the database files are indeed stored in a single root
directory ($PGDATA), however, it depends on the current implementation.

>>> 2. For files that are NOT persistent, such as /proc and /sys, by
>>> genfscon rules, which are basically the same as file_contexts. So if
>>> there are non-persistent database objects (such as the pg_temp
>>> mentioned) and there really is no parent object to label from in a type
>>> transition, using selabel lookups could make sense.
>>>     
>> I think the setfscreatecon is better analogy than the genfscon.
>>   
> 
> I don't agree here - setfscreatecon is analogous to SECURITY_LABEL=xxx,
> where the client (not the object manager) can override the default
> context for its own purposes. Label lookups, on the other hand, come
> from a fixed configuration file in /etc/selinux and they are done by the
> object manager, not the client. It's more like a matchpathcon() or a
> genfscon.
> 
> That said, I don't have a strong objection to this and I do think the
> selabel support has some valid uses for Postgres.

Hmm... it seems to me you are correct.
This behavior of selbalel_lookup() may not have appropriate analogy in
filesystem.

>> A schema object is deployed under a database object, so we can compute
>> a default security context using type transition rules, but I also want
>> to set a characteristic default on pg_temp due to its feature.
>> It is the second issue how individual security contexts can be set on
>> objects within same object class.
>> 
> 
> SE-Postgres should be able to detect when a temp table is being created
> and only do the selabel lookup in that case.
> 
> Actually, if the temp tables are visible to other clients you may need
> to do an selabel lookup followed by a type transition. Such as
> temp_schema_t (from lookup) -> type transition -> user_temp_schema_t.
> Otherwise the temp table could be accessible to other domains. Another
> alternative would be to use UBAC. If the temp table is not shared
> between sessions then it doesn't matter.

It seems to me this kind of special case handling can give us confusion...

>> (Or, defines db_schema_temp class? I'm not sure whether other DBMSs
>> shares the concept of schamas to store temporary objects.)
>>   
> 
> This may work. Whether to define a separate object class depends on the
> complexity it would add to the policy writing and object manager code,
> versus looking it up in selabel. I wouldn't worry about whether other
> DBMS would use the class. If they don't need it they can simply ignore it.

Indeed, we discussed about differences between SE-PostgreSQL and
RUBIX before, and agreed to ignore db_catalog class in SE-PostgreSQL.

At least, it has a benefit compared to selabel in UBAC handling,
so it might be necessary to consider the option.

>> The selabel_lookup(3) for database tries to solve two issues in same time.
>> The one is the default to the root of database objects which does not have
>> any parent object. The other is also the default to certain characteristic
>> objects.
>> If we can consider the selabel as analogy of setfscreatecon (automatically
>> set up) for the second issue, I don't think its priority should be moved
>> to the behind of type transition.
>>
>> An aside, the pg_temp schema is implicitly created when CREATE TEMP TABLE
>> statement is given, so we cannot apply SECURITY_LABEL=xxx here. :(
>>   
> 
> Understood.
> 
> I'll probably push the patch next week sometime, unless I hear otherwise.

Please wait for a while.

As I noted before, the selabel patch tries to solve two matters.
 - The default label for db_database class.
 - The default label for temporary schame.

If we can have db_schema_temp class, the only remaining matter is the default
in db_database class. It can be solved using a file which store a default label
for SE-PostgreSQL's db_database objects, as if run_init uses initrc_context.

It makes sense for me, and clear its behavior from the viewpoint of the analogy.

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.

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

[KaiGai Kohei]

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

KaiGai Kohei wrote:
> Please wait for a while.
> 
> As I noted before, the selabel patch tries to solve two matters.
>  - The default label for db_database class.
>  - The default label for temporary schame.
> 
> If we can have db_schema_temp class, the only remaining matter is the default
> in db_database class. It can be solved using a file which store a default label
> for SE-PostgreSQL's db_database objects, as if run_init uses initrc_context.
> 
> It makes sense for me, and clear its behavior from the viewpoint of the analogy.

I would like to reserve /etc/selinux/$POLICYTYPE/context/sepgsql_context to
store the default security context for db_database object in SE-PostgreSQL.
(I guess RUBIX can store its default in rubix_context in same way.)

The attached patch adds a new API: selinux_sepgsql_context_path() which
returns the pathname of the configuration file.

Please apply this one, instead of the patch for selabel_lookup().

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

[-- Attachment #2: libselinux-selinux_sepgsql_context_path.patch --]
[-- Type: text/x-patch, Size: 2858 bytes --]

[PATCH] add selinux_sepgsql_context_path()

 The /etc/selinux/$POLICYTYPE/context/sepgsql_context can store a default
 security context of db_database class object in SE-PostgreSQL.
 This patch add a new API: selinux_sepgsql_context_path() which returns
 a pathname of the configuration file.

 Signed-off-by: KaiGai Kohei <kaigai@ak.jp.nec.com>
--
 libselinux/include/selinux/selinux.h |    1 +
 libselinux/src/file_path_suffixes.h  |    1 +
 libselinux/src/selinux_config.c      |    9 ++++++++-
 libselinux/src/selinux_internal.h    |    1 +
 4 files changed, 11 insertions(+), 1 deletions(-)

diff --git a/libselinux/include/selinux/selinux.h b/libselinux/include/selinux/selinux.h
index 0a0b195..8adbbcf 100644
--- a/libselinux/include/selinux/selinux.h
+++ b/libselinux/include/selinux/selinux.h
@@ -492,6 +492,7 @@ extern const char *selinux_users_path(void);
 extern const char *selinux_usersconf_path(void);
 extern const char *selinux_translations_path(void);
 extern const char *selinux_colors_path(void);
+extern const char *selinux_sepgsql_context_path(void);
 extern const char *selinux_netfilter_context_path(void);
 extern const char *selinux_path(void);
 
diff --git a/libselinux/src/file_path_suffixes.h b/libselinux/src/file_path_suffixes.h
index 8d207c9..b4e13d2 100644
--- a/libselinux/src/file_path_suffixes.h
+++ b/libselinux/src/file_path_suffixes.h
@@ -20,3 +20,4 @@ S_(BINPOLICY, "/policy/policy")
     S_(FILE_CONTEXTS_LOCAL, "/contexts/files/file_contexts.local")
     S_(X_CONTEXTS, "/contexts/x_contexts")
     S_(COLORS, "/secolor.conf")
+    S_(SEPGSQL_CONTEXT, "/contexts/sepgsql_context")
diff --git a/libselinux/src/selinux_config.c b/libselinux/src/selinux_config.c
index dec5426..620a2ce 100644
--- a/libselinux/src/selinux_config.c
+++ b/libselinux/src/selinux_config.c
@@ -40,7 +40,8 @@
 #define SECURETTY_TYPES   18
 #define X_CONTEXTS        19
 #define COLORS            20
-#define NEL               21
+#define SEPGSQL_CONTEXT   21
+#define NEL               22
 
 /* New layout is relative to SELINUXDIR/policytype. */
 static char *file_paths[NEL];
@@ -391,3 +392,9 @@ const char *selinux_x_context_path()
 }
 
 hidden_def(selinux_x_context_path)
+
+const char *selinux_sepgsql_context_path()
+{
+	return get_path(SEPGSQL_CONTEXT);
+}
+hidden_def(selinux_sepgsql_context_path)
diff --git a/libselinux/src/selinux_internal.h b/libselinux/src/selinux_internal.h
index 24c1396..2d2beb8 100644
--- a/libselinux/src/selinux_internal.h
+++ b/libselinux/src/selinux_internal.h
@@ -77,6 +77,7 @@ hidden_proto(selinux_mkload_policy)
     hidden_proto(selinux_usersconf_path);
 hidden_proto(selinux_translations_path);
 hidden_proto(selinux_colors_path);
+hidden_proto(selinux_sepgsql_context_path);
 hidden_proto(selinux_getenforcemode);
 hidden_proto(selinux_getpolicytype);
 hidden_proto(selinux_raw_to_trans_context);