[PATCH] libselinux: add support for /contexts/postgresql_contexts

[PATCH] libselinux: add support for /contexts/postgresql_contexts

[KaiGai Kohei]

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

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 <kaigai@ak.jp.nec.com>
--
 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(-)
-- 
OSS Platform Development Division, NEC
KaiGai Kohei <kaigai@ak.jp.nec.com>

[-- Attachment #2: libselinux-add-pgsql-label.patch --]
[-- Type: text/x-patch, Size: 9554 bytes --]

Index: libselinux/include/selinux/label.h
===================================================================
--- libselinux/include/selinux/label.h	(revision 2883)
+++ libselinux/include/selinux/label.h	(working copy)
@@ -29,6 +29,8 @@
 #define SELABEL_CTX_MEDIA	1
 /* x contexts */
 #define SELABEL_CTX_X		2
+/* pgsql database contexts */
+#define SELABEL_CTX_PGSQL	3
 
 /*
  * Available options
Index: libselinux/include/selinux/selinux.h
===================================================================
--- libselinux/include/selinux/selinux.h	(revision 2883)
+++ libselinux/include/selinux/selinux.h	(working copy)
@@ -460,6 +460,7 @@
 extern const char *selinux_homedir_context_path(void);
 extern const char *selinux_media_context_path(void);
 extern const char *selinux_x_context_path(void);
+extern const char *selinux_pgsql_context_path(void);
 extern const char *selinux_contexts_path(void);
 extern const char *selinux_securetty_types_path(void);
 extern const char *selinux_booleans_path(void);
Index: libselinux/src/file_path_suffixes.h
===================================================================
--- libselinux/src/file_path_suffixes.h	(revision 2883)
+++ libselinux/src/file_path_suffixes.h	(working copy)
@@ -19,3 +19,4 @@
     S_(FILE_CONTEXTS_HOMEDIR, "/contexts/files/file_contexts.homedirs")
     S_(FILE_CONTEXTS_LOCAL, "/contexts/files/file_contexts.local")
     S_(X_CONTEXTS, "/contexts/x_contexts")
+    S_(PGSQL_CONTEXTS, "/contexts/postgresql_contexts")
Index: libselinux/src/label_pgsql.c
===================================================================
--- libselinux/src/label_pgsql.c	(revision 0)
+++ libselinux/src/label_pgsql.c	(revision 0)
@@ -0,0 +1,209 @@
+/*
+ * Media contexts backend for SE-PostgreSQL database contexts
+ *
+ * Author: KaiGai Kohei <kaigai@ak.jp.nec.com>
+ */
+#include <ctype.h>
+#include <stdio.h>
+#include <stdlib.h>
+#include <errno.h>
+#include "callbacks.h"
+#include "label_internal.h"
+
+typedef struct pgsql_entry {
+	struct pgsql_entry *next;
+	char *key, *type;
+} pgsql_entry;
+
+static void pgsql_close(struct selabel_handle *h)
+{
+	pgsql_entry *entry, *next_entry;
+
+	for (entry = h->data; entry != NULL; entry = next_entry) {
+		next_entry = entry->next;
+
+		if (entry->key)
+			free(entry->key);
+		free(entry->type);
+		free(entry);
+	}
+	h->data = NULL;
+}
+
+static struct selabel_lookup_rec *pgsql_lookup(struct selabel_handle *h,
+					       const char *key, int type)
+{
+	struct selabel_lookup_rec *lr;
+	pgsql_entry *head = h->data;
+	pgsql_entry *entry, *default_entry = NULL;
+	security_context_t context;
+	char *user, *role, *domain, *range;
+
+	if (type != 0) {
+		errno = EINVAL;
+		return NULL;
+	}
+
+	/* pick up user's domain */
+	if (selinux_trans_to_raw_context((security_context_t)key, &context) < 0)
+		return NULL;
+
+	user = strtok(context, ":");
+	role = strtok(NULL, ":");
+	domain = strtok(NULL, ":");
+	range = strtok(NULL, "-");
+
+	for (entry = head; entry != NULL; entry = entry->next) {
+		if (!entry->key) {
+			default_entry = entry;
+			continue;
+		}
+		if (!strcmp(domain, entry->key))
+			goto found;
+	}
+	/* not found */
+	if (!default_entry) {
+		errno = ENOENT;
+		goto error0;
+	}
+	entry = default_entry;
+
+found:
+	lr = malloc(sizeof(struct selabel_lookup_rec));
+	if (!lr)
+		goto error0;
+
+	lr->ctx_raw = malloc(strlen(user) + sizeof("object_r") + strlen(entry->type) + 4
+			     + (!range ? 0 : strlen(range)));
+	if (!lr->ctx_raw)
+		goto error1;
+
+	if (!range) {
+		sprintf(lr->ctx_raw, "%s:object_r:%s", user, entry->type);
+	} else {
+		sprintf(lr->ctx_raw, "%s:object_r:%s:%s", user, entry->type, range);
+	}
+
+	if (security_check_context_raw(lr->ctx_raw) < 0)
+		goto error2;
+
+	freecon(context);
+
+	return lr;
+
+error2:
+	free(lr->ctx_raw);
+error1:
+	free(lr);
+error0:
+	freecon(context);
+	return NULL;
+}
+
+static void pgsql_lookup_post(struct selabel_handle *h,
+			      struct selabel_lookup_rec *lr)
+{
+	h = h;	/* to kill compiler warnings */
+
+	free(lr->ctx_raw);
+	if (lr->ctx_trans)
+		free(lr->ctx_trans);
+	free(lr);
+}
+
+static void pgsql_stats(struct selabel_handle *h)
+{
+	pgsql_entry *entry, *head = h->data;
+	unsigned int count;
+	int has_default = 0;
+
+	for (count=0, entry = head; entry != NULL; count++, entry = entry->next) {
+		if (!entry->key)
+			has_default = 1;
+	}
+
+	selinux_log(SELINUX_INFO, "%u entries%s\n",
+		    count,
+		    has_default ? " has default type," : "");
+}
+
+pgsql_entry *read_a_line(FILE *filp)
+{
+	pgsql_entry *entry;
+	char buffer[4096];
+	char *ptr, *key, *type;
+	int items;
+
+retry:
+	ptr = fgets(buffer, sizeof(buffer), filp);
+	if (!ptr)
+		return NULL;
+
+	/* skip comment line */
+	while (isspace(*ptr))
+		ptr++;
+	if (*ptr == '#' || *ptr == '\0')
+		goto retry;
+
+	items = sscanf(ptr, "%as %as", &key, &type);
+	if (items < 2) {
+		if (items > 0)
+			free(key);
+		goto retry;
+	}
+
+	/* make a pgsql_entry */
+	entry = malloc(sizeof(pgsql_entry));
+	if (!entry) {
+		free(key);
+		free(type);
+		return NULL;
+	}
+	memset(entry, 0, sizeof(pgsql_entry));
+
+	if (!strcmp(key, "*")) {
+		free(key);
+		key = NULL;	/* default */
+	}
+
+	entry->key = key;
+	entry->type = type;
+
+	return entry;
+}
+
+int selabel_pgsql_init(struct selabel_handle *rec,
+		       struct selinux_opt *opts,
+		       unsigned int nopts)
+{
+	FILE *filp;
+	const char *path = NULL;
+	pgsql_entry *entry, *head = NULL;
+
+	/* parse options */
+	while (nopts--) {
+		if (opts[nopts].type == SELABEL_OPT_PATH)
+			path = opts[nopts].value;
+	}
+
+	/* open the specified file */
+	if (!path)
+		path = selinux_pgsql_context_path();
+	filp = fopen(path, "rb");
+	if (!filp)
+		return -1;
+
+	while ((entry = read_a_line(filp)) != NULL) {
+		entry->next = head;
+		head = entry;
+	}
+	fclose(filp);
+
+	rec->data = head;
+	rec->func_close	      = pgsql_close;
+	rec->func_lookup      = pgsql_lookup;
+	rec->func_lookup_post = pgsql_lookup_post;
+	rec->func_stats       = pgsql_stats;
+
+	return 0;
+}
Index: libselinux/src/selinux_internal.h
===================================================================
--- libselinux/src/selinux_internal.h	(revision 2883)
+++ libselinux/src/selinux_internal.h	(working copy)
@@ -66,6 +66,7 @@
     hidden_proto(selinux_customizable_types_path)
     hidden_proto(selinux_media_context_path)
     hidden_proto(selinux_x_context_path)
+    hidden_proto(selinux_pgsql_context_path)
     hidden_proto(selinux_path)
     hidden_proto(selinux_check_passwd_access)
     hidden_proto(selinux_check_securetty_context)
Index: libselinux/src/selinux_config.c
===================================================================
--- libselinux/src/selinux_config.c	(revision 2883)
+++ libselinux/src/selinux_config.c	(working copy)
@@ -39,7 +39,8 @@
 #define FILE_CONTEXTS_LOCAL 17
 #define SECURETTY_TYPES   18
 #define X_CONTEXTS        19
-#define NEL               20
+#define PGSQL_CONTEXTS    20
+#define NEL               21
 
 /* New layout is relative to SELINUXDIR/policytype. */
 static char *file_paths[NEL];
@@ -383,3 +384,9 @@
 }
 
 hidden_def(selinux_x_context_path)
+
+const char *selinux_pgsql_context_path()
+{
+	return get_path(PGSQL_CONTEXTS);
+}
+hidden_def(selinux_pgsql_context_path);
Index: libselinux/src/label.c
===================================================================
--- libselinux/src/label.c	(revision 2883)
+++ libselinux/src/label.c	(working copy)
@@ -20,7 +20,8 @@
 static selabel_initfunc initfuncs[] = {
 	&selabel_file_init,
 	&selabel_media_init,
-	&selabel_x_init
+	&selabel_x_init,
+	&selabel_pgsql_init,
 };
 
 /*
@@ -84,6 +85,13 @@
 	return rec;
 }
 
+static void selabel_lookup_post_common(struct selabel_handle *rec,
+				       struct selabel_lookup_rec *lr)
+{
+	if (rec->func_lookup_post)
+		rec->func_lookup_post(rec, lr);
+}
+
 static struct selabel_lookup_rec *
 selabel_lookup_common(struct selabel_handle *rec, int translating,
 		      const char *key, int type)
@@ -92,12 +100,16 @@
 	if (!lr)
 		return NULL;
 
-	if (compat_validate(rec, lr, "file_contexts", 0))
+	if (compat_validate(rec, lr, "file_contexts", 0)) {
+		selabel_lookup_post_common(rec, lr);
 		return NULL;
+	}
 
 	if (translating && !lr->ctx_trans &&
-	    selinux_raw_to_trans_context(lr->ctx_raw, &lr->ctx_trans))
+	    selinux_raw_to_trans_context(lr->ctx_raw, &lr->ctx_trans)) {
+		selabel_lookup_post_common(rec, lr);
 		return NULL;
+	}
 
 	return lr;
 }
@@ -112,6 +124,7 @@
 		return -1;
 
 	*con = strdup(lr->ctx_trans);
+	selabel_lookup_post_common(rec, lr);
 	return *con ? 0 : -1;
 }
 
@@ -125,6 +138,7 @@
 		return -1;
 
 	*con = strdup(lr->ctx_raw);
+	selabel_lookup_post_common(rec, lr);
 	return *con ? 0 : -1;
 }
 
Index: libselinux/src/label_internal.h
===================================================================
--- libselinux/src/label_internal.h	(revision 2883)
+++ libselinux/src/label_internal.h	(working copy)
@@ -23,6 +23,8 @@
 		      unsigned nopts) hidden;
 int selabel_x_init(struct selabel_handle *rec, struct selinux_opt *opts,
 		   unsigned nopts) hidden;
+int selabel_pgsql_init(struct selabel_handle *rec, struct selinux_opt *opts,
+		       unsigned nopts) hidden;
 
 /*
  * Labeling internal structures
@@ -41,6 +43,8 @@
 	/* labeling operations */
 	struct selabel_lookup_rec *(*func_lookup) (struct selabel_handle *h,
 						   const char *key, int type);
+	void (*func_lookup_post) (struct selabel_handle *h,
+				  struct selabel_lookup_rec *lr);
 	void (*func_close) (struct selabel_handle *h);
 	void (*func_stats) (struct selabel_handle *h);
 

Re: [PATCH] libselinux: add support for /contexts/postgresql_contexts

[Stephen Smalley]

On Mon, 2008-05-26 at 19:30 +0900, KaiGai Kohei wrote:
> 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".

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?

> 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 <kaigai@ak.jp.nec.com>
> --
>  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(-)
-- 
Stephen Smalley
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: [PATCH] libselinux: add support for /contexts/postgresql_contexts

[Christopher J. PeBenito]

On Tue, 2008-05-27 at 13:14 -0400, Stephen Smalley wrote:
> On Mon, 2008-05-26 at 19:30 +0900, KaiGai Kohei wrote:
> > 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".
> 
> 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?

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;

-- 
Chris PeBenito
Tresys Technology, LLC
(410) 290-1411 x150


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: [PATCH] libselinux: add support for /contexts/postgresql_contexts

[Stephen Smalley]

On Tue, 2008-05-27 at 13:55 -0400, Christopher J. PeBenito wrote:
> On Tue, 2008-05-27 at 13:14 -0400, Stephen Smalley wrote:
> > On Mon, 2008-05-26 at 19:30 +0900, KaiGai Kohei wrote:
> > > 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".
> > 
> > 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?
> 
> 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;

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

> 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;
> 
-- 
Stephen Smalley
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: [PATCH] libselinux: add support for /contexts/postgresql_contexts

[Christopher J. PeBenito]

On Tue, 2008-05-27 at 14:34 -0400, Stephen Smalley wrote:
> On Tue, 2008-05-27 at 13:55 -0400, Christopher J. PeBenito wrote:
> > On Tue, 2008-05-27 at 13:14 -0400, Stephen Smalley wrote:
> > > On Mon, 2008-05-26 at 19:30 +0900, KaiGai Kohei wrote:
> > > > 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".
> > > 
> > > 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?
> > 
> > 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;
> 
> 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.

> > 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;
> > 
-- 
Chris PeBenito
Tresys Technology, LLC
(410) 290-1411 x150


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: [PATCH] libselinux: add support for /contexts/postgresql_contexts

[Stephen Smalley]

On Tue, 2008-05-27 at 14:55 -0400, Christopher J. PeBenito wrote:
> On Tue, 2008-05-27 at 14:34 -0400, Stephen Smalley wrote:
> > On Tue, 2008-05-27 at 13:55 -0400, Christopher J. PeBenito wrote:
> > > On Tue, 2008-05-27 at 13:14 -0400, Stephen Smalley wrote:
> > > > On Mon, 2008-05-26 at 19:30 +0900, KaiGai Kohei wrote:
> > > > > 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".
> > > > 
> > > > 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?
> > > 
> > > 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;
> > 
> > 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.

Yes, that sounds right to me.

> 
> > > 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;
> > > 
-- 
Stephen Smalley
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: [PATCH] libselinux: add support for /contexts/postgresql_contexts

[Eamon Walsh]

Christopher J. PeBenito wrote:
> On Tue, 2008-05-27 at 14:34 -0400, Stephen Smalley wrote:
>   
>> On Tue, 2008-05-27 at 13:55 -0400, Christopher J. PeBenito wrote:
>>     
>>> On Tue, 2008-05-27 at 13:14 -0400, Stephen Smalley wrote:
>>>       
>>>> On Mon, 2008-05-26 at 19:30 +0900, KaiGai Kohei wrote:
>>>>         
>>>>> 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".
>>>>>           

The selabel functionality is meant for situations where you want to 
label an object but you don't have the appropriate inputs to a 
type-transition, only some name for the object that comes from an 
external namespace, e.g. file name, X windows property name, etc.

For example, if you wanted to label databases or tables differently 
depending on their name, selabel would help with this.  Doesn't Postgres 
have default, administrative tables that contain all the permissions, 
user names, and other bookkeeping?  They have fixed names, so they would 
be a prime candidate for selabel support.

Here, you do have a source context, so please use transitions for this 
(see below).


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

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.

The X server does the same kind of thing for objects that are created by 
the server itself, such as the root window.  A type transition is 
performed to label it taking the same form as the rules above.  I had a 
type transition from xserver_t to label it (remember x_root_window_t?)  
IIRC you got rid of that type.

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


I don't see why we need this file if the default names are really just 
alternative ways of saying "postgresql_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;
>>>
>>>       


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


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: [PATCH] libselinux: add support for /contexts/postgresql_contexts

[Christopher J. PeBenito]

On Tue, 2008-05-27 at 16:15 -0400, Eamon Walsh wrote:
> Christopher J. PeBenito wrote:
> > On Tue, 2008-05-27 at 14:34 -0400, Stephen Smalley wrote:
> >   
> >> On Tue, 2008-05-27 at 13:55 -0400, Christopher J. PeBenito wrote:
> >>> 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.

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.

-- 
Chris PeBenito
Tresys Technology, LLC
(410) 290-1411 x150


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: [PATCH] libselinux: add support for /contexts/postgresql_contexts

[Eamon Walsh]

Christopher J. PeBenito wrote:
> On Tue, 2008-05-27 at 16:15 -0400, Eamon Walsh wrote:
>   
>> Christopher J. PeBenito wrote:
>>     
>>> On Tue, 2008-05-27 at 14:34 -0400, Stephen Smalley wrote:
>>>   
>>>       
>>>> On Tue, 2008-05-27 at 13:55 -0400, Christopher J. PeBenito wrote:
>>>>         
>>>>> 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.
>>     
>
> 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;




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


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: [PATCH] libselinux: add support for /contexts/postgresql_contexts

[Christopher J. PeBenito]

On Thu, 2008-05-29 at 14:05 -0400, Eamon Walsh wrote:
> Christopher J. PeBenito wrote:
> > On Tue, 2008-05-27 at 16:15 -0400, Eamon Walsh wrote:
> >   
> >> Christopher J. PeBenito wrote:
> >>     
> >>> On Tue, 2008-05-27 at 14:34 -0400, Stephen Smalley wrote:
> >>>   
> >>>       
> >>>> On Tue, 2008-05-27 at 13:55 -0400, Christopher J. PeBenito wrote:
> >>>>         
> >>>>> 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.
> >>     
> >
> > 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;

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

-- 
Chris PeBenito
Tresys Technology, LLC
(410) 290-1411 x150


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: [PATCH] libselinux: add support for /contexts/postgresql_contexts

[Eamon Walsh]

Christopher J. PeBenito wrote:
> On Thu, 2008-05-29 at 14:05 -0400, Eamon Walsh wrote:
>   
>> Christopher J. PeBenito wrote:
>>     
>>> On Tue, 2008-05-27 at 16:15 -0400, Eamon Walsh wrote:
>>>   
>>>       
>>>> Christopher J. PeBenito wrote:
>>>>     
>>>>         
>>>>> On Tue, 2008-05-27 at 14:34 -0400, Stephen Smalley wrote:
>>>>>   
>>>>>       
>>>>>           
>>>>>> On Tue, 2008-05-27 at 13:55 -0400, Christopher J. PeBenito wrote:
>>>>>>         
>>>>>>             
>>>>>>> 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.
>>>>     
>>>>         
>>> 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;
>>     
>
> 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?


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


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: [PATCH] libselinux: add support for /contexts/postgresql_contexts

[Christopher J. PeBenito]

On Thu, 2008-05-29 at 20:22 -0400, Eamon Walsh wrote:
> Christopher J. PeBenito wrote:
> > On Thu, 2008-05-29 at 14:05 -0400, Eamon Walsh wrote:
> >   
> >> Christopher J. PeBenito wrote:
> >>     
> >>> On Tue, 2008-05-27 at 16:15 -0400, Eamon Walsh wrote:
> >>>   
> >>>       
> >>>> Christopher J. PeBenito wrote:
> >>>>     
> >>>>         
> >>>>> On Tue, 2008-05-27 at 14:34 -0400, Stephen Smalley wrote:
> >>>>>   
> >>>>>       
> >>>>>           
> >>>>>> On Tue, 2008-05-27 at 13:55 -0400, Christopher J. PeBenito wrote:
> >>>>>>         
> >>>>>>             
> >>>>>>> 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.
> >>>>     
> >>>>         
> >>> 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;
> >>     
> >
> > 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?

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.

-- 
Chris PeBenito
Tresys Technology, LLC
(410) 290-1411 x150


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: [PATCH] libselinux: add support for /contexts/postgresql_contexts

[KaiGai Kohei]

Christopher J. PeBenito wrote:
> On Thu, 2008-05-29 at 20:22 -0400, Eamon Walsh wrote:
>> Christopher J. PeBenito wrote:
>>> On Thu, 2008-05-29 at 14:05 -0400, Eamon Walsh wrote:
>>>   
>>>> Christopher J. PeBenito wrote:
>>>>     
>>>>> On Tue, 2008-05-27 at 16:15 -0400, Eamon Walsh wrote:
>>>>>   
>>>>>       
>>>>>> Christopher J. PeBenito wrote:
>>>>>>     
>>>>>>         
>>>>>>> On Tue, 2008-05-27 at 14:34 -0400, Stephen Smalley wrote:
>>>>>>>   
>>>>>>>       
>>>>>>>           
>>>>>>>> On Tue, 2008-05-27 at 13:55 -0400, Christopher J. PeBenito wrote:
>>>>>>>>         
>>>>>>>>             
>>>>>>>>> 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.
>>>>>>     
>>>>>>         
>>>>> 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;
>>>>     
>>> 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?
> 
> 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.

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

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: [PATCH] libselinux: add support for /contexts/postgresql_contexts

[Eamon Walsh]

KaiGai Kohei wrote:
> Christopher J. PeBenito wrote:
>   
>> On Thu, 2008-05-29 at 20:22 -0400, Eamon Walsh wrote:
>>     
>>> Christopher J. PeBenito wrote:
>>>       
>>>> On Thu, 2008-05-29 at 14:05 -0400, Eamon Walsh wrote:
>>>>   
>>>>         
>>>>> Christopher J. PeBenito wrote:
>>>>>     
>>>>>           
>>>>>> On Tue, 2008-05-27 at 16:15 -0400, Eamon Walsh wrote:
>>>>>>   
>>>>>>       
>>>>>>             
>>>>>>> Christopher J. PeBenito wrote:
>>>>>>>     
>>>>>>>         
>>>>>>>               
>>>>>>>> On Tue, 2008-05-27 at 14:34 -0400, Stephen Smalley wrote:
>>>>>>>>   
>>>>>>>>       
>>>>>>>>           
>>>>>>>>                 
>>>>>>>>> On Tue, 2008-05-27 at 13:55 -0400, Christopher J. PeBenito wrote:
>>>>>>>>>         
>>>>>>>>>             
>>>>>>>>>                   
>>>>>>>>>> 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.
>>>>>>>     
>>>>>>>         
>>>>>>>               
>>>>>> 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;
>>>>>     
>>>>>           
>>>> 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?
>>>       
>> 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.



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

There is no such API. Either a type transition is used to label
something, or it isn't.


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

Like I said, given that the database objects are named, I think an
selabel-based solution might be best here.


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


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: [PATCH] libselinux: add support for /contexts/postgresql_contexts

[Christopher J. PeBenito]

On Mon, 2008-06-02 at 13:31 -0400, Eamon Walsh wrote:
> KaiGai Kohei wrote:
> > Christopher J. PeBenito wrote:
> >> On Thu, 2008-05-29 at 20:22 -0400, Eamon Walsh wrote:
> >>> Christopher J. PeBenito wrote:
> >>>> On Thu, 2008-05-29 at 14:05 -0400, Eamon Walsh wrote:
> >>>>> Christopher J. PeBenito wrote:
> >>>>>> On Tue, 2008-05-27 at 16:15 -0400, Eamon Walsh wrote:
> >>>>>>> Christopher J. PeBenito wrote:
> >>>>>>>> On Tue, 2008-05-27 at 14:34 -0400, Stephen Smalley wrote:
> >>>>>>>>> On Tue, 2008-05-27 at 13:55 -0400, Christopher J. PeBenito wrote:
> >>>>>>>>>> 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.
> >>>>>>>     
> >>>>>>>         
> >>>>>>>               
> >>>>>> 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;
> >>>>>     
> >>>>>           
> >>>> 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?
> >>>       
> >> 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.

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

-- 
Chris PeBenito
Tresys Technology, LLC
(410) 290-1411 x150


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: [PATCH] libselinux: add support for /contexts/postgresql_contexts

[KaiGai Kohei]

Christopher J. PeBenito wrote:
> On Mon, 2008-06-02 at 13:31 -0400, Eamon Walsh wrote:
>> KaiGai Kohei wrote:
>>> Christopher J. PeBenito wrote:
>>>> On Thu, 2008-05-29 at 20:22 -0400, Eamon Walsh wrote:
>>>>> Christopher J. PeBenito wrote:
>>>>>> On Thu, 2008-05-29 at 14:05 -0400, Eamon Walsh wrote:
>>>>>>> Christopher J. PeBenito wrote:
>>>>>>>> On Tue, 2008-05-27 at 16:15 -0400, Eamon Walsh wrote:
>>>>>>>>> Christopher J. PeBenito wrote:
>>>>>>>>>> On Tue, 2008-05-27 at 14:34 -0400, Stephen Smalley wrote:
>>>>>>>>>>> On Tue, 2008-05-27 at 13:55 -0400, Christopher J. PeBenito wrote:
>>>>>>>>>>>> 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.
>>>>>>>>>     
>>>>>>>>>         
>>>>>>>>>               
>>>>>>>> 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;
>>>>>>>     
>>>>>>>           
>>>>>> 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?
>>>>>       
>>>> 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.
> 
> 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.

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

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: [PATCH] libselinux: add support for /contexts/postgresql_contexts

[Christopher J. PeBenito]

On Tue, 2008-06-03 at 19:25 +0900, KaiGai Kohei wrote:
> Christopher J. PeBenito wrote:

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

Unfortunately self doesn't work in type_transitions.

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

-- 
Chris PeBenito
Tresys Technology, LLC
(410) 290-1411 x150


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: [PATCH] libselinux: add support for /contexts/postgresql_contexts

[KaiGai Kohei]

Christopher J. PeBenito wrote:
> On Tue, 2008-06-03 at 19:25 +0900, KaiGai Kohei wrote:
>> Christopher J. PeBenito wrote:
> 
>>> 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.
> 
> Unfortunately self doesn't work in type_transitions.

Oops,

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

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?

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

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: [PATCH] libselinux: add support for /contexts/postgresql_contexts

[Joshua Brindle]

KaiGai Kohei wrote:
> Christopher J. PeBenito wrote:

<snip>

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

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?


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: [PATCH] libselinux: add support for /contexts/postgresql_contexts

[KaiGai Kohei]

Joshua Brindle wrote:
> KaiGai Kohei wrote:
>> Christopher J. PeBenito wrote:
> 
> <snip>
> 
>> 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.

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

>>   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?
> 
> 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,
-- 
OSS Platform Development Division, NEC
KaiGai Kohei <kaigai@ak.jp.nec.com>

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: [PATCH] libselinux: add support for /contexts/postgresql_contexts

[Eamon Walsh]

KaiGai Kohei wrote:
> Joshua Brindle wrote:
>   
>> KaiGai Kohei wrote:
>>     
>>> Christopher J. PeBenito wrote:
>>>       
>> <snip>
>>
>>     
>>> 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.
>>>       
>
> db_blob:{write} is also checked here...
>
>   
>>>   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?
>>>       
>> 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.
>   

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.



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


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


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: [PATCH] libselinux: add support for /contexts/postgresql_contexts

[KaiGai Kohei]

Eamon Walsh wrote:
> KaiGai Kohei wrote:
>> Joshua Brindle wrote:
>>   
>>> KaiGai Kohei wrote:
>>>     
>>>> Christopher J. PeBenito wrote:
>>>>       
>>> <snip>
>>>
>>>     
>>>> 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.
>>>>       
>> db_blob:{write} is also checked here...
>>
>>   
>>>>   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?
>>>>       
>>> 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.
>>   
> 
> 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.

No, it seems to kernel as if the write() operation is done by postgresql
server process.

The facility of large object allows postgresql server process to read/write
files on server host according to the operations come from client.

e.g)
# SELECT lo_import('/etc/passwd');

This query come from client (but restricted to database super user) enables
postgresql server process to read the given file and insert it as database
records. All interactions between the kernel and userspace are done as
normal i/o operations invoked by a server process, not a client.

Thanks,

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


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

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: [PATCH] libselinux: add support for /contexts/postgresql_contexts

[Christopher J. PeBenito]

On Wed, 2008-06-04 at 13:03 +0900, KaiGai Kohei wrote:
> Christopher J. PeBenito wrote:
> > On Tue, 2008-06-03 at 19:25 +0900, KaiGai Kohei wrote:
> >> Christopher J. PeBenito wrote:
> > 
> >>> 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:

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

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

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

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

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

-- 
Chris PeBenito
Tresys Technology, LLC
(410) 290-1411 x150


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: [PATCH] libselinux: add support for /contexts/postgresql_contexts

[KaiGai Kohei]

Christopher J. PeBenito wrote:
> On Wed, 2008-06-04 at 13:03 +0900, KaiGai Kohei wrote:
>> Christopher J. PeBenito wrote:
>>> On Tue, 2008-06-03 at 19:25 +0900, KaiGai Kohei wrote:
>>>> Christopher J. PeBenito wrote:
>>>>> 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:
> 
>>>> - 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.
>>
>> 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.

OK, it is clear enough for me.


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


>> 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?
> 
> I'll defer to Josh on this one since he knows much more about databases
> than I do.

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

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: [PATCH] libselinux: add support for /contexts/postgresql_contexts

[Chris PeBenito]

On Thu, 2008-06-05 at 10:18 +0900, KaiGai Kohei wrote:
> Christopher J. PeBenito wrote:
> > On Wed, 2008-06-04 at 13:03 +0900, KaiGai Kohei wrote:
> >> Christopher J. PeBenito wrote:
> >>> On Tue, 2008-06-03 at 19:25 +0900, KaiGai Kohei wrote:
> >>>> Christopher J. PeBenito wrote:
> >>>>> 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:
> > 

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

-- 
Chris PeBenito
<pebenito@gentoo.org>
Developer,
Hardened Gentoo Linux
 
Public Key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE6AF9243
Key fingerprint = B0E6 877A 883F A57A 8E6A  CB00 BC8E E42D E6AF 9243


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: [PATCH] libselinux: add support for /contexts/postgresql_contexts

[KaiGai Kohei]

Chris PeBenito wrote:
> On Thu, 2008-06-05 at 10:18 +0900, KaiGai Kohei wrote:
>> Christopher J. PeBenito wrote:
>>> On Wed, 2008-06-04 at 13:03 +0900, KaiGai Kohei wrote:
>>>> Christopher J. PeBenito wrote:
>>>>> On Tue, 2008-06-03 at 19:25 +0900, KaiGai Kohei wrote:
>>>>>> Christopher J. PeBenito wrote:
>>>>>>> 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:
> 
>>>> 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:
>>>
>>> +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.

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

Please wait for days.

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

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: [PATCH] libselinux: add support for /contexts/postgresql_contexts

[KaiGai Kohei]

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

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.

Thanks,

KaiGai Kohei wrote:
> Chris PeBenito wrote:
>> On Thu, 2008-06-05 at 10:18 +0900, KaiGai Kohei wrote:
>>> Christopher J. PeBenito wrote:
>>>> On Wed, 2008-06-04 at 13:03 +0900, KaiGai Kohei wrote:
>>>>> Christopher J. PeBenito wrote:
>>>>>> On Tue, 2008-06-03 at 19:25 +0900, KaiGai Kohei wrote:
>>>>>>> Christopher J. PeBenito wrote:
>>>>>>>> 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:
>>>>> 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:
>>>>
>>>> +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.
> 
> OK, I'll send the patch with a comment for tuple-level dontaudit and
> without dontaudit for relabelfrom/relabelto.
> 
> Please wait for days.
> 
> Thanks,


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

[-- Attachment #2: refpolicy-sepgsql-kaigai-final.patch --]
[-- Type: text/x-patch, Size: 22308 bytes --]

Index: refpolicy/policy/modules/kernel/kernel.if
===================================================================
--- refpolicy/policy/modules/kernel/kernel.if	(revision 2710)
+++ refpolicy/policy/modules/kernel/kernel.if	(working copy)
@@ -2553,6 +2553,35 @@
 
 ########################################
 ## <summary>
+##      Relabelfrom unlabeled database objects of SE-PostgreSQL
+## </summary>
+## <param name="domain">
+##      <summary>
+##      Domain allowed access.
+##      </summary>
+## </param>
+#
+interface(`kernel_relabelfrom_unlabeled_database',`
+	gen_require(`
+		type unlabeled_t;
+
+		class db_database { setattr relabelfrom };
+		class db_table { setattr relabelfrom };
+		class db_procedure { setattr relabelfrom };
+		class db_column { setattr relabelfrom };
+		class db_tuple { update relabelfrom };
+		class db_blob { setattr relabelfrom };
+	')
+	allow $1 unlabeled_t:db_database { setattr relabelfrom };
+	allow $1 unlabeled_t:db_table { setattr relabelfrom };
+	allow $1 unlabeled_t:db_procedure { setattr relabelfrom };
+	allow $1 unlabeled_t:db_column { setattr relabelfrom };
+	allow $1 unlabeled_t:db_tuple { update relabelfrom };
+	allow $1 unlabeled_t:db_blob { setattr relabelfrom };
+')
+
+########################################
+## <summary>
 ##	Unconfined access to kernel module resources.
 ## </summary>
 ## <param name="domain">
Index: refpolicy/policy/modules/services/postgresql.if
===================================================================
--- refpolicy/policy/modules/services/postgresql.if	(revision 2710)
+++ refpolicy/policy/modules/services/postgresql.if	(working copy)
@@ -1,7 +1,210 @@
 ## <summary>PostgreSQL relational database</summary>
 
+#######################################
+## <summary>
+##      The userdomain template for the SE-PostgreSQL.
+## </summary>
+## <desc>
+##      This template creates a delivered types which are used
+##	for given userdomains.
+## </desc>
+## <param name="userdomain_prefix">
+##      <summary>
+##      The prefix of the user domain (e.g., user
+##      is the prefix for user_t).
+##      </summary>
+## </param>
+## <param name="user_domain">
+## 	<summary>
+##      The type of the user domain.
+##      </summary>
+## </param>
+## <param name="user_role">
+##      <summary>
+##      The role associated with the user domain.
+##      </summary>
+## </param>
+#
+template(`postgresql_userdom_template',`
+	gen_require(`
+		class db_database all_db_database_perms;
+		class db_table all_db_table_perms;
+		class db_procedure all_db_procedure_perms;
+		class db_column all_db_column_perms;
+		class db_tuple all_db_tuple_perms;
+		class db_blob all_db_blob_perms;
+
+		attribute sepgsql_client_type;
+		attribute sepgsql_database_type;
+		attribute sepgsql_sysobj_table_type;
+
+		type sepgsql_trusted_proc_t;
+		type sepgsql_trusted_domain_t;
+	')
+
+	########################################
+	#
+	# Declarations
+	#
+
+	typeattribute $2 sepgsql_client_type;
+
+	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_sysobj_t;
+	postgresql_system_table_object($1_sepgsql_sysobj_t)
+
+	type $1_sepgsql_table_t;
+	postgresql_table_object($1_sepgsql_table_t)
+
+	role $3 types sepgsql_trusted_domain_t;
+
+	##############################
+	#
+	# Client local policy
+	#
+
+	tunable_policy(`sepgsql_enable_users_ddl',`
+		allow $2 $1_sepgsql_table_t  : db_table { create drop };
+		type_transition $2 sepgsql_database_type:db_table $1_sepgsql_table_t;
+
+		allow $2 $1_sepgsql_table_t  : db_column { create drop };
+
+		allow $2 $1_sepgsql_sysobj_t : db_tuple { update insert delete };
+		type_transition $2 sepgsql_sysobj_table_type:db_tuple $1_sepgsql_sysobj_t;
+	')
+
+	allow $2 $1_sepgsql_table_t  : db_table  { getattr setattr use select update insert delete };
+	allow $2 $1_sepgsql_table_t  : db_column { getattr setattr use select update insert };
+	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_blob_t : db_blob { create drop getattr setattr read write };
+	type_transition $2 sepgsql_database_type:db_blob $1_sepgsql_blob_t;
+
+	allow $2 sepgsql_trusted_domain_t:process transition;
+	type_transition $2 sepgsql_trusted_proc_t:process sepgsql_trusted_domain_t;
+')
+
 ########################################
 ## <summary>
+##     Marks as a SE-PostgreSQL loadable shared library module
+## </summary>
+## <param name="type">
+##     <summary>
+##     Type marked as a database object type.
+##     </summary>
+## </param>
+#
+interface(`postgresql_loadable_module',`
+	gen_require(`
+		attribute sepgsql_module_type;
+	')
+
+	typeattribute $1 sepgsql_module_type;
+')
+
+########################################
+## <summary>
+##     Marks as a SE-PostgreSQL database object type
+## </summary>
+## <param name="type">
+##     <summary>
+##     Type marked as a database object type.
+##     </summary>
+## </param>
+#
+interface(`postgresql_database_object',`
+	gen_require(`
+		attribute sepgsql_database_type;
+	')
+
+	typeattribute $1 sepgsql_database_type;
+')
+
+########################################
+## <summary>
+##     Marks as a SE-PostgreSQL table/column/tuple object type
+## </summary>
+## <param name="type">
+##     <summary>
+##     Type marked as a table/column/tuple object type.
+##     </summary>
+## </param>
+#
+interface(`postgresql_table_object',`
+	gen_require(`
+		attribute sepgsql_table_type;
+	')
+
+	typeattribute $1 sepgsql_table_type;
+')
+
+########################################
+## <summary>
+##     Marks as a SE-PostgreSQL system table/column/tuple object type
+## </summary>
+## <param name="type">
+##     <summary>
+##     Type marked as a table/column/tuple object type.
+##     </summary>
+## </param>
+#
+interface(`postgresql_system_table_object',`
+	gen_require(`
+		attribute sepgsql_table_type;
+		attribute sepgsql_sysobj_table_type;
+	')
+
+	typeattribute $1 sepgsql_table_type;
+	typeattribute $1 sepgsql_sysobj_table_type;
+')
+
+########################################
+## <summary>
+##     Marks as a SE-PostgreSQL procedure object type
+## </summary>
+## <param name="type">
+##     <summary>
+##     Type marked as a database object type.
+##     </summary>
+## </param>
+#
+interface(`postgresql_procedure_object',`
+	gen_require(`
+		attribute sepgsql_procedure_type;
+	')
+
+	typeattribute $1 sepgsql_procedure_type;
+')
+
+########################################
+## <summary>
+##     Marks as a SE-PostgreSQL binary large object type
+## </summary>
+## <param name="type">
+##     <summary>
+##     Type marked as a database binary large object type.
+##     </summary>
+## </param>
+#
+interface(`postgresql_blob_object',`
+	gen_require(`
+		attribute sepgsql_blob_type;
+	')
+
+	typeattribute $1 sepgsql_blob_type;
+')
+
+########################################
+## <summary>
 ##	Allow the specified domain to search postgresql's database directory.
 ## </summary>
 ## <param name="domain">
@@ -120,3 +323,60 @@
         # Some versions of postgresql put the sock file in /tmp
 	allow $1 postgresql_tmp_t:sock_file write;
 ')
+
+########################################
+## <summary>
+##      Allow the specified domain unprivileged accesses to unifined database objects
+##	managed by SE-PostgreSQL,
+## </summary>
+## <param name="domain">
+##      <summary>
+##      Domain allowed access.
+##      </summary>
+## </param>
+#
+interface(`postgresql_unpriv_client',`
+	gen_require(`
+		class db_table all_db_table_perms;
+		class db_procedure all_db_procedure_perms;
+		class db_blob all_db_blob_perms;
+
+		attribute sepgsql_client_type;
+		attribute sepgsql_database_type;
+
+		type sepgsql_table_t;
+		type sepgsql_proc_t;
+		type sepgsql_blob_t;
+
+		type sepgsql_trusted_proc_t;
+		type sepgsql_trusted_domain_t;
+	')
+
+	typeattribute $1 sepgsql_client_type;
+
+	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;
+
+	type_transition $1 sepgsql_trusted_proc_t:process sepgsql_trusted_domain_t;
+	allow $1 sepgsql_trusted_domain_t:process transition;
+')
+
+########################################
+## <summary>
+##      Allow the specified domain unconfined accesses to any database objects
+##	managed by SE-PostgreSQL,
+## </summary>
+## <param name="domain">
+##      <summary>
+##      Domain allowed access.
+##      </summary>
+## </param>
+#
+interface(`postgresql_unconfined',`
+	gen_require(`
+		attribute sepgsql_unconfined_type;
+	')
+
+	typeattribute $1 sepgsql_unconfined_type;
+')
Index: refpolicy/policy/modules/services/apache.te
===================================================================
--- refpolicy/policy/modules/services/apache.te	(revision 2710)
+++ refpolicy/policy/modules/services/apache.te	(working copy)
@@ -475,6 +475,7 @@
 optional_policy(`
 	# Allow httpd to work with postgresql
 	postgresql_stream_connect(httpd_t)
+	postgresql_unpriv_client(httpd_t)
 
 	tunable_policy(`httpd_can_network_connect_db',`
 		postgresql_tcp_connect(httpd_t)
Index: refpolicy/policy/modules/services/apache.if
===================================================================
--- refpolicy/policy/modules/services/apache.if	(revision 2710)
+++ refpolicy/policy/modules/services/apache.if	(working copy)
@@ -226,6 +226,10 @@
 	')
 
 	optional_policy(`
+		postgresql_unpriv_client(httpd_$1_script_t)
+	')
+
+	optional_policy(`
 		nscd_socket_use(httpd_$1_script_t)
 	')
 ')
Index: refpolicy/policy/modules/services/postgresql.te
===================================================================
--- refpolicy/policy/modules/services/postgresql.te	(revision 2710)
+++ refpolicy/policy/modules/services/postgresql.te	(working copy)
@@ -1,10 +1,27 @@
 
 policy_module(postgresql,1.5.1)
 
+gen_require(`
+	class db_database all_db_database_perms;
+	class db_table all_db_table_perms;
+	class db_procedure all_db_procedure_perms;
+	class db_column all_db_column_perms;
+	class db_tuple all_db_tuple_perms;
+	class db_blob all_db_blob_perms;
+')
+
 #################################
 #
 # Declarations
 #
+
+## <desc>
+## <p>
+## Allow unprived users to execute DDL statement
+## </p>
+## </desc>
+gen_tunable(sepgsql_enable_users_ddl, true)
+
 type postgresql_t;
 type postgresql_exec_t;
 init_daemon_domain(postgresql_t,postgresql_exec_t)
@@ -27,6 +44,58 @@
 type postgresql_var_run_t;
 files_pid_file(postgresql_var_run_t)
 
+# database clients attribute
+attribute sepgsql_client_type;
+attribute sepgsql_unconfined_type;
+
+# database objects attribute
+attribute sepgsql_database_type;
+attribute sepgsql_table_type;
+attribute sepgsql_sysobj_table_type;
+attribute sepgsql_procedure_type;
+attribute sepgsql_blob_type;
+attribute sepgsql_module_type;
+
+# database object types
+type sepgsql_blob_t;
+postgresql_blob_object(sepgsql_blob_t)
+
+type sepgsql_db_t;
+postgresql_database_object(sepgsql_db_t)
+
+type sepgsql_fixed_table_t;
+postgresql_table_object(sepgsql_fixed_table_t)
+
+type sepgsql_proc_t;
+postgresql_procedure_object(sepgsql_proc_t)
+
+type sepgsql_ro_blob_t;
+postgresql_blob_object(sepgsql_ro_blob_t)
+
+type sepgsql_ro_table_t;
+postgresql_table_object(sepgsql_ro_table_t)
+
+type sepgsql_secret_blob_t;
+postgresql_blob_object(sepgsql_secret_blob_t)
+
+type sepgsql_secret_table_t;
+postgresql_table_object(sepgsql_secret_table_t)
+
+type sepgsql_sysobj_t;
+postgresql_system_table_object(sepgsql_sysobj_t)
+
+type sepgsql_table_t;
+postgresql_table_object(sepgsql_table_t)
+
+type sepgsql_trusted_proc_t;
+postgresql_procedure_object(sepgsql_trusted_proc_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;
+
 ########################################
 #
 # postgresql Local policy
@@ -42,7 +111,21 @@
 allow postgresql_t self:udp_socket create_stream_socket_perms;
 allow postgresql_t self:unix_dgram_socket create_socket_perms;
 allow postgresql_t self:unix_stream_socket create_stream_socket_perms;
+allow postgresql_t self:netlink_selinux_socket create_socket_perms;
 
+allow postgresql_t sepgsql_database_type:db_database *;
+type_transition postgresql_t postgresql_t:db_database sepgsql_db_t;
+
+allow postgresql_t sepgsql_module_type:db_database install_module;
+allow postgresql_t sepgsql_table_type:{ db_table db_column db_tuple } *;
+allow postgresql_t sepgsql_procedure_type:db_procedure *;
+allow postgresql_t sepgsql_blob_type:db_blob *;
+
+# server specific type transitions
+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;
+
 manage_dirs_pattern(postgresql_t,postgresql_db_t,postgresql_db_t)
 manage_files_pattern(postgresql_t,postgresql_db_t,postgresql_db_t)
 manage_lnk_files_pattern(postgresql_t,postgresql_db_t,postgresql_db_t)
@@ -75,6 +158,9 @@
 manage_sock_files_pattern(postgresql_t,postgresql_var_run_t,postgresql_var_run_t)
 files_pid_filetrans(postgresql_t,postgresql_var_run_t,file)
 
+# Database/Loadable module
+allow sepgsql_database_type sepgsql_module_type:db_database load_module;
+
 kernel_read_kernel_sysctls(postgresql_t)
 kernel_read_system_state(postgresql_t)
 kernel_list_proc(postgresql_t)
@@ -101,6 +187,12 @@
 fs_getattr_all_fs(postgresql_t)
 fs_search_auto_mountpoints(postgresql_t)
 
+selinux_get_enforce_mode(postgresql_t)
+selinux_validate_context(postgresql_t)
+selinux_compute_access_vector(postgresql_t)
+selinux_compute_create_context(postgresql_t)
+selinux_compute_relabel_context(postgresql_t)
+
 term_use_controlling_term(postgresql_t)
 
 corecmd_exec_bin(postgresql_t)
@@ -126,7 +218,7 @@
 
 miscfiles_read_localization(postgresql_t)
 
-seutil_dontaudit_search_config(postgresql_t)
+seutil_libselinux_linked(postgresql_t)
 
 userdom_dontaudit_use_unpriv_user_fds(postgresql_t)
 
@@ -167,3 +259,89 @@
 optional_policy(`
 	udev_read_db(postgresql_t)
 ')
+
+########################################
+#
+# Rules common to all clients
+#
+
+allow sepgsql_client_type sepgsql_db_t:db_database { getattr access get_param set_param };
+type_transition sepgsql_client_type sepgsql_client_type:db_database sepgsql_db_t;
+
+allow sepgsql_client_type sepgsql_fixed_table_t:db_table { getattr use select insert };
+allow sepgsql_client_type sepgsql_fixed_table_t:db_column { getattr use select insert };
+allow sepgsql_client_type sepgsql_fixed_table_t:db_tuple { use select insert };
+
+allow sepgsql_client_type sepgsql_table_t:db_table { getattr use select update insert delete };
+allow sepgsql_client_type sepgsql_table_t:db_column { getattr use select update insert };
+allow sepgsql_client_type sepgsql_table_t:db_tuple { use select update insert delete };
+
+allow sepgsql_client_type sepgsql_ro_table_t:db_table { getattr use select };
+allow sepgsql_client_type sepgsql_ro_table_t:db_column { getattr use select };
+allow sepgsql_client_type sepgsql_ro_table_t:db_tuple { use select };
+
+allow sepgsql_client_type sepgsql_secret_table_t:db_table getattr;
+allow sepgsql_client_type sepgsql_secret_table_t:db_column getattr;
+
+allow sepgsql_client_type sepgsql_sysobj_t:db_table { getattr use select };
+allow sepgsql_client_type sepgsql_sysobj_t:db_column { getattr use select };
+allow sepgsql_client_type sepgsql_sysobj_t:db_tuple { use select };
+
+allow sepgsql_client_type sepgsql_proc_t:db_procedure { getattr execute };
+allow sepgsql_client_type sepgsql_trusted_proc_t:db_procedure { getattr execute entrypoint };
+
+allow sepgsql_client_type sepgsql_blob_t:db_blob { create drop getattr setattr read write };
+allow sepgsql_client_type sepgsql_ro_blob_t:db_blob { getattr read };
+allow sepgsql_client_type sepgsql_secret_blob_t:db_blob getattr;
+
+tunable_policy(`sepgsql_enable_users_ddl',`
+	allow sepgsql_client_type sepgsql_table_t:db_table  { create drop setattr };
+	allow sepgsql_client_type sepgsql_table_t:db_column { create drop setattr };
+	allow sepgsql_client_type sepgsql_sysobj_t:db_tuple  { update insert delete };
+')
+
+########################################
+#
+# Unconfined access to this module
+#
+allow sepgsql_unconfined_type sepgsql_database_type:db_database *;
+type_transition sepgsql_unconfined_type sepgsql_unconfined_type:db_database sepgsql_db_t;
+
+type_transition sepgsql_unconfined_type sepgsql_database_type:db_table sepgsql_table_t;
+type_transition sepgsql_unconfined_type sepgsql_database_type:db_procedure sepgsql_proc_t;
+type_transition sepgsql_unconfined_type sepgsql_database_type:db_blob sepgsql_blob_t;
+
+allow sepgsql_unconfined_type sepgsql_table_type:{ db_table db_column db_tuple } *;
+
+# unconfined domain is not allowed to invoke user defined procedure directly.
+# They have to confirm and relabel it at first.
+allow sepgsql_unconfined_type { sepgsql_proc_t sepgsql_trusted_proc_t }:db_procedure *;
+allow sepgsql_unconfined_type sepgsql_procedure_type:db_procedure { create drop getattr setattr relabelfrom relabelto };
+
+allow sepgsql_unconfined_type sepgsql_blob_type:db_blob *;
+
+allow sepgsql_unconfined_type sepgsql_module_type:db_database install_module;
+
+optional_policy(`
+	kernel_relabelfrom_unlabeled_database(sepgsql_unconfined_type)
+')
+
+########################################
+#
+# Dontaudit deny logs in row-level access control
+#
+
+# 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.
+
+dontaudit { postgresql_t sepgsql_client_type sepgsql_unconfined_type } { sepgsql_table_type - sepgsql_sysobj_table_type } : db_tuple { use select update insert delete };
Index: refpolicy/policy/modules/services/postgresql.fc
===================================================================
--- refpolicy/policy/modules/services/postgresql.fc	(revision 2710)
+++ refpolicy/policy/modules/services/postgresql.fc	(working copy)
@@ -6,8 +6,8 @@
 #
 # /usr
 #
-/usr/bin/initdb			--	gen_context(system_u:object_r:postgresql_exec_t,s0)
-/usr/bin/postgres		--	gen_context(system_u:object_r:postgresql_exec_t,s0)
+/usr/bin/initdb(\.sepgsql)?	--	gen_context(system_u:object_r:postgresql_exec_t,s0)
+/usr/bin/(se)?postgres		--	gen_context(system_u:object_r:postgresql_exec_t,s0)
 
 /usr/lib/pgsql/test/regres(/.*)?	gen_context(system_u:object_r:postgresql_db_t,s0)
 /usr/lib/pgsql/test/regress/pg_regress -- gen_context(system_u:object_r:postgresql_exec_t,s0)
@@ -30,8 +30,12 @@
 /var/lib/pgsql/data(/.*)?		gen_context(system_u:object_r:postgresql_db_t,s0)
 /var/lib/pgsql/pgstartup\.log		gen_context(system_u:object_r:postgresql_log_t,s0)
 
+/var/lib/sepgsql(/.*)?			gen_context(system_u:object_r:postgresql_db_t,s0)
+/var/lib/sepgsql/pgstartup\.log	--	gen_context(system_u:object_r:postgresql_log_t,s0)
+
 /var/log/postgres\.log.* 	--	gen_context(system_u:object_r:postgresql_log_t,s0)
 /var/log/postgresql(/.*)?		gen_context(system_u:object_r:postgresql_log_t,s0)
+/var/log/sepostgresql\.log.*	--	gen_context(system_u:object_r:postgresql_log_t,s0)
 
 ifdef(`distro_redhat', `
 /var/log/rhdb/rhdb(/.*)?		gen_context(system_u:object_r:postgresql_log_t,s0)
Index: refpolicy/policy/modules/system/userdomain.if
===================================================================
--- refpolicy/policy/modules/system/userdomain.if	(revision 2710)
+++ refpolicy/policy/modules/system/userdomain.if	(working copy)
@@ -1197,6 +1197,10 @@
 		netutils_run_traceroute_cond($1_t,$1_r,{ $1_tty_device_t $1_devpts_t })
 	')
 
+	optional_policy(`
+		postgresql_userdom_template($1,$1_t,$1_r)
+	')
+
 	# Run pppd in pppd_t by default for user
 	optional_policy(`
 		ppp_run_cond($1_t,$1_r,{ $1_tty_device_t $1_devpts_t })
@@ -1367,6 +1371,10 @@
 	')
 
 	optional_policy(`
+		postgresql_unconfined($1_t)
+	')
+
+	optional_policy(`
 		userhelper_exec($1_t)
 	')
 ')
Index: refpolicy/policy/modules/system/libraries.te
===================================================================
--- refpolicy/policy/modules/system/libraries.te	(revision 2710)
+++ refpolicy/policy/modules/system/libraries.te	(working copy)
@@ -109,3 +109,8 @@
 	# blow up.
 	rpm_manage_script_tmp_files(ldconfig_t)
 ')
+
+optional_policy(`
+	postgresql_loadable_module(lib_t)
+	postgresql_loadable_module(textrel_shlib_t)
+')
Index: refpolicy/policy/modules/system/unconfined.if
===================================================================
--- refpolicy/policy/modules/system/unconfined.if	(revision 2710)
+++ refpolicy/policy/modules/system/unconfined.if	(working copy)
@@ -88,6 +88,10 @@
 	')
 
 	optional_policy(`
+		postgresql_unconfined($1)
+	')
+
+	optional_policy(`
 		seutil_create_bin_policy($1)
 		seutil_relabelto_bin_policy($1)
 	')
Index: refpolicy/policy/modules/system/init.fc
===================================================================
--- refpolicy/policy/modules/system/init.fc	(revision 2710)
+++ refpolicy/policy/modules/system/init.fc	(working copy)
@@ -38,6 +38,8 @@
 #
 # /usr
 #
+/usr/bin/sepg_ctl	--	gen_context(system_u:object_r:initrc_exec_t,s0)
+
 /usr/libexec/dcc/start-.* --	gen_context(system_u:object_r:initrc_exec_t,s0)
 /usr/libexec/dcc/stop-.* --	gen_context(system_u:object_r:initrc_exec_t,s0)
 

Re: [PATCH] libselinux: add support for /contexts/postgresql_contexts

[Christopher J. PeBenito]

On Mon, 2008-06-09 at 12:07 +0900, KaiGai Kohei wrote:
> 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?

-- 
Chris PeBenito
Tresys Technology, LLC
(410) 290-1411 x150


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: [PATCH] libselinux: add support for /contexts/postgresql_contexts

[KaiGai Kohei]

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

Christopher J. PeBenito wrote:
> 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.

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.

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

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

[-- Attachment #2: sepgsql-policy-fixes.patch --]
[-- Type: text/x-patch, Size: 2386 bytes --]

Index: refpolicy/policy/modules/services/postgresql.if
===================================================================
--- refpolicy/policy/modules/services/postgresql.if	(revision 2714)
+++ refpolicy/policy/modules/services/postgresql.if	(working copy)
@@ -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;
 	')
 
 	########################################
@@ -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;
 
 	##############################
 	#
@@ -87,8 +87,8 @@
 	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;
 
-	allow $2 sepgsql_trusted_domain_t:process transition;
-	type_transition $2 sepgsql_trusted_proc_t:process sepgsql_trusted_domain_t;
+	allow $2 sepgsql_trusted_proc_t:process transition;
+	type_transition $2 sepgsql_trusted_proc_exec_t:process sepgsql_trusted_proc_t;
 ')
 
 ########################################
@@ -340,21 +340,20 @@
 		class db_blob all_db_blob_perms;
 
 		attribute sepgsql_client_type;
-		attribute sepgsql_database_type;
 
-		type sepgsql_table_t, sepgsql_proc_t, sepgsql_blob_t;
+		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;
 
-	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;
+	type_transition $1 sepgsql_db_t:db_table sepgsql_table_t;
+	type_transition $1 sepgsql_db_t:db_procedure sepgsql_proc_t;
+	type_transition $1 sepgsql_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;
 ')
 
 ########################################

Re: [PATCH] libselinux: add support for /contexts/postgresql_contexts

[Christopher J. PeBenito]

On Fri, 2008-06-13 at 19:39 +0900, KaiGai Kohei wrote:
> Christopher J. PeBenito wrote:
> > 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.
> 
> 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.

I merged this part of the patch.

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

-- 
Chris PeBenito
Tresys Technology, LLC
(410) 290-1411 x150


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: [PATCH] libselinux: add support for /contexts/postgresql_contexts

[KaiGai Kohei]

Christopher J. PeBenito wrote:
>>> 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.

And, is there any differences between user_sepgsql_proc_t and
staff_sepgsql_proc_t?
If you indend this idea enables end-users to extend their policy of
$1_sepgsql_proc_t by security module, I also think it is a good idea,
even if there is no differences in the default.

But trusted procedure works as an unconfined database domain.
There is no margin to customize except for MLS/MCS.

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

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: [PATCH] libselinux: add support for /contexts/postgresql_contexts

[Christopher J. PeBenito]

On Wed, 2008-06-18 at 15:53 +0900, KaiGai Kohei wrote:
> Christopher J. PeBenito wrote:
> >>> 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.

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

-- 
Chris PeBenito
Tresys Technology, LLC
(410) 290-1411 x150


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: [PATCH] libselinux: add support for /contexts/postgresql_contexts

[KaiGai Kohei]

Christopher J. PeBenito wrote:
> On Wed, 2008-06-18 at 15:53 +0900, KaiGai Kohei wrote:
>> Christopher J. PeBenito wrote:
>>>>> 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.
> 
> 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?

The purpose of $1_sepgsql_proc_t is to avoid unconfined domain
to invoke user defined function (may be malicious one) without
checking its safeness.

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

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: [PATCH] libselinux: add support for /contexts/postgresql_contexts

[Christopher J. PeBenito]

On Fri, 2008-06-20 at 15:48 +0900, KaiGai Kohei wrote:
> Christopher J. PeBenito wrote:
> > On Wed, 2008-06-18 at 15:53 +0900, KaiGai Kohei wrote:
> >> Christopher J. PeBenito wrote:
> >>>>> 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.
> > 
> > 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?

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.

-- 
Chris PeBenito
Tresys Technology, LLC
(410) 290-1411 x150


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: [PATCH] libselinux: add support for /contexts/postgresql_contexts

[KaiGai Kohei]

Christopher J. PeBenito wrote:
> On Fri, 2008-06-20 at 15:48 +0900, KaiGai Kohei wrote:
>> Christopher J. PeBenito wrote:
>>> On Wed, 2008-06-18 at 15:53 +0900, KaiGai Kohei wrote:
>>>> Christopher J. PeBenito wrote:
>>>>>>> 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.
>>> 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?
> 
> 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?

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

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: [PATCH] libselinux: add support for /contexts/postgresql_contexts

[Christopher J. PeBenito]

On Mon, 2008-06-23 at 21:48 +0900, KaiGai Kohei wrote:
> Christopher J. PeBenito wrote:
> > On Fri, 2008-06-20 at 15:48 +0900, KaiGai Kohei wrote:
> >> Christopher J. PeBenito wrote:
> >>> On Wed, 2008-06-18 at 15:53 +0900, KaiGai Kohei wrote:
> >>>> Christopher J. PeBenito wrote:
> >>>>>>> 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.
> >>> 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?
> > 
> > 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?

-- 
Chris PeBenito
Tresys Technology, LLC
(410) 290-1411 x150


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: [PATCH] libselinux: add support for /contexts/postgresql_contexts

[KaiGai Kohei]

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

Christopher J. PeBenito wrote:
> On Mon, 2008-06-23 at 21:48 +0900, KaiGai Kohei wrote:
>> Christopher J. PeBenito wrote:
>>> On Fri, 2008-06-20 at 15:48 +0900, KaiGai Kohei wrote:
>>>> Christopher J. PeBenito wrote:
>>>>> On Wed, 2008-06-18 at 15:53 +0900, KaiGai Kohei wrote:
>>>>>> Christopher J. PeBenito wrote:
>>>>>>>>> 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.
>>>>> 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?
>>> 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

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

[-- Attachment #2: refpolicy-sepgsql_proc_exec_t.patch --]
[-- Type: text/x-patch, Size: 3702 bytes --]

Index: refpolicy/policy/modules/services/postgresql.if
===================================================================
--- refpolicy/policy/modules/services/postgresql.if	(revision 2727)
+++ refpolicy/policy/modules/services/postgresql.if	(working copy)
@@ -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;
 	')
 
 	########################################
@@ -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;
 
-	allow $2 sepgsql_trusted_domain_t:process transition;
-	type_transition $2 sepgsql_trusted_proc_t:process sepgsql_trusted_domain_t;
+	allow $2 sepgsql_trusted_proc_t:process transition;
+	type_transition $2 sepgsql_trusted_proc_exec_t:process sepgsql_trusted_proc_t;
 ')
 
 ########################################
@@ -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;
@@ -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)
@@ -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;
 
 ########################################
 #

Re: [PATCH] libselinux: add support for /contexts/postgresql_contexts

[Christopher J. PeBenito]

On Tue, 2008-06-24 at 11:35 +0900, KaiGai Kohei wrote:
> 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


Merged.

> 
> 
> 
> 
> 
> 
> 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)
> @@ -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;
>         ')
>  
>         ########################################
> @@ -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;
>  
> -       allow $2 sepgsql_trusted_domain_t:process transition;
> -       type_transition $2 sepgsql_trusted_proc_t:process
> sepgsql_trusted_domain_t;
> +       allow $2 sepgsql_trusted_proc_t:process transition;
> +       type_transition $2 sepgsql_trusted_proc_exec_t:process
> sepgsql_trusted_proc_t;
>  ')
>  
>  ########################################
> @@ -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;
> @@ -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)
> @@ -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;
>  
>  ########################################
>  #
> 
-- 
Chris PeBenito
Tresys Technology, LLC
(410) 290-1411 x150


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: [PATCH] libselinux: add support for /contexts/postgresql_contexts

[KaiGai Kohei]

Christopher J. PeBenito wrote:
> On Tue, 2008-05-27 at 14:34 -0400, Stephen Smalley wrote:
>> On Tue, 2008-05-27 at 13:55 -0400, Christopher J. PeBenito wrote:
>>> On Tue, 2008-05-27 at 13:14 -0400, Stephen Smalley wrote:
>>>> On Mon, 2008-05-26 at 19:30 +0900, KaiGai Kohei wrote:
>>>>> 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".
>>>> 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?
>>> 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;
>> 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.

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.

I thought you concerned about using a domain of server process as
a target of type_transition because its relationship is not clear
like ones between a directory and files.

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

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, ...).
We can describe it with type_transition enough.

The matter is how to decide the root of type_transition in the world
of database. Does it come from a server process? client process itself?
configuration file? or initial context?

Thanks,

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

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

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: [PATCH] libselinux: add support for /contexts/postgresql_contexts

[Christopher J. PeBenito]

On Wed, 2008-05-28 at 10:49 +0900, KaiGai Kohei wrote:
> Christopher J. PeBenito wrote:
> > On Tue, 2008-05-27 at 14:34 -0400, Stephen Smalley wrote:
> >> On Tue, 2008-05-27 at 13:55 -0400, Christopher J. PeBenito wrote:
> >>> 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).
> > 
> > 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.

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

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

I don't agree.

-- 
Chris PeBenito
Tresys Technology, LLC
(410) 290-1411 x150



--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: [PATCH] libselinux: add support for /contexts/postgresql_contexts

[KaiGai Kohei]

Christopher J. PeBenito wrote:
> On Wed, 2008-05-28 at 10:49 +0900, KaiGai Kohei wrote:
>> Christopher J. PeBenito wrote:
>>> On Tue, 2008-05-27 at 14:34 -0400, Stephen Smalley wrote:
>>>> On Tue, 2008-05-27 at 13:55 -0400, Christopher J. PeBenito wrote:
>>>>> 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).
>>> 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.

Yes, I did not want database objects to inherit postgresql_t in the default
policy.
However, it is theoretically possible, when someone writes a policy
which allows to create database object with postgresql_t on db_database
class.
No need to say, it is so confusable context naming. So, I applied
type_transition rules to attach proper context for any database objects.

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

I don't oppose to provide the default type of db_database class object
as the root of type_transition chain, because it has no parent object.

However, I don't think these hints for rest of object classes are necessary,
because they have hierarchic relationships, like ones between directory and
files on filesystem.
I think we should pay attention the resemblance with filesystem.

>> I don't think we need default contexts for any database object managed
>> under database itself (like table, column, procedure, ...).
> 
> I don't agree.
-- 
KaiGai Kohei <kaigai@kaigai.gr.jp>

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: [PATCH] libselinux: add support for /contexts/postgresql_contexts

[KaiGai Kohei]

Stephen Smalley wrote:
> On Tue, 2008-05-27 at 13:55 -0400, Christopher J. PeBenito wrote:
>> On Tue, 2008-05-27 at 13:14 -0400, Stephen Smalley wrote:
>>> On Mon, 2008-05-26 at 19:30 +0900, KaiGai Kohei wrote:
>>>> 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".
>>> 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?
>> 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;
> 
> 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


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

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

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: [PATCH] libselinux: add support for /contexts/postgresql_contexts

[Stephen Smalley]

On Wed, 2008-05-28 at 10:13 +0900, KaiGai Kohei wrote:
> Stephen Smalley wrote:
> > On Tue, 2008-05-27 at 13:55 -0400, Christopher J. PeBenito wrote:
> >> On Tue, 2008-05-27 at 13:14 -0400, Stephen Smalley wrote:
> >>> On Mon, 2008-05-26 at 19:30 +0900, KaiGai Kohei wrote:
> >>>> 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".
> >>> 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?
> >> 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;
> > 
> > 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.

Hmm...in that case, type_transition makes sense for that 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

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

> 
> >> 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;
> 
-- 
Stephen Smalley
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: [PATCH] libselinux: add support for /contexts/postgresql_contexts

[KaiGai Kohei]

Stephen Smalley wrote:
> On Wed, 2008-05-28 at 10:13 +0900, KaiGai Kohei wrote:
>> Stephen Smalley wrote:
>>> On Tue, 2008-05-27 at 13:55 -0400, Christopher J. PeBenito wrote:
>>>> On Tue, 2008-05-27 at 13:14 -0400, Stephen Smalley wrote:
>>>>> On Mon, 2008-05-26 at 19:30 +0900, KaiGai Kohei wrote:
>>>>>> 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".
>>>>> 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?
>>>> 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;
>>> 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.
> 
> Hmm...in that case, type_transition makes sense for that 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
> 
> So is that "default" behavior fundamentally a problem?
> Do we really need these other contexts at all?

No, it is theoretically possible to share only one type for various object
classes.
(unlabeled_t can be an example for this case.)
If a policy writer want, we can label all of database object with same
security context and allows something for each object classes.

However, it is rightly confusable policy. So, I defined object classes
specific types, like sepgsql_table_t, sepgsql_proc_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;
-- 
KaiGai Kohei <kaigai@kaigai.gr.jp>

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: [PATCH] libselinux: add support for /contexts/postgresql_contexts

[KaiGai Kohei]

Stephen Smalley wrote:
>> 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.

I think it can be a good candidate to describe type_transition for
db_database class, because another subsystem (socket) adopts self
relationship approach and we can avoid unnecessary confusion.

Chris, can you change type_transition rules for db_database, as follows?

  type_transition postgresql_t self:db_database sepgsql_db_t;
  type_transition sepgsql_client_type self_t:db_database sepgsql_db_t;

In this approach, I think configuration files are not necessary basically.

However, I'm attracted to Eamon's idea.
If there is a configuration file to describe what database object should
have what context, we can also provide a restorecon for database objects.

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

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.