libselinux: add support for /contexts/postgresql_contexts

Hello,

The attached patch enables to obtain the default security context of newly created database, defined at /etc/selinux/*/contexts/postgresql_contexts .

The format is as follows:
--------
#
# Config file for SE-PostgreSQL
#
# <domain of client> <type of newly created database>
unconfined_t sepgsql_db_t
* sepgsql_db_t
--------

'*' means default security context, if given key is not matched for any entry.

This API requires the security context of client as a key, and it returns a security context to be attached for a newly created database. It has a type field defined in the right-hand of config file, and inherits user and lower-range field of given security context as a key.

e.g)
selabel_lookup(sehandle, &context, "user_u:user_r:user_t:s0", 0); returns "user_u:object_r:sepgsql_db_t:s0".

This patch is implemented based on the previous discussion at:
http://marc.info/?l=selinux&m=120999566809541&w=2

Thanks,

Signed-off-by KaiGai Kohei <[email protected]>

--

 include/selinux/label.h   |    2
 include/selinux/selinux.h |    1
 src/file_path_suffixes.h  |    1
 src/label.c               |   20 +++-
 src/label_internal.h      |    4
 src/label_pgsql.c         |  209 ++++++++++++++++++++++++++++++++++++++++++++++
 src/selinux_config.c      |    9 +
 src/selinux_internal.h    |    1
 8 files changed, 243 insertions(+), 4 deletions(-)

Quoted 17 lines · KaiGai Kohei

Hello,

The attached patch enables to obtain the default security context of newly created database, defined at /etc/selinux/*/contexts/postgresql_contexts .

The format is as follows:
--------
#
# Config file for SE-PostgreSQL
#
# <domain of client> <type of newly created database>
unconfined_t sepgsql_db_t
* sepgsql_db_t
--------

'*' means default security context, if given key is not matched for any entry.

Quoted 8 lines

This API requires the security context of client as a key, and it returns a security context to be attached for a newly created database. It has a type field defined in the right-hand of config file, and inherits user and lower-range field of given security context as a key.

e.g)
selabel_lookup(sehandle, &context, "user_u:user_r:user_t:s0", 0); returns "user_u:object_r:sepgsql_db_t:s0".

Chris is investigating the use of roles on objects in order to provide more fully featured RBAC support without requiring use of per-role domains. Hardcoding the use of object_r won't be future compatible for that situation, and more generally we don't want to hardcode policy information in libselinux at all.

I'm also unclear as to why type_transition rules aren't a better way of expressing the above, although I know you've been discussing this with Chris for some time. Logically I'd expect the client domain to be the source type of the transition, and the type for the newly created database to be the new/result type of the transition. What to use as the target type is less clear; we'd have a similar issue if we were to use type_transitions for e.g. sockets. It could either be the client domain both as source and target (self relationship, no related object) or the client domain as source and the object manager domain as target.

Chris, what is the objection to using type transitions here, as they are for labeling new objects and this seems to fit that situation?

Quoted 43 lines · Stephen Smalley

Quoted 17 lines · KaiGai Kohei

Hello,

The attached patch enables to obtain the default security context of newly created database, defined at /etc/selinux/*/contexts/postgresql_contexts .

The format is as follows:
--------
#
# Config file for SE-PostgreSQL
#
# <domain of client> <type of newly created database>
unconfined_t sepgsql_db_t
* sepgsql_db_t
--------

'*' means default security context, if given key is not matched for any entry.

Quoted 8 lines

This API requires the security context of client as a key, and it returns a security context to be attached for a newly created database. It has a type field defined in the right-hand of config file, and inherits user and lower-range field of given security context as a key.

e.g)
selabel_lookup(sehandle, &context, "user_u:user_r:user_t:s0", 0); returns "user_u:object_r:sepgsql_db_t:s0".

Chris is investigating the use of roles on objects in order to provide more fully featured RBAC support without requiring use of per-role domains. Hardcoding the use of object_r won't be future compatible for that situation, and more generally we don't want to hardcode policy information in libselinux at all.

I'm also unclear as to why type_transition rules aren't a better way of expressing the above, although I know you've been discussing this with Chris for some time. Logically I'd expect the client domain to be the source type of the transition, and the type for the newly created database to be the new/result type of the transition. What to use as the target type is less clear; we'd have a similar issue if we were to use type_transitions for e.g. sockets. It could either be the client domain both as source and target (self relationship, no related object) or the client domain as source and the object manager domain as target.

Quoted 2 lines

Chris, what is the objection to using type transitions here, as they are for labeling new objects and this seems to fit that situation?

I think KaiGai took my idea a little to far. My issue was just to have postgres determine what the default label for its objects are via postgresql_contexts. A derived role/type still makes sense to be stated via (type|role)_transition. I suspect there was confusion on this point. I mainly had an issue with statements like:

type_transition postgresql_t postgresql_t:db_database sepgsql_db_t; type_transition postgresql_t sepgsql_database_type:db_table sepgsql_sysobj_t; type_transition postgresql_t sepgsql_database_type:db_procedure sepgsql_proc_t; type_transition postgresql_t sepgsql_database_type:db_blob sepgsql_blob_t; type_transition sepgsql_client_type postgresql_t:db_database sepgsql_db_t;

which I feel should be instead be expressed in a postgresql_contexts file that says the default context for a database is ::seqpgsql_db_t, default context for table is ::sepgsql_sysobj_t, etc.

This makes perfect sense staying as a type_transition in the policy:

type_transition staff_t sepgsql_sysobj_t:db_tuple staff_sepgsql_sysobj_t;

Quoted 53 lines · Christopher J. PeBenito

Quoted 43 lines · Stephen Smalley

Quoted 17 lines · KaiGai Kohei

Hello,

The attached patch enables to obtain the default security context of newly created database, defined at /etc/selinux/*/contexts/postgresql_contexts .

The format is as follows:
--------
#
# Config file for SE-PostgreSQL
#
# <domain of client> <type of newly created database>
unconfined_t sepgsql_db_t
* sepgsql_db_t
--------

'*' means default security context, if given key is not matched for any entry.

Quoted 8 lines

This API requires the security context of client as a key, and it returns a security context to be attached for a newly created database. It has a type field defined in the right-hand of config file, and inherits user and lower-range field of given security context as a key.

e.g)
selabel_lookup(sehandle, &context, "user_u:user_r:user_t:s0", 0); returns "user_u:object_r:sepgsql_db_t:s0".

Chris is investigating the use of roles on objects in order to provide more fully featured RBAC support without requiring use of per-role domains. Hardcoding the use of object_r won't be future compatible for that situation, and more generally we don't want to hardcode policy information in libselinux at all.

I'm also unclear as to why type_transition rules aren't a better way of expressing the above, although I know you've been discussing this with Chris for some time. Logically I'd expect the client domain to be the source type of the transition, and the type for the newly created database to be the new/result type of the transition. What to use as the target type is less clear; we'd have a similar issue if we were to use type_transitions for e.g. sockets. It could either be the client domain both as source and target (self relationship, no related object) or the client domain as source and the object manager domain as target.

Quoted 2 lines

Chris, what is the objection to using type transitions here, as they are for labeling new objects and this seems to fit that situation?

I think KaiGai took my idea a little to far. My issue was just to have postgres determine what the default label for its objects are via postgresql_contexts. A derived role/type still makes sense to be stated via (type|role)_transition. I suspect there was confusion on this point. I mainly had an issue with statements like:

Quoted 5 lines

type_transition postgresql_t postgresql_t:db_database sepgsql_db_t; type_transition postgresql_t sepgsql_database_type:db_table sepgsql_sysobj_t; type_transition postgresql_t sepgsql_database_type:db_procedure sepgsql_proc_t; type_transition postgresql_t sepgsql_database_type:db_blob sepgsql_blob_t; type_transition sepgsql_client_type postgresql_t:db_database sepgsql_db_t;

The first four statements don't make sense to me; the last one does make sense (i.e. when a postgres client creates a new database, where the only related "object" in view is that object manager's context, label the new database with sepgsql_db_t). That last instance seems valid as a way of expressing types for new databases; the first four statements seem to be more suited to this postgres contexts configuration (as they are independent of client domain entirely).

Quoted 8 lines

which I feel should be instead be expressed in a postgresql_contexts file that says the default context for a database is ::seqpgsql_db_t, default context for table is ::sepgsql_sysobj_t, etc.

This makes perfect sense staying as a type_transition in the policy:

type_transition staff_t sepgsql_sysobj_t:db_tuple staff_sepgsql_sysobj_t;

Quoted 60 lines · Stephen Smalley

Quoted 53 lines · Christopher J. PeBenito

Quoted 43 lines · Stephen Smalley

Quoted 17 lines · KaiGai Kohei

Hello,

The attached patch enables to obtain the default security context of newly created database, defined at /etc/selinux/*/contexts/postgresql_contexts .

The format is as follows:
--------
#
# Config file for SE-PostgreSQL
#
# <domain of client> <type of newly created database>
unconfined_t sepgsql_db_t
* sepgsql_db_t
--------

'*' means default security context, if given key is not matched for any entry.

Quoted 8 lines

This API requires the security context of client as a key, and it returns a security context to be attached for a newly created database. It has a type field defined in the right-hand of config file, and inherits user and lower-range field of given security context as a key.

e.g)
selabel_lookup(sehandle, &context, "user_u:user_r:user_t:s0", 0); returns "user_u:object_r:sepgsql_db_t:s0".

Chris is investigating the use of roles on objects in order to provide more fully featured RBAC support without requiring use of per-role domains. Hardcoding the use of object_r won't be future compatible for that situation, and more generally we don't want to hardcode policy information in libselinux at all.

I'm also unclear as to why type_transition rules aren't a better way of expressing the above, although I know you've been discussing this with Chris for some time. Logically I'd expect the client domain to be the source type of the transition, and the type for the newly created database to be the new/result type of the transition. What to use as the target type is less clear; we'd have a similar issue if we were to use type_transitions for e.g. sockets. It could either be the client domain both as source and target (self relationship, no related object) or the client domain as source and the object manager domain as target.

Quoted 2 lines

Chris, what is the objection to using type transitions here, as they are for labeling new objects and this seems to fit that situation?

I think KaiGai took my idea a little to far. My issue was just to have postgres determine what the default label for its objects are via postgresql_contexts. A derived role/type still makes sense to be stated via (type|role)_transition. I suspect there was confusion on this point. I mainly had an issue with statements like:

Quoted 5 lines

type_transition postgresql_t postgresql_t:db_database sepgsql_db_t; type_transition postgresql_t sepgsql_database_type:db_table sepgsql_sysobj_t; type_transition postgresql_t sepgsql_database_type:db_procedure sepgsql_proc_t; type_transition postgresql_t sepgsql_database_type:db_blob sepgsql_blob_t; type_transition sepgsql_client_type postgresql_t:db_database sepgsql_db_t;

Quoted 7 lines

The first four statements don't make sense to me; the last one does make sense (i.e. when a postgres client creates a new database, where the only related "object" in view is that object manager's context, label the new database with sepgsql_db_t). That last instance seems valid as a way of expressing types for new databases; the first four statements seem to be more suited to this postgres contexts configuration (as they are independent of client domain entirely).

If we have a default contexts configuration, then none of the above statements would be needed: speaking of the last statement, in the absence a type_transition, clients that create databases would still get sepgsql_db_t as the type for the database, since that is the default database type.

Nonetheless, it sounds like you don't have a problem with the libselinux change, as long as its just for the default contexts only, right? Then creating objects with something other than the default context would be the job of type_transition.

Quoted 9 lines

Quoted 9 lines

which I feel should be instead be expressed in a postgresql_contexts file that says the default context for a database is ::seqpgsql_db_t, default context for table is ::sepgsql_sysobj_t, etc.

This makes perfect sense staying as a type_transition in the policy:

type_transition staff_t sepgsql_sysobj_t:db_tuple staff_sepgsql_sysobj_t;

Quoted 28 lines · Stephen Smalley

Quoted 26 lines · Christopher J. PeBenito

Quoted 24 lines · Stephen Smalley

Quoted 22 lines · KaiGai Kohei

Hello,

The attached patch enables to obtain the default security context of newly created database, defined at /etc/selinux/*/contexts/postgresql_contexts .

The format is as follows:
--------
#
# Config file for SE-PostgreSQL
#
# <domain of client> <type of newly created database>
unconfined_t sepgsql_db_t
* sepgsql_db_t
--------

'*' means default security context, if given key is not matched for any entry.

This API requires the security context of client as a key, and it returns a security context to be attached for a newly created database. It has a type field defined in the right-hand of config file, and inherits user and lower-range field of given security context as a key.

Quoted 4 lines

Quoted 4 lines

Quoted 4 lines

Quoted 4 lines

e.g)
selabel_lookup(sehandle, &context, "user_u:user_r:user_t:s0", 0); returns "user_u:object_r:sepgsql_db_t:s0".

Quoted 25 lines

Quoted 25 lines

Quoted 16 lines

Chris is investigating the use of roles on objects in order to provide more fully featured RBAC support without requiring use of per-role domains. Hardcoding the use of object_r won't be future compatible for that situation, and more generally we don't want to hardcode policy information in libselinux at all.

I'm also unclear as to why type_transition rules aren't a better way of expressing the above, although I know you've been discussing this with Chris for some time. Logically I'd expect the client domain to be the source type of the transition, and the type for the newly created database to be the new/result type of the transition. What to use as the target type is less clear; we'd have a similar issue if we were to use type_transitions for e.g. sockets. It could either be the client domain both as source and target (self relationship, no related object) or the client domain as source and the object manager domain as target.

Quoted 3 lines

Chris, what is the objection to using type transitions here, as they are for labeling new objects and this seems to fit that situation?

I think KaiGai took my idea a little to far. My issue was just to have postgres determine what the default label for its objects are via postgresql_contexts. A derived role/type still makes sense to be stated via (type|role)_transition. I suspect there was confusion on this point. I mainly had an issue with statements like:

Quoted 6 lines

Quoted 6 lines

type_transition postgresql_t postgresql_t:db_database sepgsql_db_t; type_transition postgresql_t sepgsql_database_type:db_table sepgsql_sysobj_t; type_transition postgresql_t sepgsql_database_type:db_procedure sepgsql_proc_t; type_transition postgresql_t sepgsql_database_type:db_blob sepgsql_blob_t; type_transition sepgsql_client_type postgresql_t:db_database sepgsql_db_t;

Quoted 8 lines

The first four statements don't make sense to me; the last one does make sense (i.e. when a postgres client creates a new database, where the only related "object" in view is that object manager's context, label the new database with sepgsql_db_t). That last instance seems valid as a way of expressing types for new databases; the first four statements seem to be more suited to this postgres contexts configuration (as they are independent of client domain entirely).

If we have a default contexts configuration, then none of the above statements would be needed: speaking of the last statement, in the absence a type_transition, clients that create databases would still get sepgsql_db_t as the type for the database, since that is the default database type.

Nonetheless, it sounds like you don't have a problem with the libselinux change, as long as its just for the default contexts only, right? Then creating objects with something other than the default context would be the job of type_transition.

Quoted 10 lines

Quoted 10 lines

which I feel should be instead be expressed in a postgresql_contexts file that says the default context for a database is ::seqpgsql_db_t, default context for table is ::sepgsql_sysobj_t, etc.

This makes perfect sense staying as a type_transition in the policy:

type_transition staff_t sepgsql_sysobj_t:db_tuple staff_sepgsql_sysobj_t;

Quoted 11 lines · Christopher J. PeBenito

Quoted 9 lines · Stephen Smalley

Quoted 8 lines · Christopher J. PeBenito

I mainly had an issue with statements like:

type_transition postgresql_t postgresql_t:db_database sepgsql_db_t; type_transition postgresql_t sepgsql_database_type:db_table sepgsql_sysobj_t; type_transition postgresql_t sepgsql_database_type:db_procedure sepgsql_proc_t; type_transition postgresql_t sepgsql_database_type:db_blob sepgsql_blob_t; type_transition sepgsql_client_type postgresql_t:db_database sepgsql_db_t;

I don't see the problem with the above statements - seems like a reasonable use of transitions to me. If you don't like the first four transitions, then I would ask -- why not simply eliminate the target types in those rules and label all of those objects with postgresql_t (default transition)? Clearly the names are just for convenience. You did a similar thing with the X policy: going through and combining types.

Quoted 9 lines · Eamon Walsh

Quoted 7 lines · Christopher J. PeBenito

Quoted 4 lines · Stephen Smalley

Quoted 2 lines · Christopher J. PeBenito

I mainly had an issue with statements like:

Quoted 9 lines

Quoted 7 lines

Quoted 7 lines

Quoted 7 lines

type_transition postgresql_t postgresql_t:db_database sepgsql_db_t; type_transition postgresql_t sepgsql_database_type:db_table sepgsql_sysobj_t; type_transition postgresql_t sepgsql_database_type:db_procedure sepgsql_proc_t; type_transition postgresql_t sepgsql_database_type:db_blob sepgsql_blob_t; type_transition sepgsql_client_type postgresql_t:db_database sepgsql_db_t;

I don't see the problem with the above statements - seems like a reasonable use of transitions to me. If you don't like the first four transitions, then I would ask -- why not simply eliminate the target types in those rules and label all of those objects with postgresql_t (default transition)? Clearly the names are just for convenience. You did a similar thing with the X policy: going through and combining types.

I don't think this is the same situation. Having a table labeled postgresql_t doesn't make sense to me, since postgresql_t is the type of the server process. Though, I suppose that if it wasn't an object manager, then the objects would implicitly be postgresql_t and/or postgresql_db_t. So to conclude my stream of consciousness, I'm compelled by your argument, but I'm not sure its enough to change my position

Quoted 26 lines · Christopher J. PeBenito

Quoted 16 lines · Eamon Walsh

Quoted 7 lines · Christopher J. PeBenito

Quoted 4 lines · Stephen Smalley

Quoted 2 lines · Christopher J. PeBenito

I mainly had an issue with statements like:

Quoted 7 lines

Quoted 7 lines

Quoted 7 lines

type_transition postgresql_t postgresql_t:db_database sepgsql_db_t; type_transition postgresql_t sepgsql_database_type:db_table sepgsql_sysobj_t; type_transition postgresql_t sepgsql_database_type:db_procedure sepgsql_proc_t; type_transition postgresql_t sepgsql_database_type:db_blob sepgsql_blob_t; type_transition sepgsql_client_type postgresql_t:db_database sepgsql_db_t;

Quoted 7 lines

I don't see the problem with the above statements - seems like a reasonable use of transitions to me. If you don't like the first four transitions, then I would ask -- why not simply eliminate the target types in those rules and label all of those objects with postgresql_t (default transition)? Clearly the names are just for convenience. You did a similar thing with the X policy: going through and combining types.

Quoted 7 lines

I don't think this is the same situation. Having a table labeled postgresql_t doesn't make sense to me, since postgresql_t is the type of the server process. Though, I suppose that if it wasn't an object manager, then the objects would implicitly be postgresql_t and/or postgresql_db_t. So to conclude my stream of consciousness, I'm compelled by your argument, but I'm not sure its enough to change my position

If it's not the same situation, it sounds pretty darn close: the X server also acts as a "client" when it starts up, and various objects are created by the server before any real clients connect. For example root window and default colormap.

From xserver.if:

# Labeling rules for default windows and colormaps
type_transition $1_xserver_t $1_xserver_t:{ x_drawable x_colormap } $1_rootwindow_t;

Quoted 38 lines · Eamon Walsh

Quoted 26 lines · Christopher J. PeBenito

Quoted 20 lines · Eamon Walsh

Quoted 9 lines · Christopher J. PeBenito

Quoted 5 lines · Stephen Smalley

Quoted 2 lines · Christopher J. PeBenito

I mainly had an issue with statements like:

Quoted 8 lines

Quoted 8 lines

Quoted 8 lines

type_transition postgresql_t postgresql_t:db_database sepgsql_db_t; type_transition postgresql_t sepgsql_database_type:db_table sepgsql_sysobj_t; type_transition postgresql_t sepgsql_database_type:db_procedure sepgsql_proc_t; type_transition postgresql_t sepgsql_database_type:db_blob sepgsql_blob_t; type_transition sepgsql_client_type postgresql_t:db_database sepgsql_db_t;

Quoted 3 lines

I don't see the problem with the above statements - seems like a reasonable use of transitions to me. If you don't like the first four transitions, then I would ask -- why not simply eliminate the target types in those rules and label all of those objects with postgresql_t (default transition)? Clearly the names are just for convenience. You did a similar thing with the X policy: going through and combining types.

Quoted 8 lines

I don't think this is the same situation. Having a table labeled postgresql_t doesn't make sense to me, since postgresql_t is the type of the server process. Though, I suppose that if it wasn't an object manager, then the objects would implicitly be postgresql_t and/or postgresql_db_t. So to conclude my stream of consciousness, I'm compelled by your argument, but I'm not sure its enough to change my position

If it's not the same situation, it sounds pretty darn close: the X server also acts as a "client" when it starts up, and various objects are created by the server before any real clients connect. For example root window and default colormap.

Quoted 5 lines

From xserver.if:

# Labeling rules for default windows and colormaps
type_transition $1_xserver_t $1_xserver_t:{ x_drawable x_colormap } $1_rootwindow_t;

Its significantly different since this deals with derived types while postgres doesn't.

Quoted 54 lines · Christopher J. PeBenito

Quoted 51 lines · Eamon Walsh

Quoted 31 lines · Christopher J. PeBenito

Quoted 20 lines · Eamon Walsh

Quoted 9 lines · Christopher J. PeBenito

Quoted 5 lines · Stephen Smalley

Quoted 2 lines · Christopher J. PeBenito

I mainly had an issue with statements like:

Quoted 8 lines

Quoted 8 lines

Quoted 8 lines

type_transition postgresql_t postgresql_t:db_database sepgsql_db_t; type_transition postgresql_t sepgsql_database_type:db_table sepgsql_sysobj_t; type_transition postgresql_t sepgsql_database_type:db_procedure sepgsql_proc_t; type_transition postgresql_t sepgsql_database_type:db_blob sepgsql_blob_t; type_transition sepgsql_client_type postgresql_t:db_database sepgsql_db_t;

Quoted 8 lines

I don't see the problem with the above statements - seems like a reasonable use of transitions to me. If you don't like the first four transitions, then I would ask -- why not simply eliminate the target types in those rules and label all of those objects with postgresql_t (default transition)? Clearly the names are just for convenience. You did a similar thing with the X policy: going through and combining types.

Quoted 8 lines

I don't think this is the same situation. Having a table labeled postgresql_t doesn't make sense to me, since postgresql_t is the type of the server process. Though, I suppose that if it wasn't an object manager, then the objects would implicitly be postgresql_t and/or postgresql_db_t. So to conclude my stream of consciousness, I'm compelled by your argument, but I'm not sure its enough to change my position

If it's not the same situation, it sounds pretty darn close: the X server also acts as a "client" when it starts up, and various objects are created by the server before any real clients connect. For example root window and default colormap.

From xserver.if:

# Labeling rules for default windows and colormaps
type_transition $1_xserver_t $1_xserver_t:{ x_drawable x_colormap } $1_rootwindow_t;

Quoted 3 lines

Its significantly different since this deals with derived types while postgres doesn't.

That's the policy writer's decision to make. What if I make my own policy and I want to use derived types for postgres?

Quoted 57 lines · Eamon Walsh

Quoted 56 lines · Christopher J. PeBenito

Quoted 46 lines · Eamon Walsh

Quoted 31 lines · Christopher J. PeBenito

Quoted 20 lines · Eamon Walsh

Quoted 9 lines · Christopher J. PeBenito

Quoted 5 lines · Stephen Smalley

Quoted 2 lines · Christopher J. PeBenito

I mainly had an issue with statements like:

Quoted 8 lines

Quoted 8 lines

Quoted 8 lines

type_transition postgresql_t postgresql_t:db_database sepgsql_db_t; type_transition postgresql_t sepgsql_database_type:db_table sepgsql_sysobj_t; type_transition postgresql_t sepgsql_database_type:db_procedure sepgsql_proc_t; type_transition postgresql_t sepgsql_database_type:db_blob sepgsql_blob_t; type_transition sepgsql_client_type postgresql_t:db_database sepgsql_db_t;

Quoted 8 lines

I don't see the problem with the above statements - seems like a reasonable use of transitions to me. If you don't like the first four transitions, then I would ask -- why not simply eliminate the target types in those rules and label all of those objects with postgresql_t (default transition)? Clearly the names are just for convenience. You did a similar thing with the X policy: going through and combining types.

Quoted 8 lines

I don't think this is the same situation. Having a table labeled postgresql_t doesn't make sense to me, since postgresql_t is the type of the server process. Though, I suppose that if it wasn't an object manager, then the objects would implicitly be postgresql_t and/or postgresql_db_t. So to conclude my stream of consciousness, I'm compelled by your argument, but I'm not sure its enough to change my position

If it's not the same situation, it sounds pretty darn close: the X server also acts as a "client" when it starts up, and various objects are created by the server before any real clients connect. For example root window and default colormap.

Quoted 5 lines

From xserver.if:

# Labeling rules for default windows and colormaps
type_transition $1_xserver_t $1_xserver_t:{ x_drawable x_colormap } $1_rootwindow_t;

Its significantly different since this deals with derived types while postgres doesn't.

Quoted 2 lines

That's the policy writer's decision to make. What if I make my own policy and I want to use derived types for postgres?

I never argued that type transitions shouldn't work. My problem is the default type in the absence of type transitions. In fact there are derived types in the current postgres policy, and I'm fine with them.

Quoted 71 lines · Christopher J. PeBenito

Quoted 69 lines · Eamon Walsh

Quoted 67 lines · Christopher J. PeBenito

Quoted 54 lines · Eamon Walsh

Quoted 37 lines · Christopher J. PeBenito

Quoted 24 lines · Eamon Walsh

Quoted 11 lines · Christopher J. PeBenito

Quoted 6 lines · Stephen Smalley

Quoted 2 lines · Christopher J. PeBenito

I mainly had an issue with statements like:

Quoted 9 lines

Quoted 9 lines

Quoted 9 lines

type_transition postgresql_t postgresql_t:db_database sepgsql_db_t; type_transition postgresql_t sepgsql_database_type:db_table sepgsql_sysobj_t; type_transition postgresql_t sepgsql_database_type:db_procedure sepgsql_proc_t; type_transition postgresql_t sepgsql_database_type:db_blob sepgsql_blob_t; type_transition sepgsql_client_type postgresql_t:db_database sepgsql_db_t;

Quoted 9 lines

I don't see the problem with the above statements - seems like a reasonable use of transitions to me. If you don't like the first four transitions, then I would ask -- why not simply eliminate the target types in those rules and label all of those objects with postgresql_t (default transition)? Clearly the names are just for convenience. You did a similar thing with the X policy: going through and combining types.

Quoted 9 lines

I don't think this is the same situation. Having a table labeled postgresql_t doesn't make sense to me, since postgresql_t is the type of the server process. Though, I suppose that if it wasn't an object manager, then the objects would implicitly be postgresql_t and/or postgresql_db_t. So to conclude my stream of consciousness, I'm compelled by your argument, but I'm not sure its enough to change my position

If it's not the same situation, it sounds pretty darn close: the X server also acts as a "client" when it starts up, and various objects are created by the server before any real clients connect. For example root window and default colormap.

Quoted 6 lines

From xserver.if:

# Labeling rules for default windows and colormaps
type_transition $1_xserver_t $1_xserver_t:{ x_drawable x_colormap } $1_rootwindow_t;

Its significantly different since this deals with derived types while postgres doesn't.

Quoted 7 lines

Quoted 3 lines

That's the policy writer's decision to make. What if I make my own policy and I want to use derived types for postgres?

I never argued that type transitions shouldn't work. My problem is the default type in the absence of type transitions. In fact there are derived types in the current postgres policy, and I'm fine with them.

IIUC, SE-PostgreSQL has to decide the security context of a newly created objects as follows:

1. It invokes security_compute_create_raw() to decide the security context of a newly created object, came from the policy.
2. It checks whether it come from TYPE_TRANSITION rule, or not. (What API is available to check it?)

3. If there is no TYPE_TRANSITION rule, it refers the configuration file to get the default context and applies it as if the context is explicitly specified by hand.
4. It checks xxxx:{ create } permission for the given security context.

It differs from the behavior of setfscreatecon on filesystem, and will be confusable. I think the default come from configuration file should work, as if a user specifies a security context explicitly.

If I misunderstood and you want to add a feature like setfscreatecon, adding a database parameter is more suitable implementation for postgresql, like:
postgres=# SET sepgsql_table_createcon \
'system_u:object_r:sepgsql_secret_t:SystemHigh'

Users can specify it on the frontend (psql), and it read ~/.psqlrc and apply it on the startup.

However, I don't think TYPE_TRANSITION toward sepgsql_db_t, sepgsql_table_t, ... are unnecessary, even if such the default option is added, because we don't use setfscreatecon as alternatives of TYPE_TRANSITION on filesystem.

Quoted 50 lines · KaiGai Kohei

Quoted 49 lines · Christopher J. PeBenito

Quoted 48 lines · Eamon Walsh

Quoted 47 lines · Christopher J. PeBenito

Quoted 36 lines · Eamon Walsh

Quoted 21 lines · Christopher J. PeBenito

Quoted 11 lines · Eamon Walsh

Quoted 10 lines · Christopher J. PeBenito

Quoted 9 lines · Stephen Smalley

Quoted 8 lines · Christopher J. PeBenito

I mainly had an issue with statements like:

type_transition postgresql_t postgresql_t:db_database sepgsql_db_t; type_transition postgresql_t sepgsql_database_type:db_table sepgsql_sysobj_t; type_transition postgresql_t sepgsql_database_type:db_procedure sepgsql_proc_t; type_transition postgresql_t sepgsql_database_type:db_blob sepgsql_blob_t; type_transition sepgsql_client_type postgresql_t:db_database sepgsql_db_t;

Quoted 9 lines

I don't see the problem with the above statements - seems like a reasonable use of transitions to me. If you don't like the first four transitions, then I would ask -- why not simply eliminate the target types in those rules and label all of those objects with postgresql_t (default transition)? Clearly the names are just for convenience. You did a similar thing with the X policy: going through and combining types.

Quoted 9 lines

I don't think this is the same situation. Having a table labeled postgresql_t doesn't make sense to me, since postgresql_t is the type of the server process. Though, I suppose that if it wasn't an object manager, then the objects would implicitly be postgresql_t and/or postgresql_db_t. So to conclude my stream of consciousness, I'm compelled by your argument, but I'm not sure its enough to change my position

If it's not the same situation, it sounds pretty darn close: the X server also acts as a "client" when it starts up, and various objects are created by the server before any real clients connect. For example root window and default colormap.

Quoted 6 lines

From xserver.if:

# Labeling rules for default windows and colormaps
type_transition $1_xserver_t $1_xserver_t:{ x_drawable x_colormap } $1_rootwindow_t;

Its significantly different since this deals with derived types while postgres doesn't.

Quoted 7 lines

Quoted 7 lines

Quoted 3 lines

That's the policy writer's decision to make. What if I make my own policy and I want to use derived types for postgres?

I never argued that type transitions shouldn't work. My problem is the default type in the absence of type transitions. In fact there are derived types in the current postgres policy, and I'm fine with them.

It sounds to me like selabel might be best for this. The tables, databases, procedures, and blobs have names, and those names can be used in a mapping to contexts. There can be setcreatecon overrides to this as well. selabel has a wildcard for setting a default context.

But putting a hard-coded context into a file just to avoid a few type transition rules is totally bogus to me. I find it strange that it's considered a "simplification" to use a default_context file rather than policy rules, as though it's some kind of huge win. Adding a default_context file requires new libselinux API, which bloat affects all SELinux users. I've also never seen a coherent solution for managing these files. They are part of the security policy, which means updates to them must be atomic with the policy load or there will be race conditions affecting their users.

Quoted 63 lines · Eamon Walsh

Quoted 50 lines · KaiGai Kohei

Quoted 49 lines · Christopher J. PeBenito

Quoted 48 lines · Eamon Walsh

Quoted 47 lines · Christopher J. PeBenito

Quoted 36 lines · Eamon Walsh

Quoted 21 lines · Christopher J. PeBenito

Quoted 11 lines · Eamon Walsh

Quoted 10 lines · Christopher J. PeBenito

Quoted 9 lines · Stephen Smalley

Quoted 8 lines · Christopher J. PeBenito

I mainly had an issue with statements like:

type_transition postgresql_t postgresql_t:db_database sepgsql_db_t; type_transition postgresql_t sepgsql_database_type:db_table sepgsql_sysobj_t; type_transition postgresql_t sepgsql_database_type:db_procedure sepgsql_proc_t; type_transition postgresql_t sepgsql_database_type:db_blob sepgsql_blob_t; type_transition sepgsql_client_type postgresql_t:db_database sepgsql_db_t;

Quoted 9 lines

I don't see the problem with the above statements - seems like a reasonable use of transitions to me. If you don't like the first four transitions, then I would ask -- why not simply eliminate the target types in those rules and label all of those objects with postgresql_t (default transition)? Clearly the names are just for convenience. You did a similar thing with the X policy: going through and combining types.

Quoted 9 lines

I don't think this is the same situation. Having a table labeled postgresql_t doesn't make sense to me, since postgresql_t is the type of the server process. Though, I suppose that if it wasn't an object manager, then the objects would implicitly be postgresql_t and/or postgresql_db_t. So to conclude my stream of consciousness, I'm compelled by your argument, but I'm not sure its enough to change my position

If it's not the same situation, it sounds pretty darn close: the X server also acts as a "client" when it starts up, and various objects are created by the server before any real clients connect. For example root window and default colormap.

Quoted 6 lines

From xserver.if:

# Labeling rules for default windows and colormaps
type_transition $1_xserver_t $1_xserver_t:{ x_drawable x_colormap } $1_rootwindow_t;

Its significantly different since this deals with derived types while postgres doesn't.

Quoted 7 lines

Quoted 7 lines

Quoted 3 lines

That's the policy writer's decision to make. What if I make my own policy and I want to use derived types for postgres?

I never argued that type transitions shouldn't work. My problem is the default type in the absence of type transitions. In fact there are derived types in the current postgres policy, and I'm fine with them.

It sounds to me like selabel might be best for this. The tables, databases, procedures, and blobs have names, and those names can be used in a mapping to contexts. There can be setcreatecon overrides to this as well. selabel has a wildcard for setting a default context.

Quoted 9 lines

But putting a hard-coded context into a file just to avoid a few type transition rules is totally bogus to me. I find it strange that it's considered a "simplification" to use a default_context file rather than policy rules, as though it's some kind of huge win. Adding a default_context file requires new libselinux API, which bloat affects all SELinux users. I've also never seen a coherent solution for managing these files. They are part of the security policy, which means updates to them must be atomic with the policy load or there will be race conditions affecting their users.

I'm out of arguments; clearly I'm in the minority on this issue. I already said I wouldn't block the policy over this, so KaiGai, if you would send a last patch based on the revisions I made [1], let see if we can finally get this merged.

[1] http://marc.info/?l=selinux&m=120999566809541&w=2

Quoted 6 lines · Christopher J. PeBenito

I'm out of arguments; clearly I'm in the minority on this issue. I already said I wouldn't block the policy over this, so KaiGai, if you would send a last patch based on the revisions I made [1], let see if we can finally get this merged.

[1] http://marc.info/?l=selinux&m=120999566809541&w=2

I'll submit a revised version later.
(Now we cannot update SVN repository, due to server maintenance.)

Before this, I want to modify the following points:

- neverallow rule should be removed, as you suggested before.

- The type_transition rule for newly created database should be described with "self" as its target, like:

    type_transition sepgsql_client_type self : db_database sepgsql_db_t;

The purpose is to make clear its meanings that this type_transition has no appropriate parent as socket creation.

- postgresql_unconfined() interface should also associate a domin with sepgsql_client_type, not only sepgsql_unconfined_type. dontaudit rules on row-level logs are not disabled for unconfined clients. And, it's not useful to write additional policy module.

Quoted 15 lines · KaiGai Kohei

Quoted 6 lines · Christopher J. PeBenito

I'm out of arguments; clearly I'm in the minority on this issue. I already said I wouldn't block the policy over this, so KaiGai, if you would send a last patch based on the revisions I made [1], let see if we can finally get this merged.

[1] http://marc.info/?l=selinux&m=120999566809541&w=2

I'll submit a revised version later.
(Now we cannot update SVN repository, due to server maintenance.)

Before this, I want to modify the following points:

- neverallow rule should be removed, as you suggested before.

Quoted 5 lines

- The type_transition rule for newly created database should be described with "self" as its target, like:

    type_transition sepgsql_client_type self : db_database sepgsql_db_t;

The purpose is to make clear its meanings that this type_transition has no appropriate parent as socket creation.

Unfortunately self doesn't work in type_transitions.

Quoted 4 lines

- postgresql_unconfined() interface should also associate a domin with sepgsql_client_type, not only sepgsql_unconfined_type. dontaudit rules on row-level logs are not disabled for unconfined clients. And, it's not useful to write additional policy module.

I don't understand what you mean about the dontaudits. Otherwise, you should recheck the unconfined rules. I'm fairly sure I copied anything relevant from the client rules into unconfined so I didn't have to add both attributes in postgresql_unconfined().

Christopher J. PeBenito wrote:

In addition, I found an unclear point which came from my original policy. :(

allow sepgsql_unconfined_type postgresql_t:db_blob { import export };

A blob import interface enables to read a file on a server host by the server process (postgresql_t), and import to database as several frames of largeobject. A export interface works for inversed direction.

In the previous discussion, the meaning of these permission is to indicate server process to start importing or exporting.
However, I'm now considering the following rules are more sensefull:

1. SE-PostgreSQL checks whether the client has db_blob:{import} for the target large object.
2. SE-PostgreSQL checks whether the client has file:{read} for the target file.
3. SELinux (kernel) checks whether postgresql_t has file:{read} for the target file, because it uses read(2) system call.

Could you tell me your opinion?

Quoted 1 line · KaiGai Kohei

Christopher J. PeBenito wrote:

<snip>

Quoted 8 lines

In addition, I found an unclear point which came from my original policy. :(

allow sepgsql_unconfined_type postgresql_t:db_blob { import export };

A blob import interface enables to read a file on a server host by the server process (postgresql_t), and import to database as several frames of largeobject. A export interface works for inversed direction.

Quoted 6 lines

In the previous discussion, the meaning of these permission is to indicate server process to start importing or exporting.
However, I'm now considering the following rules are more sensefull:

1. SE-PostgreSQL checks whether the client has db_blob:{import} for the target large object.

Quoted 5 lines

2. SE-PostgreSQL checks whether the client has file:{read} for the target file.
3. SELinux (kernel) checks whether postgresql_t has file:{read} for the target file, because it uses read(2) system call.

Quoted 1 line

Could you tell me your opinion?

Chris asked me to look at this for him. The access checks above seem completely reasonable to me, much better than the previous check.

I wonder though, how you'll do an export check between the client and file type, since a compute_create between the client and the target directory may be different than between postgresql_t and the directory? Which context would you attempt to use?

Quoted 15 lines · Joshua Brindle

Quoted 2 lines · KaiGai Kohei

Christopher J. PeBenito wrote:

<snip>

Quoted 8 lines

In addition, I found an unclear point which came from my original policy. :(

allow sepgsql_unconfined_type postgresql_t:db_blob { import export };

A blob import interface enables to read a file on a server host by the server process (postgresql_t), and import to database as several frames of largeobject. A export interface works for inversed direction.

Quoted 7 lines

Quoted 7 lines

In the previous discussion, the meaning of these permission is to indicate server process to start importing or exporting.
However, I'm now considering the following rules are more sensefull:

1. SE-PostgreSQL checks whether the client has db_blob:{import} for the target large object.

db_blob:{write} is also checked here...

Quoted 5 lines

Quoted 5 lines

2. SE-PostgreSQL checks whether the client has file:{read} for the target file.
3. SELinux (kernel) checks whether postgresql_t has file:{read} for the target file, because it uses read(2) system call.

Quoted 9 lines

Quoted 2 lines

Could you tell me your opinion?

Chris asked me to look at this for him. The access checks above seem completely reasonable to me, much better than the previous check.

I wonder though, how you'll do an export check between the client and file type, since a compute_create between the client and the target directory may be different than between postgresql_t and the directory? Which context would you attempt to use?

In export case, the target file is labeled as a newly created one between postgresql_t and its parent directly, as SELinux attaches in default.

We can understand the behavior as PostgreSQL owns this file and delivers its file descriptor to the client. Thus, the client should be checked the file:{write} permission for the result of compute_create between postgresql_t and the parent directly.

It does not give us any mismatching between DAC and MAC.
So, I think it is more suitable than using setfscreatecon() to force the result between the client and the parent directly.

In the conclusion, the following permissions will be checked for blob export.

1. SELinux (kernel) checks file:{write} between postgresql_t and the newly created file which is labeled as the result between postgresql_t and the parent directory.
This file is owned by PostgreSQL in DAC world.
2. SE-PostgreSQL checks db_blob:{export read} between the client and the target large object.
3. SE-PostgreSQL checks file:{write} between the client and the target file.

Thanks,

Quoted 41 lines · KaiGai Kohei

Quoted 15 lines · Joshua Brindle

Quoted 2 lines · KaiGai Kohei

Christopher J. PeBenito wrote:

<snip>

Quoted 8 lines

In addition, I found an unclear point which came from my original policy. :(

allow sepgsql_unconfined_type postgresql_t:db_blob { import export };

A blob import interface enables to read a file on a server host by the server process (postgresql_t), and import to database as several frames of largeobject. A export interface works for inversed direction.

Quoted 7 lines

Quoted 7 lines

In the previous discussion, the meaning of these permission is to indicate server process to start importing or exporting.
However, I'm now considering the following rules are more sensefull:

1. SE-PostgreSQL checks whether the client has db_blob:{import} for the target large object.

db_blob:{write} is also checked here...

Quoted 5 lines

Quoted 5 lines

2. SE-PostgreSQL checks whether the client has file:{read} for the target file.
3. SELinux (kernel) checks whether postgresql_t has file:{read} for the target file, because it uses read(2) system call.

Quoted 9 lines

Quoted 2 lines

Could you tell me your opinion?

Chris asked me to look at this for him. The access checks above seem completely reasonable to me, much better than the previous check.

I wonder though, how you'll do an export check between the client and file type, since a compute_create between the client and the target directory may be different than between postgresql_t and the directory? Which context would you attempt to use?

Quoted 8 lines

In export case, the target file is labeled as a newly created one between postgresql_t and its parent directly, as SELinux attaches in default.

We can understand the behavior as PostgreSQL owns this file and delivers its file descriptor to the client. Thus, the client should be checked the file:{write} permission for the result of compute_create between postgresql_t and the parent directly.

Doesn't the kernel handle this automatically? Which is to say, if you give a file descriptor to another process (I'm assuming it gets passed through the local socket), the kernel still checks read and write on every access.

Quoted 16 lines

It does not give us any mismatching between DAC and MAC.
So, I think it is more suitable than using setfscreatecon() to force the result between the client and the parent directly.

In the conclusion, the following permissions will be checked for blob export.

1. SELinux (kernel) checks file:{write} between postgresql_t and the newly created file which is labeled as the result between postgresql_t and the parent directory.
This file is owned by PostgreSQL in DAC world.
2. SE-PostgreSQL checks db_blob:{export read} between the client and the target large object.
3. SE-PostgreSQL checks file:{write} between the client and the target file.

Thanks,

Quoted 19 lines · Christopher J. PeBenito

Quoted 11 lines · KaiGai Kohei

Quoted 6 lines · Christopher J. PeBenito

I'm out of arguments; clearly I'm in the minority on this issue. I already said I wouldn't block the policy over this, so KaiGai, if you would send a last patch based on the revisions I made [1], let see if we can finally get this merged.

[1] http://marc.info/?l=selinux&m=120999566809541&w=2

I'll submit a revised version later.
(Now we cannot update SVN repository, due to server maintenance.)

Quoted 6 lines

Before this, I want to modify the following points:

- postgresql_unconfined() interface should also associate a domin with sepgsql_client_type, not only sepgsql_unconfined_type. dontaudit rules on row-level logs are not disabled for unconfined clients. And, it's not useful to write additional policy module.

Quoted 4 lines

I don't understand what you mean about the dontaudits. Otherwise, you should recheck the unconfined rules. I'm fairly sure I copied anything relevant from the client rules into unconfined so I didn't have to add both attributes in postgresql_unconfined().

A table can contain massive tuples in generally. If 50% of 1,000,000 tuples are labaled as "Classified" and hidden from clients (includes unconfined domain), tuple-level access denied log will make a flood of logs. The dontaudit rule enables to restain the problem.

I intended sepgsql_client_type means all domains connectable to SE-PostgreSQL. If it dosen't contain unconfined domains, I think its name is a bit confusable and something like "sepgsql_unpriv_type" is better for its name.

Then, the above dontaudit rule should be rewritten as follows:

  dontaudit { sepgsql_client_type sepgsql_unpriv_type postgresql_t } \
            { sepgsql_table_type - sepgsql_sysobj_table_type } : db_tuple *;

At first, I used a boolean (sepgsql_enable_audittuple) to turn on/off tuple-level access logs, but you suggested it is unnecessary, so I removed it.

In addition, I found an unclear point which came from my original policy. :(

allow sepgsql_unconfined_type postgresql_t:db_blob { import export };

A blob import interface enables to read a file on a server host by the server process (postgresql_t), and import to database as several frames of largeobject. A export interface works for inversed direction.

In the previous discussion, the meaning of these permission is to indicate server process to start importing or exporting.
However, I'm now considering the following rules are more sensefull:

1. SE-PostgreSQL checks whether the client has db_blob:{import} for the target large object.
2. SE-PostgreSQL checks whether the client has file:{read} for the target file.
3. SELinux (kernel) checks whether postgresql_t has file:{read} for the target file, because it uses read(2) system call.

Could you tell me your opinion?

Quoted 27 lines · KaiGai Kohei

Quoted 13 lines · Christopher J. PeBenito

Quoted 11 lines · KaiGai Kohei

Quoted 6 lines · Christopher J. PeBenito

I'm out of arguments; clearly I'm in the minority on this issue. I already said I wouldn't block the policy over this, so KaiGai, if you would send a last patch based on the revisions I made [1], let see if we can finally get this merged.

[1] http://marc.info/?l=selinux&m=120999566809541&w=2

I'll submit a revised version later.
(Now we cannot update SVN repository, due to server maintenance.)

Before this, I want to modify the following points:

Quoted 8 lines

Quoted 4 lines

- postgresql_unconfined() interface should also associate a domin with sepgsql_client_type, not only sepgsql_unconfined_type. dontaudit rules on row-level logs are not disabled for unconfined clients. And, it's not useful to write additional policy module.

I don't understand what you mean about the dontaudits. Otherwise, you should recheck the unconfined rules. I'm fairly sure I copied anything relevant from the client rules into unconfined so I didn't have to add both attributes in postgresql_unconfined().

A table can contain massive tuples in generally. If 50% of 1,000,000 tuples are labaled as "Classified" and hidden from clients (includes unconfined domain), tuple-level access denied log will make a flood of logs. The dontaudit rule enables to restain the problem.

Quoted 3 lines

I intended sepgsql_client_type means all domains connectable to SE-PostgreSQL. If it dosen't contain unconfined domains, I think its name is a bit confusable and something like "sepgsql_unpriv_type" is better for its name.

The fact is that we need an interface for unconfined access. If the privileged client access is equivalent to unconfined access, then I feel that the unconfined interface is clearer.

Quoted 7 lines

Then, the above dontaudit rule should be rewritten as follows:

  dontaudit { sepgsql_client_type sepgsql_unpriv_type postgresql_t } \
            { sepgsql_table_type - sepgsql_sysobj_table_type } : db_tuple *;

At first, I used a boolean (sepgsql_enable_audittuple) to turn on/off tuple-level access logs, but you suggested it is unnecessary, so I removed it.

I don't agree because of:

(quoted diff) +2 -0

+allow postgresql_t sepgsql_table_type:{ db_table db_column db_tuple } *;
+allow sepgsql_unconfined_type sepgsql_table_type:{ db_table db_column db_tuple } *;

so dontauditing for postgresql_t and sepgsql_unconfined_type doesn't do anything since the access is allowed.

Quoted 12 lines

In addition, I found an unclear point which came from my original policy. :(

allow sepgsql_unconfined_type postgresql_t:db_blob { import export };

A blob import interface enables to read a file on a server host by the server process (postgresql_t), and import to database as several frames of largeobject. A export interface works for inversed direction.

In the previous discussion, the meaning of these permission is to indicate server process to start importing or exporting.
However, I'm now considering the following rules are more sensefull:

Quoted 8 lines

1. SE-PostgreSQL checks whether the client has db_blob:{import} for the target large object.
2. SE-PostgreSQL checks whether the client has file:{read} for the target file.
3. SELinux (kernel) checks whether postgresql_t has file:{read} for the target file, because it uses read(2) system call.

Could you tell me your opinion?

I'll defer to Josh on this one since he knows much more about databases than I do.

Quoted 29 lines · Christopher J. PeBenito

Quoted 15 lines · KaiGai Kohei

Quoted 7 lines · Christopher J. PeBenito

Quoted 6 lines · KaiGai Kohei

Quoted 5 lines · Christopher J. PeBenito

I'm out of arguments; clearly I'm in the minority on this issue. I already said I wouldn't block the policy over this, so KaiGai, if you would send a last patch based on the revisions I made [1], let see if we can finally get this merged.

Quoted 5 lines

Quoted 5 lines

Quoted 1 line

[1] http://marc.info/?l=selinux&m=120999566809541&w=2

I'll submit a revised version later.
(Now we cannot update SVN repository, due to server maintenance.)

Before this, I want to modify the following points:

Quoted 7 lines

Then, the above dontaudit rule should be rewritten as follows:

  dontaudit { sepgsql_client_type sepgsql_unpriv_type postgresql_t } \
            { sepgsql_table_type - sepgsql_sysobj_table_type } : db_tuple *;

At first, I used a boolean (sepgsql_enable_audittuple) to turn on/off tuple-level access logs, but you suggested it is unnecessary, so I removed it.

I don't agree because of:

(quoted diff) +2 -0

+allow postgresql_t sepgsql_table_type:{ db_table db_column db_tuple } *;
+allow sepgsql_unconfined_type sepgsql_table_type:{ db_table db_column db_tuple } *;

Quoted 2 lines

so dontauditing for postgresql_t and sepgsql_unconfined_type doesn't do anything since the access is allowed.

It is correct in type enforcement.
But MCS/MLS can prevent to access by unconfined domains, and make flood of access denied logs.

Quoted 25 lines · KaiGai Kohei

Quoted 24 lines · Christopher J. PeBenito

Quoted 14 lines · KaiGai Kohei

Quoted 7 lines · Christopher J. PeBenito

Quoted 6 lines · KaiGai Kohei

Quoted 5 lines · Christopher J. PeBenito

I'm out of arguments; clearly I'm in the minority on this issue. I already said I wouldn't block the policy over this, so KaiGai, if you would send a last patch based on the revisions I made [1], let see if we can finally get this merged.

Quoted 5 lines

Quoted 5 lines

Quoted 1 line

[1] http://marc.info/?l=selinux&m=120999566809541&w=2

I'll submit a revised version later.
(Now we cannot update SVN repository, due to server maintenance.)

Before this, I want to modify the following points:

Quoted 7 lines

Then, the above dontaudit rule should be rewritten as follows:

  dontaudit { sepgsql_client_type sepgsql_unpriv_type postgresql_t } \
            { sepgsql_table_type - sepgsql_sysobj_table_type } : db_tuple *;

At first, I used a boolean (sepgsql_enable_audittuple) to turn on/off tuple-level access logs, but you suggested it is unnecessary, so I removed it.

I don't agree because of:

Quoted 8 lines

Quoted 5 lines

(quoted diff) +2 -0

+allow postgresql_t sepgsql_table_type:{ db_table db_column db_tuple } *;
+allow sepgsql_unconfined_type sepgsql_table_type:{ db_table db_column db_tuple } *;

so dontauditing for postgresql_t and sepgsql_unconfined_type doesn't do anything since the access is allowed.

It is correct in type enforcement.
But MCS/MLS can prevent to access by unconfined domains, and make flood of access denied logs.

Ok, I see your point. Please add a comment in the policy that explains this, so I don't mistakenly remove the dontaudit in the future :)

One thing I just realized: do we really want to dontaudit all perms? It seems like use and/or select might be sufficient. Dontauditing relabelto and relabelfrom doesn't seem like a good idea.

Quoted 33 lines · Chris PeBenito

Quoted 24 lines · KaiGai Kohei

Quoted 23 lines · Christopher J. PeBenito

Quoted 12 lines · KaiGai Kohei

Quoted 11 lines · Christopher J. PeBenito

Quoted 10 lines · KaiGai Kohei

Quoted 6 lines · Christopher J. PeBenito

I'm out of arguments; clearly I'm in the minority on this issue. I already said I wouldn't block the policy over this, so KaiGai, if you would send a last patch based on the revisions I made [1], let see if we can finally get this merged.

[1] http://marc.info/?l=selinux&m=120999566809541&w=2

I'll submit a revised version later.
(Now we cannot update SVN repository, due to server maintenance.)

Quoted 8 lines

Quoted 1 line

Quoted 1 line

Before this, I want to modify the following points:

Then, the above dontaudit rule should be rewritten as follows:

  dontaudit { sepgsql_client_type sepgsql_unpriv_type postgresql_t } \
            { sepgsql_table_type - sepgsql_sysobj_table_type } : db_tuple *;

At first, I used a boolean (sepgsql_enable_audittuple) to turn on/off tuple-level access logs, but you suggested it is unnecessary, so I removed it.

I don't agree because of:

Quoted 8 lines

Quoted 5 lines

(quoted diff) +2 -0

+allow postgresql_t sepgsql_table_type:{ db_table db_column db_tuple } *;
+allow sepgsql_unconfined_type sepgsql_table_type:{ db_table db_column db_tuple } *;

so dontauditing for postgresql_t and sepgsql_unconfined_type doesn't do anything since the access is allowed.

It is correct in type enforcement.
But MCS/MLS can prevent to access by unconfined domains, and make flood of access denied logs.

Quoted 6 lines

Ok, I see your point. Please add a comment in the policy that explains this, so I don't mistakenly remove the dontaudit in the future :)

One thing I just realized: do we really want to dontaudit all perms? It seems like use and/or select might be sufficient. Dontauditing relabelto and relabelfrom doesn't seem like a good idea.

OK, I'll send the patch with a comment for tuple-level dontaudit and without dontaudit for relabelfrom/relabelto.

Please wait for days.

Thanks,

In the attached patch, the following points are changed from [1].

[1] http://marc.info/?l=selinux&m=120999566809541&w=2

- type_transition rule of a newly created database got being described as a relation ship between client and itself, like:
| type_transition sepgsql_client_type sepgsql_client_type:db_database sepgsql_db_t;

- neverallow rule has gone.

- allow sepgsql_unconfined_type postgresql_t:db_blob { import export }; is removed.

- A comment is added to explain dontaudit rule in row-level denied logs.

 | # NOTE:
 | # The purpose of the dontaudit rule in row-level access control is to prevent a flood of logs.
 | # If a client tries to SELECT a table including violated tuples, these are filtered from
 | # the result set as if not exist, but its access denied longs can be recorded within log files.
 | # In generally, the number of tuples are much larger than the number of columns, tables and so on.
 | # So, it makes a flood of logs when many tuples are violated.
 | #
 | # The default policy does not prevent anything for sepgsql_client_type sepgsql_unconfined_type,
 | # so we don't need "dontaudit" rules in Type-Enforcement. However, MLS/MCS can prevent them
 | # to access classified tuples and can make a audit record.
 | #
 | # Therefore, the following rule is applied for any domains which can connect SE-PostgreSQL.

I merged this, but I was thinking about some revisions that we should consider:

1. in the unpriv client interface, we have these type transitions:
type_transition $1 sepgsql_database_type:db_table sepgsql_table_t; type_transition $1 sepgsql_database_type:db_procedure sepgsql_proc_t; type_transition $1 sepgsql_database_type:db_blob sepgsql_blob_t;

The client can only access the system database, not all databases, so it seems that sepgsql_database_type should be replaced with sepgsql_db_t.

2. the stored procedure type names have been in the back of my mind for long time but I couldn't come up with a good naming scheme. This especially bugged me for the sepgsql_trusted_domain_t and sepgsql_trusted_proc_t. Why not just go with what we do with regular domains and executables: sepgsql_trusted_proc_t and sepgsql_trusted_proc_exec_t?

Quoted 8 lines · Christopher J. PeBenito

I merged this, but I was thinking about some revisions that we should consider:

1. in the unpriv client interface, we have these type transitions:
type_transition $1 sepgsql_database_type:db_table sepgsql_table_t; type_transition $1 sepgsql_database_type:db_procedure sepgsql_proc_t; type_transition $1 sepgsql_database_type:db_blob sepgsql_blob_t;

Quoted 2 lines

The client can only access the system database, not all databases, so it seems that sepgsql_database_type should be replaced with sepgsql_db_t.

I agreed.

Currently, sepgsql_db_t is the only type of sepgsql_database_type except for unlabeled_t, however, these type_transition can prevent user to add new database type and new type_transition rules.

Quoted 6 lines

2. the stored procedure type names have been in the back of my mind for long time but I couldn't come up with a good naming scheme. This especially bugged me for the sepgsql_trusted_domain_t and sepgsql_trusted_proc_t. Why not just go with what we do with regular domains and executables: sepgsql_trusted_proc_t and sepgsql_trusted_proc_exec_t?

I don't have a clear reason for the naming of them. sepgsql_trusted_proc_t and sepgsql_trusted_proc_exec_t are more suitable for the purpose, I also think.

Quoted 9 lines

Quoted 6 lines

2. the stored procedure type names have been in the back of my mind for long time but I couldn't come up with a good naming scheme. This especially bugged me for the sepgsql_trusted_domain_t and sepgsql_trusted_proc_t. Why not just go with what we do with regular domains and executables: sepgsql_trusted_proc_t and sepgsql_trusted_proc_exec_t?

I don't have a clear reason for the naming of them. sepgsql_trusted_proc_t and sepgsql_trusted_proc_exec_t are more suitable for the purpose, I also think.

It seems that we should also rename $1_sepgsql_proc_t for consistency.

Quoted 10 lines · Christopher J. PeBenito

Quoted 9 lines

Quoted 6 lines

2. the stored procedure type names have been in the back of my mind for long time but I couldn't come up with a good naming scheme. This especially bugged me for the sepgsql_trusted_domain_t and sepgsql_trusted_proc_t. Why not just go with what we do with regular domains and executables: sepgsql_trusted_proc_t and sepgsql_trusted_proc_exec_t?

I don't have a clear reason for the naming of them. sepgsql_trusted_proc_t and sepgsql_trusted_proc_exec_t are more suitable for the purpose, I also think.

Quoted 1 line

It seems that we should also rename $1_sepgsql_proc_t for consistency.

Sorry for late reply.

At first, $1_sepgsql_proc_t lost the term of "trusted", so its name does not shows its purpose.

Quoted 10 lines · KaiGai Kohei

Quoted 9 lines · Christopher J. PeBenito

Quoted 9 lines

Quoted 6 lines

2. the stored procedure type names have been in the back of my mind for long time but I couldn't come up with a good naming scheme. This especially bugged me for the sepgsql_trusted_domain_t and sepgsql_trusted_proc_t. Why not just go with what we do with regular domains and executables: sepgsql_trusted_proc_t and sepgsql_trusted_proc_exec_t?

I don't have a clear reason for the naming of them. sepgsql_trusted_proc_t and sepgsql_trusted_proc_exec_t are more suitable for the purpose, I also think.

Quoted 5 lines

Quoted 1 line

It seems that we should also rename $1_sepgsql_proc_t for consistency.

Sorry for late reply.

At first, $1_sepgsql_proc_t lost the term of "trusted", so its name does not shows its purpose.

No, I mean having a $1_sepgsql_proc_t and $1_sepgsql_proc_exec_t.

Quoted 17 lines · Christopher J. PeBenito

Quoted 15 lines · KaiGai Kohei

Quoted 10 lines · Christopher J. PeBenito

Quoted 9 lines

Quoted 6 lines

2. the stored procedure type names have been in the back of my mind for long time but I couldn't come up with a good naming scheme. This especially bugged me for the sepgsql_trusted_domain_t and sepgsql_trusted_proc_t. Why not just go with what we do with regular domains and executables: sepgsql_trusted_proc_t and sepgsql_trusted_proc_exec_t?

I don't have a clear reason for the naming of them. sepgsql_trusted_proc_t and sepgsql_trusted_proc_exec_t are more suitable for the purpose, I also think.

It seems that we should also rename $1_sepgsql_proc_t for consistency.

Sorry for late reply.

At first, $1_sepgsql_proc_t lost the term of "trusted", so its name does not shows its purpose.

Quoted 1 line

No, I mean having a $1_sepgsql_proc_t and $1_sepgsql_proc_exec_t.

Do you intend the following domain transition?
user_t + user_sepgsql_proc_exec_t -> user_sepgsql_proc_t

Is there any reason why users should not invoke their functions without domain transition?

Quoted 21 lines · KaiGai Kohei

Quoted 11 lines · Christopher J. PeBenito

Quoted 10 lines · KaiGai Kohei

Quoted 9 lines · Christopher J. PeBenito

Quoted 9 lines

Quoted 6 lines

2. the stored procedure type names have been in the back of my mind for long time but I couldn't come up with a good naming scheme. This especially bugged me for the sepgsql_trusted_domain_t and sepgsql_trusted_proc_t. Why not just go with what we do with regular domains and executables: sepgsql_trusted_proc_t and sepgsql_trusted_proc_exec_t?

I don't have a clear reason for the naming of them. sepgsql_trusted_proc_t and sepgsql_trusted_proc_exec_t are more suitable for the purpose, I also think.

Quoted 6 lines

Quoted 5 lines

Quoted 1 line

It seems that we should also rename $1_sepgsql_proc_t for consistency.

Sorry for late reply.

At first, $1_sepgsql_proc_t lost the term of "trusted", so its name does not shows its purpose.

No, I mean having a $1_sepgsql_proc_t and $1_sepgsql_proc_exec_t.

Do you intend the following domain transition?
user_t + user_sepgsql_proc_exec_t -> user_sepgsql_proc_t

Quoted 2 lines

Is there any reason why users should not invoke their functions without domain transition?

I don't think we need a transition. Mainly I think the procedure should be $1_sepgsql_proc_exec_t so there is naming consistency for stored procedures.

Quoted 25 lines · Christopher J. PeBenito

Quoted 23 lines · KaiGai Kohei

Quoted 11 lines · Christopher J. PeBenito

Quoted 10 lines · KaiGai Kohei

Quoted 9 lines · Christopher J. PeBenito

Quoted 9 lines

Quoted 6 lines

2. the stored procedure type names have been in the back of my mind for long time but I couldn't come up with a good naming scheme. This especially bugged me for the sepgsql_trusted_domain_t and sepgsql_trusted_proc_t. Why not just go with what we do with regular domains and executables: sepgsql_trusted_proc_t and sepgsql_trusted_proc_exec_t?

I don't have a clear reason for the naming of them. sepgsql_trusted_proc_t and sepgsql_trusted_proc_exec_t are more suitable for the purpose, I also think.

Quoted 6 lines

Quoted 5 lines

Quoted 1 line

It seems that we should also rename $1_sepgsql_proc_t for consistency.

Sorry for late reply.

At first, $1_sepgsql_proc_t lost the term of "trusted", so its name does not shows its purpose.

No, I mean having a $1_sepgsql_proc_t and $1_sepgsql_proc_exec_t.

Do you intend the following domain transition?
user_t + user_sepgsql_proc_exec_t -> user_sepgsql_proc_t

Is there any reason why users should not invoke their functions without domain transition?

Quoted 3 lines

I don't think we need a transition. Mainly I think the procedure should be $1_sepgsql_proc_exec_t so there is naming consistency for stored procedures.

I agree it.
Do you need a patch?

Quoted 25 lines · KaiGai Kohei

Quoted 24 lines · Christopher J. PeBenito

Quoted 23 lines · KaiGai Kohei

Quoted 11 lines · Christopher J. PeBenito

Quoted 10 lines · KaiGai Kohei

Quoted 9 lines · Christopher J. PeBenito

Quoted 9 lines

Quoted 6 lines

2. the stored procedure type names have been in the back of my mind for long time but I couldn't come up with a good naming scheme. This especially bugged me for the sepgsql_trusted_domain_t and sepgsql_trusted_proc_t. Why not just go with what we do with regular domains and executables: sepgsql_trusted_proc_t and sepgsql_trusted_proc_exec_t?

I don't have a clear reason for the naming of them. sepgsql_trusted_proc_t and sepgsql_trusted_proc_exec_t are more suitable for the purpose, I also think.

Quoted 6 lines

Quoted 5 lines

Quoted 1 line

It seems that we should also rename $1_sepgsql_proc_t for consistency.

Sorry for late reply.

At first, $1_sepgsql_proc_t lost the term of "trusted", so its name does not shows its purpose.

No, I mean having a $1_sepgsql_proc_t and $1_sepgsql_proc_exec_t.

Do you intend the following domain transition?
user_t + user_sepgsql_proc_exec_t -> user_sepgsql_proc_t

Is there any reason why users should not invoke their functions without domain transition?

Quoted 5 lines

Quoted 3 lines

I don't think we need a transition. Mainly I think the procedure should be $1_sepgsql_proc_exec_t so there is naming consistency for stored procedures.

I agree it.
Do you need a patch?

Well I didn't merge the trusted_proc patch yet, would you update that patch with $1_sepgsql_proc_exec_t too?

The attached patch replaces the following names:

  $1_sepgsql_proc_t         -> $1_sepgsql_proc_exec_t
  sepgsql_trusted_domain_t  -> sepgsql_trusted_proc_t
  sepgsql_trusted_proc_t    -> sepgsql_trusted_proc_exec_t

differences
between files
attachment
(refpolicy-sepgsql_proc_exec_t.patch)

Index: refpolicy/policy/modules/services/postgresql.if
===================================================================
--- refpolicy/policy/modules/services/postgresql.if (revision
2727)
+++ refpolicy/policy/modules/services/postgresql.if (working copy)

policy/modules/services/postgresql.if +1 -1

@@ -37,7 +37,7 @@
                attribute sepgsql_client_type, sepgsql_database_type;
                attribute sepgsql_sysobj_table_type;
 
-               type sepgsql_trusted_proc_t, sepgsql_trusted_domain_t;
+               type sepgsql_trusted_proc_exec_t,
 sepgsql_trusted_proc_t;
        ')
 

        ########################################

policy/modules/services/postgresql.if +5 -5

@@ -50,8 +50,8 @@
        type $1_sepgsql_blob_t;
        postgresql_blob_object($1_sepgsql_blob_t)
 
-       type $1_sepgsql_proc_t;
-       postgresql_procedure_object($1_sepgsql_proc_t)
+       type $1_sepgsql_proc_exec_t;
+       postgresql_procedure_object($1_sepgsql_proc_exec_t)
 
        type $1_sepgsql_sysobj_t;
        postgresql_system_table_object($1_sepgsql_sysobj_t)

@@ -59,7 +59,7 @@
        type $1_sepgsql_table_t;
        postgresql_table_object($1_sepgsql_table_t)
 
-       role $3 types sepgsql_trusted_domain_t;
+       role $3 types sepgsql_trusted_proc_t;
 
        ##############################
        #

@@ -81,14 +81,14 @@
        allow $2 $1_sepgsql_table_t  : db_tuple  { use select update
 insert delete };
        allow $2 $1_sepgsql_sysobj_t : db_tuple  { use select };
 
-       allow $2 $1_sepgsql_proc_t : db_procedure { create drop
 getattr setattr execute };
-       type_transition $2 sepgsql_database_type:db_procedure
 $1_sepgsql_proc_t;
+       allow $2 $1_sepgsql_proc_exec_t : db_procedure { create drop
 getattr setattr execute };
+       type_transition $2 sepgsql_database_type:db_procedure
 $1_sepgsql_proc_exec_t;
 
        allow $2 $1_sepgsql_blob_t : db_blob { create drop getattr
 setattr read write };
        type_transition $2 sepgsql_database_type:db_blob

$1_sepgsql_blob_t;

(quoted diff) +0 -2

-       allow $2 sepgsql_trusted_domain_t:process transition;
-       type_transition $2 sepgsql_trusted_proc_t:process

sepgsql_trusted_domain_t;

(quoted diff) +2 -0

+       allow $2 sepgsql_trusted_proc_t:process transition;
+       type_transition $2 sepgsql_trusted_proc_exec_t:process

sepgsql_trusted_proc_t;
')

########################################

policy/modules/services/postgresql.if +1 -1

@@ -343,7 +343,7 @@
 
                type sepgsql_db_t, sepgsql_table_t, sepgsql_proc_t,
 sepgsql_blob_t;
 
-               type sepgsql_trusted_proc_t, sepgsql_trusted_domain_t;
+               type sepgsql_trusted_proc_t,
 sepgsql_trusted_proc_exec_t;
        ')

 
        typeattribute $1 sepgsql_client_type;

policy/modules/services/postgresql.if +2 -2

@@ -352,8 +352,8 @@
        type_transition $1 sepgsql_db_t:db_procedure sepgsql_proc_t;
        type_transition $1 sepgsql_db_t:db_blob sepgsql_blob_t;
 
-       type_transition $1 sepgsql_trusted_proc_t:process
 sepgsql_trusted_domain_t;
-       allow $1 sepgsql_trusted_domain_t:process transition;
+       type_transition $1 sepgsql_trusted_proc_exec_t:process
 sepgsql_trusted_proc_t;
+       allow $1 sepgsql_trusted_proc_t:process transition;
 ')

########################################
Index: refpolicy/policy/modules/services/postgresql.te
===================================================================
--- refpolicy/policy/modules/services/postgresql.te (revision
2727)
+++ refpolicy/policy/modules/services/postgresql.te (working copy)

policy/modules/services/postgresql.te +6 -6

@@ -87,14 +87,14 @@
 type sepgsql_table_t;
 postgresql_table_object(sepgsql_table_t)
 
-type sepgsql_trusted_proc_t;
-postgresql_procedure_object(sepgsql_trusted_proc_t)
+type sepgsql_trusted_proc_exec_t;
+postgresql_procedure_object(sepgsql_trusted_proc_exec_t)
 
 # Trusted Procedure Domain
-type sepgsql_trusted_domain_t;
-domain_type(sepgsql_trusted_domain_t)
-postgresql_unconfined(sepgsql_trusted_domain_t)
-role system_r types sepgsql_trusted_domain_t;
+type sepgsql_trusted_proc_t;
+domain_type(sepgsql_trusted_proc_t)
+postgresql_unconfined(sepgsql_trusted_proc_t)
+role system_r types sepgsql_trusted_proc_t;
 
 ########################################
 #

Quoted 57 lines · Stephen Smalley

Quoted 51 lines · Christopher J. PeBenito

Quoted 42 lines · Stephen Smalley

Quoted 17 lines · KaiGai Kohei

Hello,

The attached patch enables to obtain the default security context of newly created database, defined at /etc/selinux/*/contexts/postgresql_contexts .

The format is as follows:
--------
#
# Config file for SE-PostgreSQL
#
# <domain of client> <type of newly created database>
unconfined_t sepgsql_db_t
* sepgsql_db_t
--------

'*' means default security context, if given key is not matched for any entry.

Quoted 8 lines

This API requires the security context of client as a key, and it returns a security context to be attached for a newly created database. It has a type field defined in the right-hand of config file, and inherits user and lower-range field of given security context as a key.

e.g)
selabel_lookup(sehandle, &context, "user_u:user_r:user_t:s0", 0); returns "user_u:object_r:sepgsql_db_t:s0".

Chris is investigating the use of roles on objects in order to provide more fully featured RBAC support without requiring use of per-role domains. Hardcoding the use of object_r won't be future compatible for that situation, and more generally we don't want to hardcode policy information in libselinux at all.

I'm also unclear as to why type_transition rules aren't a better way of expressing the above, although I know you've been discussing this with Chris for some time. Logically I'd expect the client domain to be the source type of the transition, and the type for the newly created database to be the new/result type of the transition. What to use as the target type is less clear; we'd have a similar issue if we were to use type_transitions for e.g. sockets. It could either be the client domain both as source and target (self relationship, no related object) or the client domain as source and the object manager domain as target.

Quoted 2 lines

Chris, what is the objection to using type transitions here, as they are for labeling new objects and this seems to fit that situation?

I think KaiGai took my idea a little to far. My issue was just to have postgres determine what the default label for its objects are via postgresql_contexts. A derived role/type still makes sense to be stated via (type|role)_transition. I suspect there was confusion on this point. I mainly had an issue with statements like:

Quoted 5 lines

type_transition postgresql_t postgresql_t:db_database sepgsql_db_t; type_transition postgresql_t sepgsql_database_type:db_table sepgsql_sysobj_t; type_transition postgresql_t sepgsql_database_type:db_procedure sepgsql_proc_t; type_transition postgresql_t sepgsql_database_type:db_blob sepgsql_blob_t; type_transition sepgsql_client_type postgresql_t:db_database sepgsql_db_t;

Quoted 7 lines

The first four statements don't make sense to me; the last one does make sense (i.e. when a postgres client creates a new database, where the only related "object" in view is that object manager's context, label the new database with sepgsql_db_t). That last instance seems valid as a way of expressing types for new databases; the first four statements seem to be more suited to this postgres contexts configuration (as they are independent of client domain entirely).

If we have a default contexts configuration, then none of the above statements would be needed: speaking of the last statement, in the absence a type_transition, clients that create databases would still get sepgsql_db_t as the type for the database, since that is the default database type.

Nonetheless, it sounds like you don't have a problem with the libselinux change, as long as its just for the default contexts only, right? Then creating objects with something other than the default context would be the job of type_transition.

Quoted 7 lines

Quoted 7 lines

which I feel should be instead be expressed in a postgresql_contexts file that says the default context for a database is ::seqpgsql_db_t, default context for table is ::sepgsql_sysobj_t, etc.

This makes perfect sense staying as a type_transition in the policy:

type_transition staff_t sepgsql_sysobj_t:db_tuple staff_sepgsql_sysobj_t;

Quoted 17 lines · Christopher J. PeBenito

Quoted 8 lines · Stephen Smalley

Quoted 7 lines · Christopher J. PeBenito

I mainly had an issue with statements like:

type_transition postgresql_t postgresql_t:db_database sepgsql_db_t; type_transition postgresql_t sepgsql_database_type:db_table sepgsql_sysobj_t; type_transition postgresql_t sepgsql_database_type:db_procedure sepgsql_proc_t; type_transition postgresql_t sepgsql_database_type:db_blob sepgsql_blob_t; type_transition sepgsql_client_type postgresql_t:db_database sepgsql_db_t;

Quoted 7 lines

The first four statements don't make sense to me; the last one does make sense (i.e. when a postgres client creates a new database, where the only related "object" in view is that object manager's context, label the new database with sepgsql_db_t). That last instance seems valid as a way of expressing types for new databases; the first four statements seem to be more suited to this postgres contexts configuration (as they are independent of client domain entirely).

Quoted 5 lines

If we have a default contexts configuration, then none of the above statements would be needed: speaking of the last statement, in the absence a type_transition, clients that create databases would still get sepgsql_db_t as the type for the database, since that is the default database type.

As I wrote in the reply to Stephen, it is not a default context. These rules are used to initialize SE-PostgreSQL itself with proper security context.

> Nonetheless, it sounds like you don't have a problem with the libselinux

Quoted 3 lines

change, as long as its just for the default contexts only, right? Then creating objects with something other than the default context would be the job of type_transition.

What do you think the type_transition rules on db_database class should be described as a relationship between a client process and ... ?

I don't think we need default contexts for any database object managed under database itself (like table, column, procedure, ...).

Quoted 17 lines · KaiGai Kohei

Quoted 16 lines · Christopher J. PeBenito

Quoted 15 lines · Stephen Smalley

Quoted 7 lines · Christopher J. PeBenito

I mainly had an issue with statements like:

type_transition postgresql_t postgresql_t:db_database sepgsql_db_t; type_transition postgresql_t sepgsql_database_type:db_table sepgsql_sysobj_t; type_transition postgresql_t sepgsql_database_type:db_procedure sepgsql_proc_t; type_transition postgresql_t sepgsql_database_type:db_blob sepgsql_blob_t; type_transition sepgsql_client_type postgresql_t:db_database sepgsql_db_t;

The first four statements don't make sense to me; the last one does make sense (i.e. when a postgres client creates a new database, where the only related "object" in view is that object manager's context, label the new database with sepgsql_db_t). That last instance seems valid as a way of expressing types for new databases; the first four statements seem to be more suited to this postgres contexts configuration (as they are independent of client domain entirely).

Quoted 8 lines

Quoted 5 lines

If we have a default contexts configuration, then none of the above statements would be needed: speaking of the last statement, in the absence a type_transition, clients that create databases would still get sepgsql_db_t as the type for the database, since that is the default database type.

As I wrote in the reply to Stephen, it is not a default context. These rules are used to initialize SE-PostgreSQL itself with proper security context.

In my opinion, it is in fact the default context, despite what you say. Otherwise you wouldn't have all sorts of type_transitions to the above types for not only the server, but the generic clients. I suspect you would never want to run with no type transitions and have all of the objects labeled postgresql_t. That seems like a bad default configuration.

Quoted 6 lines

> Nonetheless, it sounds like you don't have a problem with the libselinux

Quoted 3 lines

change, as long as its just for the default contexts only, right? Then creating objects with something other than the default context would be the job of type_transition.

What do you think the type_transition rules on db_database class should be described as a relationship between a client process and ... ?

I suspect that there is no right answer, only a less bad answer, which would have to be the server process type. Unfortunately I don't see anything better, unless you want to transition on the default database type.

Quoted 2 lines

I don't think we need default contexts for any database object managed under database itself (like table, column, procedure, ...).

I don't agree.

Quoted 51 lines · Christopher J. PeBenito

Quoted 42 lines · Stephen Smalley

Quoted 17 lines · KaiGai Kohei

Hello,

The attached patch enables to obtain the default security context of newly created database, defined at /etc/selinux/*/contexts/postgresql_contexts .

The format is as follows:
--------
#
# Config file for SE-PostgreSQL
#
# <domain of client> <type of newly created database>
unconfined_t sepgsql_db_t
* sepgsql_db_t
--------

'*' means default security context, if given key is not matched for any entry.

Quoted 8 lines

This API requires the security context of client as a key, and it returns a security context to be attached for a newly created database. It has a type field defined in the right-hand of config file, and inherits user and lower-range field of given security context as a key.

e.g)
selabel_lookup(sehandle, &context, "user_u:user_r:user_t:s0", 0); returns "user_u:object_r:sepgsql_db_t:s0".

Chris is investigating the use of roles on objects in order to provide more fully featured RBAC support without requiring use of per-role domains. Hardcoding the use of object_r won't be future compatible for that situation, and more generally we don't want to hardcode policy information in libselinux at all.

I'm also unclear as to why type_transition rules aren't a better way of expressing the above, although I know you've been discussing this with Chris for some time. Logically I'd expect the client domain to be the source type of the transition, and the type for the newly created database to be the new/result type of the transition. What to use as the target type is less clear; we'd have a similar issue if we were to use type_transitions for e.g. sockets. It could either be the client domain both as source and target (self relationship, no related object) or the client domain as source and the object manager domain as target.

Quoted 2 lines

Chris, what is the objection to using type transitions here, as they are for labeling new objects and this seems to fit that situation?

I think KaiGai took my idea a little to far. My issue was just to have postgres determine what the default label for its objects are via postgresql_contexts. A derived role/type still makes sense to be stated via (type|role)_transition. I suspect there was confusion on this point. I mainly had an issue with statements like:

Quoted 5 lines

type_transition postgresql_t postgresql_t:db_database sepgsql_db_t; type_transition postgresql_t sepgsql_database_type:db_table sepgsql_sysobj_t; type_transition postgresql_t sepgsql_database_type:db_procedure sepgsql_proc_t; type_transition postgresql_t sepgsql_database_type:db_blob sepgsql_blob_t; type_transition sepgsql_client_type postgresql_t:db_database sepgsql_db_t;

The first four statements don't make sense to me; the last one does make sense (i.e. when a postgres client creates a new database, where the only related "object" in view is that object manager's context, label the new database with sepgsql_db_t). That last instance seems valid as a way of expressing types for new databases; the first four statements seem to be more suited to this postgres contexts configuration (as they are independent of client domain entirely).

Quoted 7 lines

which I feel should be instead be expressed in a postgresql_contexts file that says the default context for a database is ::seqpgsql_db_t, default context for table is ::sepgsql_sysobj_t, etc.

This makes perfect sense staying as a type_transition in the policy:

type_transition staff_t sepgsql_sysobj_t:db_tuple staff_sepgsql_sysobj_t;

Quoted 58 lines · Stephen Smalley

Quoted 51 lines · Christopher J. PeBenito

Quoted 42 lines · Stephen Smalley

Quoted 17 lines · KaiGai Kohei

Hello,

The attached patch enables to obtain the default security context of newly created database, defined at /etc/selinux/*/contexts/postgresql_contexts .

The format is as follows:
--------
#
# Config file for SE-PostgreSQL
#
# <domain of client> <type of newly created database>
unconfined_t sepgsql_db_t
* sepgsql_db_t
--------

'*' means default security context, if given key is not matched for any entry.

Quoted 8 lines

This API requires the security context of client as a key, and it returns a security context to be attached for a newly created database. It has a type field defined in the right-hand of config file, and inherits user and lower-range field of given security context as a key.

e.g)
selabel_lookup(sehandle, &context, "user_u:user_r:user_t:s0", 0); returns "user_u:object_r:sepgsql_db_t:s0".

Chris is investigating the use of roles on objects in order to provide more fully featured RBAC support without requiring use of per-role domains. Hardcoding the use of object_r won't be future compatible for that situation, and more generally we don't want to hardcode policy information in libselinux at all.

I'm also unclear as to why type_transition rules aren't a better way of expressing the above, although I know you've been discussing this with Chris for some time. Logically I'd expect the client domain to be the source type of the transition, and the type for the newly created database to be the new/result type of the transition. What to use as the target type is less clear; we'd have a similar issue if we were to use type_transitions for e.g. sockets. It could either be the client domain both as source and target (self relationship, no related object) or the client domain as source and the object manager domain as target.

Quoted 2 lines

Chris, what is the objection to using type transitions here, as they are for labeling new objects and this seems to fit that situation?

I think KaiGai took my idea a little to far. My issue was just to have postgres determine what the default label for its objects are via postgresql_contexts. A derived role/type still makes sense to be stated via (type|role)_transition. I suspect there was confusion on this point. I mainly had an issue with statements like:

Quoted 5 lines

type_transition postgresql_t postgresql_t:db_database sepgsql_db_t; type_transition postgresql_t sepgsql_database_type:db_table sepgsql_sysobj_t; type_transition postgresql_t sepgsql_database_type:db_procedure sepgsql_proc_t; type_transition postgresql_t sepgsql_database_type:db_blob sepgsql_blob_t; type_transition sepgsql_client_type postgresql_t:db_database sepgsql_db_t;

Quoted 7 lines

The first four statements don't make sense to me; the last one does make sense (i.e. when a postgres client creates a new database, where the only related "object" in view is that object manager's context, label the new database with sepgsql_db_t). That last instance seems valid as a way of expressing types for new databases; the first four statements seem to be more suited to this postgres contexts configuration (as they are independent of client domain entirely).

When SE-PostgreSQL initializes itself, a server process is a client process in same time. The first four rules are necessary to attach proper context of any system object on initialization.

It does not means something default.

In the "default" behavior, if we have no type_transition,
- a newly created database inherits the type of server process
- a newly created table/procedure/largeobject inherits the type of database
- a newly created column/tuple inherits the type of table

Quoted 8 lines

Quoted 8 lines

which I feel should be instead be expressed in a postgresql_contexts file that says the default context for a database is ::seqpgsql_db_t, default context for table is ::sepgsql_sysobj_t, etc.

This makes perfect sense staying as a type_transition in the policy:

type_transition staff_t sepgsql_sysobj_t:db_tuple staff_sepgsql_sysobj_t;

Quoted 65 lines · KaiGai Kohei

Quoted 57 lines · Stephen Smalley

Quoted 51 lines · Christopher J. PeBenito

Quoted 42 lines · Stephen Smalley

Quoted 17 lines · KaiGai Kohei

Hello,

The attached patch enables to obtain the default security context of newly created database, defined at /etc/selinux/*/contexts/postgresql_contexts .

The format is as follows:
--------
#
# Config file for SE-PostgreSQL
#
# <domain of client> <type of newly created database>
unconfined_t sepgsql_db_t
* sepgsql_db_t
--------

'*' means default security context, if given key is not matched for any entry.

Quoted 8 lines

This API requires the security context of client as a key, and it returns a security context to be attached for a newly created database. It has a type field defined in the right-hand of config file, and inherits user and lower-range field of given security context as a key.

e.g)
selabel_lookup(sehandle, &context, "user_u:user_r:user_t:s0", 0); returns "user_u:object_r:sepgsql_db_t:s0".

Chris is investigating the use of roles on objects in order to provide more fully featured RBAC support without requiring use of per-role domains. Hardcoding the use of object_r won't be future compatible for that situation, and more generally we don't want to hardcode policy information in libselinux at all.

I'm also unclear as to why type_transition rules aren't a better way of expressing the above, although I know you've been discussing this with Chris for some time. Logically I'd expect the client domain to be the source type of the transition, and the type for the newly created database to be the new/result type of the transition. What to use as the target type is less clear; we'd have a similar issue if we were to use type_transitions for e.g. sockets. It could either be the client domain both as source and target (self relationship, no related object) or the client domain as source and the object manager domain as target.

Quoted 2 lines

Chris, what is the objection to using type transitions here, as they are for labeling new objects and this seems to fit that situation?

I think KaiGai took my idea a little to far. My issue was just to have postgres determine what the default label for its objects are via postgresql_contexts. A derived role/type still makes sense to be stated via (type|role)_transition. I suspect there was confusion on this point. I mainly had an issue with statements like:

Quoted 5 lines

type_transition postgresql_t postgresql_t:db_database sepgsql_db_t; type_transition postgresql_t sepgsql_database_type:db_table sepgsql_sysobj_t; type_transition postgresql_t sepgsql_database_type:db_procedure sepgsql_proc_t; type_transition postgresql_t sepgsql_database_type:db_blob sepgsql_blob_t; type_transition sepgsql_client_type postgresql_t:db_database sepgsql_db_t;

Quoted 7 lines

The first four statements don't make sense to me; the last one does make sense (i.e. when a postgres client creates a new database, where the only related "object" in view is that object manager's context, label the new database with sepgsql_db_t). That last instance seems valid as a way of expressing types for new databases; the first four statements seem to be more suited to this postgres contexts configuration (as they are independent of client domain entirely).

Quoted 3 lines

When SE-PostgreSQL initializes itself, a server process is a client process in same time. The first four rules are necessary to attach proper context of any system object on initialization.

Hmm...in that case, type_transition makes sense for that initialization.

Quoted 2 lines

It does not means something default.

Quoted 4 lines

In the "default" behavior, if we have no type_transition,
- a newly created database inherits the type of server process
- a newly created table/procedure/largeobject inherits the type of database
- a newly created column/tuple inherits the type of table

So is that "default" behavior fundamentally a problem? Do we really need these other contexts at all?

Quoted 7 lines

Quoted 7 lines

Quoted 7 lines

which I feel should be instead be expressed in a postgresql_contexts file that says the default context for a database is ::seqpgsql_db_t, default context for table is ::sepgsql_sysobj_t, etc.

This makes perfect sense staying as a type_transition in the policy:

type_transition staff_t sepgsql_sysobj_t:db_tuple staff_sepgsql_sysobj_t;

Quoted 3 lines

e.g)
selabel_lookup(sehandle, &context, "user_u:user_r:user_t:s0", 0); returns "user_u:object_r:sepgsql_db_t:s0".

Chris is investigating the use of roles on objects in order to provide more fully featured RBAC support without requiring use of per-role domains. Hardcoding the use of object_r won't be future compatible for that situation, and more generally we don't want to hardcode policy information in libselinux at all.

I'm also unclear as to why type_transition rules aren't a better way of expressing the above, although I know you've been discussing this with Chris for some time. Logically I'd expect the client domain to be the source type of the transition, and the type for the newly created database to be the new/result type of the transition. What to use as the target type is less clear; we'd have a similar issue if we were to use type_transitions for e.g. sockets. It could either be the client domain both as source and target (self relationship, no related object) or the client domain as source and the object manager domain as target.