The status of SE-PostgreSQL

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 <[email protected]>

Some updates on SE-posgreSql.

2009/3/23 KaiGai Kohei <[email protected]>

Here is a bad news.

Quoted 82 lines

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.

Quoted 8 lines

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

Thanks,
--
OSS Platform Development Division, NEC
KaiGai Kohei <[email protected]>

--
Shaz

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,

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

Quoted 88 lines · 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,

Quoted 7 lines · Andy Warner

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,

Quoted 88 lines

Quoted 87 lines · 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,

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,

Quoted 120 lines · KaiGai Kohei

Quoted 8 lines · Andy Warner

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,

Quoted 90 lines

Quoted 88 lines · 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,

Quoted 23 lines · 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>, ...

Quoted 9 lines

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.

Quoted 217 lines

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,

Quoted 120 lines · KaiGai Kohei

Quoted 8 lines · Andy Warner

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,

Quoted 90 lines

Quoted 88 lines · 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,

Quoted 35 lines · Andy Warner

Quoted 23 lines · 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>, ...

Quoted 10 lines

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

Quoted 7 lines

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.

From my rather limited understanding of SELinux I do not believe that is

Quoted 3 lines

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.

Quoted 3 lines

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.

Quoted 8 lines

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,

Quoted 223 lines

Quoted 223 lines

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,

Quoted 125 lines · KaiGai Kohei

Quoted 9 lines · Andy Warner

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,

Quoted 92 lines

Quoted 89 lines · 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,

Quoted 45 lines · KaiGai Kohei

Quoted 35 lines · Andy Warner

Quoted 23 lines · 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>, ...

Quoted 10 lines

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

Quoted 7 lines

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.

Quoted 10 lines

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.

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?

Quoted 257 lines

Quoted 3 lines

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.

Quoted 3 lines

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.

Quoted 8 lines

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,

Quoted 223 lines

Quoted 223 lines

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,

Quoted 125 lines · KaiGai Kohei

Quoted 9 lines · Andy Warner

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,

Quoted 92 lines

Quoted 89 lines · 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,

Quoted 61 lines · Andy Warner

Quoted 48 lines · KaiGai Kohei

Quoted 37 lines · Andy Warner

Quoted 23 lines · 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>, ...

Quoted 11 lines

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

Quoted 8 lines

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.

Quoted 11 lines

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.

Quoted 6 lines

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?

Quoted 6 lines

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.

Quoted 9 lines

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.

Quoted 9 lines

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.

Quoted 4 lines

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

From an SQL perspective, the general difference between a schema and a

Thanks,

Quoted 266 lines

Quoted 266 lines

Quoted 4 lines

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.

Quoted 4 lines

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.

Quoted 9 lines

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,

Quoted 230 lines

Quoted 230 lines

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,

Quoted 130 lines · KaiGai Kohei

Quoted 10 lines · Andy Warner

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,

Quoted 94 lines

Quoted 90 lines · 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,

Quoted 19 lines

Quoted 8 lines

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.

Quoted 4 lines

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.

Quoted 10 lines

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

Quoted 23 lines · 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>, ...

Quoted 9 lines

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.

Quoted 35 lines · Andy Warner

Quoted 23 lines · 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>, ...

Quoted 10 lines

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

Quoted 8 lines

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 [email protected] with the words "unsubscribe selinux" without quotes as the message.

Quoted 46 lines · Joshua Brindle

Quoted 35 lines · Andy Warner

Quoted 23 lines · 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>, ...

Quoted 10 lines

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

Quoted 8 lines

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.

Quoted 4 lines

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.

Quoted 62 lines · Andy Warner

Quoted 49 lines · Joshua Brindle

Quoted 37 lines · Andy Warner

Quoted 23 lines · 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>, ...

Quoted 11 lines

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

Quoted 9 lines

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.

Quoted 5 lines

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.

Quoted 11 lines

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.

Quoted 3 lines

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.

Quoted 7 lines

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

Quoted 8 lines

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.

Quoted 4 lines

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.

Quoted 4 lines

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.

Quoted 22 lines · Andy Warner

Quoted 3 lines

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.

Quoted 7 lines

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

Quoted 9 lines

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

Quoted 11 lines

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.

Quoted 7 lines

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}

Quoted 9 lines

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.

Quoted 6 lines

Quoted 6 lines

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.

Quoted 13 lines

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.

Quoted 6 lines

Quoted 6 lines

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.

Quoted 6 lines

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)

Quoted 9 lines

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 [email protected] with the words "unsubscribe selinux" without quotes as the message.

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

Quoted 1 line

Quoted 16 lines

Quoted 6 lines

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}

Quoted 9 lines

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.

Quoted 7 lines

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.

Quoted 6 lines

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?

Quoted 20 lines

Quoted 6 lines

Quoted 6 lines

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.

Quoted 13 lines

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.

Quoted 6 lines

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.

Quoted 13 lines

Quoted 6 lines

Quoted 6 lines

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.

Quoted 6 lines

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.

Quoted 4 lines

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.

Quoted 1 line

Quoted 13 lines

Quoted 8 lines

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.

Quoted 6 lines

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.

Quoted 1 line

--

Quoted 11 lines · Andy Warner

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

Quoted 2 lines

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

Quoted 24 lines

Quoted 16 lines

Quoted 6 lines

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}

Quoted 10 lines

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.

Quoted 8 lines

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.

Quoted 13 lines

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.

Quoted 7 lines

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?

Quoted 6 lines

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)

Quoted 51 lines

Quoted 22 lines

Quoted 8 lines

Quoted 8 lines

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.

Quoted 14 lines

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.

Quoted 7 lines

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.

Quoted 15 lines

Quoted 8 lines

Quoted 8 lines

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.

Quoted 7 lines

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.

Quoted 5 lines

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)

Quoted 10 lines

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.

Quoted 2 lines

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.

Quoted 31 lines

Quoted 14 lines

Quoted 10 lines

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.

Quoted 7 lines

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.

Quoted 2 lines

--

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.

Quoted 1 line

Quoted 6 lines

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.

Quoted 12 lines · Andy Warner

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:

Quoted 9 lines

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.

Quoted 8 lines

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;

Quoted 5 lines

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.

Quoted 10 lines

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>

Quoted 6 lines

Quoted 6 lines

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.

Quoted 3 lines

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.

Quoted 12 lines · Andy Warner

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:

Quoted 8 lines

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.

Quoted 8 lines

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;

Quoted 4 lines

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.

Quoted 8 lines

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?

Quoted 23 lines · Joshua Brindle

Quoted 12 lines · Andy Warner

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:

Quoted 9 lines

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:

Quoted 5 lines

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.

Quoted 8 lines

Quoted 8 lines

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;

Quoted 8 lines

Quoted 5 lines

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.

Quoted 4 lines

Quoted 4 lines

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

type_transition postgresql_t postgresql_t : db_database sepgsql_db_t;

Quoted 8 lines

Quoted 5 lines

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,

Quoted 8 lines

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.

Quoted 6 lines

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.

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.

Quoted 15 lines · KaiGai Kohei

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

Quoted 8 lines

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.

Quoted 3 lines

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,

Quoted 20 lines

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.

Quoted 7 lines

Quoted 3 lines

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.

From an analogy of filesystem, if we can put a valid security context on

Quoted 15 lines · KaiGai Kohei

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

Quoted 8 lines

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.

Quoted 3 lines

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,

Quoted 48 lines · KaiGai Kohei

Quoted 15 lines · KaiGai Kohei

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

Quoted 8 lines

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.

Quoted 8 lines

Quoted 3 lines

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?

Quoted 63 lines · Eamon Walsh

Quoted 51 lines · KaiGai Kohei

Quoted 15 lines · KaiGai Kohei

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

Quoted 9 lines

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.

Quoted 10 lines

Quoted 4 lines

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,

Quoted 7 lines

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

Quoted 8 lines

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.

Quoted 7 lines

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

Quoted 7 lines

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.

Quoted 10 lines

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

Quoted 8 lines

Quoted 8 lines

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

Quoted 4 lines

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?

Quoted 8 lines

Quoted 6 lines

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.

Quoted 6 lines

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.

Quoted 3 lines

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

Quoted 8 lines

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.

Quoted 3 lines

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.

Quoted 25 lines

Quoted 8 lines

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.

Quoted 7 lines

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

Quoted 4 lines

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,

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.

Quoted 14 lines

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

Quoted 9 lines

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,

Quoted 14 lines

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

Quoted 9 lines

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,

Quoted 29 lines · KaiGai Kohei

Quoted 14 lines

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

Quoted 9 lines

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.

Quoted 9 lines

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

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?

Quoted 13 lines

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.

Quoted 6 lines

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

[snip]

Quoted 20 lines

Quoted 13 lines

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.

Quoted 6 lines

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?

Quoted 6 lines

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.

Quoted 2 lines

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,

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.

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.

Quoted 24 lines · KaiGai Kohei

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

Quoted 5 lines

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.

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.

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.

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

I look forward to playing with this :)

4. Permissive domain in userspace

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

Quoted 5 lines · KaiGai Kohei

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,

Quoted 31 lines · KaiGai Kohei

Quoted 5 lines · KaiGai Kohei

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.

Quoted 9 lines

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

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.

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.

Quoted 5 lines · KaiGai Kohei

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,

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 <[email protected]>

--

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

security/selinux/avc.c +1 -1

index 7f9b5fa..b2ab608 100644
@@ -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

security/selinux/include/security.h +3 -1

index 5c3434f..a7be3f0 100644
@@ -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,

security/selinux/selinuxfs.c +2 -2

index d3c8b98..4d56ab1 100644
@@ -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:

security/selinux/ss/services.c +5 -25

index deeec6c..500e6f7 100644
@@ -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;

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 <[email protected]>

--

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

security/selinux/avc.c +1 -1

index 7f9b5fa..b2ab608 100644
@@ -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

security/selinux/include/security.h +3 -1

index 5c3434f..a7be3f0 100644
@@ -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,

security/selinux/selinuxfs.c +2 -2

index d3c8b98..4d56ab1 100644
@@ -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:

security/selinux/ss/services.c +5 -25

index deeec6c..500e6f7 100644
@@ -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;

Quoted 16 lines · 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.

Quoted 5 lines

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 <[email protected]>

Acked-by Stephen Smalley <[email protected]>

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 <[email protected]>

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,

Quoted 7 lines · 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

Quoted 9 lines

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.

Quoted 29 lines

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.

Quoted 5 lines

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?

Quoted 11 lines

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.