file_type_auto_trans is not sufficient

file_type_auto_trans is not sufficient

[Ivan Gyurdiev]

As part of my current project, I am running into a large number of cases
where file_type_auto_trans is not an acceptable solution for changing
the context for a newly created file/directory. This always
happens in a conflicting-transition scenario (very common):

For example:

1) 
libgnome needs to create .gnome2 and .gnome2_private with
a context that differs from the parent directory. Applications
that link to libgnome may already have a transition defined 
for (ROLE_home_dir_t: dir)

2)
libfontconfig needs to create .font.cache-# with
a context that differs from the parent directory. Same
problem for (ROLE_hime_dir_t: file)

3) 
Mail apps need to be able to save mail to $HOME
under some context (likely ROLE_untrusted_content_t:file/dir).
Same goes for web content saved by mozilla. This conflicts
with the usual transition.

4) 
libORBit2 needs to create /tmp/orbit-$USER... with a specific
context while the app may have its own tmp_domain. Same for libICE.

===============

To address those problems, I think I need to add selinux support
to a number of applications, and perform the transition in the code. 
I'm not sure what's the best way to do that. Does adding 
the following functions to libselinux (or elsewhere) make sense?

int mkdir_restorecon(const char *pathname, mode_t mode);
int creat_restorecon(const char *pathname, mode_t mode);
int mknod_restorecon(const char *pathname, mode_t mode, dev_t dev);

Those would perform getfscreate/matchpathcon/setfscreate cycle,
and would ignore errors in permissive mode.

-- 
Ivan Gyurdiev <ivg2@cornell.edu>
Cornell University


--
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: file_type_auto_trans is not sufficient

[Ivan Gyurdiev]

> To address those problems, I think I need to add selinux support
> to a number of applications, and perform the transition in the code. 
> I'm not sure what's the best way to do that. Does adding 
> the following functions to libselinux (or elsewhere) make sense?
> 
> int mkdir_restorecon(const char *pathname, mode_t mode);
> int creat_restorecon(const char *pathname, mode_t mode);
> int mknod_restorecon(const char *pathname, mode_t mode, dev_t dev);
> 
> Those would perform getfscreate/matchpathcon/setfscreate cycle,
> and would ignore errors in permissive mode.

Actually, what exactly happens when you call setfscreate() and
at the same time you have a matching file_type_auto_trans rule?

In my case for /tmp/gconfd-$USER vs /tmp/orbit-$USER,
(process is gconf, executing libORBit code that creates orbit-$USER)
the orbit getfscreate() rule took precedence over
the matching file_type_auto_trans in gconfd... does
this always happen, or do I have to make a choice 
between either file_type_auto_trans, or setfscreate() ?

-- 
Ivan Gyurdiev <ivg2@cornell.edu>
Cornell University


--
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: file_type_auto_trans is not sufficient

[Daniel J Walsh]

Ivan Gyurdiev wrote:

>>To address those problems, I think I need to add selinux support
>>to a number of applications, and perform the transition in the code. 
>>I'm not sure what's the best way to do that. Does adding 
>>the following functions to libselinux (or elsewhere) make sense?
>>
>>int mkdir_restorecon(const char *pathname, mode_t mode);
>>int creat_restorecon(const char *pathname, mode_t mode);
>>int mknod_restorecon(const char *pathname, mode_t mode, dev_t dev);
>>
>>Those would perform getfscreate/matchpathcon/setfscreate cycle,
>>and would ignore errors in permissive mode.
>>    
>>
>
>Actually, what exactly happens when you call setfscreate() and
>at the same time you have a matching file_type_auto_trans rule?
>
>In my case for /tmp/gconfd-$USER vs /tmp/orbit-$USER,
>(process is gconf, executing libORBit code that creates orbit-$USER)
>the orbit getfscreate() rule took precedence over
>the matching file_type_auto_trans in gconfd... does
>this always happen, or do I have to make a choice 
>between either file_type_auto_trans, or setfscreate() ?
>
>  
>
setfscreatecon takes precedence.

-- 



--
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: file_type_auto_trans is not sufficient

[Ivan Gyurdiev]

> setfscreatecon takes precedence.

...on second thought this interface doesn't work at all - 
apps call higher level functions for portability - the C
standard functions (fopen...), glib (g_mkdir).

Maybe just add:

/* Performs a context match, and changes the file creation context.
 * On success, returns the old context. On failure, returns NULL.
 * The context returned must be freed with freecon() */

security_context_t switch_context(const char* pathname, mode_t mode) {
        security_context_t prev_ctx = NULL;
        security_context_t tmp_ctx = NULL;

        /* Attempt to get the current context. */
        if (getfscreatecon(&prev_ctx) < 0)
                return NULL;

        /* Attempt a match. */
        if (matchpathcon(pathname, mode, &tmp_ctx) >= 0) {
                if (setfscreatecon(tmp_ctx) < 0) {
                        freecon(tmp_ctx);
                        freecon(prev_ctx);
                        return NULL;
                }
                freecon(tmp_ctx);
        }

        return prev_ctx;
}

...and then do this in every app that needs it, replacing
mkdir with the appropriate function. This is annoying.... 
but I can't think how else to write a better interface.

/* Performs a mkdir call, and sets the context of the directory
 * being created, according to matchpathcon. On SElinux failure
 * returns -1. Otherwise, returns the usual mkdir status. */

int mkdir_restorecon(const char *pathname, mode_t mode) {
        security_context_t prev_ctx = NULL;
        int status;

        if (is_selinux_enabled()) {
                prev_ctx = switch_context(pathname, mode);

                if ((prev_ctx != NULL) && security_getenforce())
                        return -1;
        }

        status = mkdir(pathname, mode);

        if (prev_ctx != NULL) {
                setfscreatecon(prev_ctx);
                freecon(prev_ctx);
        }

        return status;
}

-- 
Ivan Gyurdiev <ivg2@cornell.edu>
Cornell University


--
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: file_type_auto_trans is not sufficient

[Daniel J Walsh]

Ivan Gyurdiev wrote:

>>setfscreatecon takes precedence.
>>    
>>
>
>...on second thought this interface doesn't work at all - 
>apps call higher level functions for portability - the C
>standard functions (fopen...), glib (g_mkdir).
>
>Maybe just add:
>
>/* Performs a context match, and changes the file creation context.
> * On success, returns the old context. On failure, returns NULL.
> * The context returned must be freed with freecon() */
>
>security_context_t switch_context(const char* pathname, mode_t mode) {
>        security_context_t prev_ctx = NULL;
>        security_context_t tmp_ctx = NULL;
>
>        /* Attempt to get the current context. */
>        if (getfscreatecon(&prev_ctx) < 0)
>                return NULL;
>
>        /* Attempt a match. */
>        if (matchpathcon(pathname, mode, &tmp_ctx) >= 0) {
>                if (setfscreatecon(tmp_ctx) < 0) {
>                        freecon(tmp_ctx);
>                        freecon(prev_ctx);
>                        return NULL;
>                }
>                freecon(tmp_ctx);
>        }
>
>        return prev_ctx;
>}
>
>...and then do this in every app that needs it, replacing
>mkdir with the appropriate function. This is annoying.... 
>but I can't think how else to write a better interface.
>
>/* Performs a mkdir call, and sets the context of the directory
> * being created, according to matchpathcon. On SElinux failure
> * returns -1. Otherwise, returns the usual mkdir status. */
>
>int mkdir_restorecon(const char *pathname, mode_t mode) {
>        security_context_t prev_ctx = NULL;
>        int status;
>
>        if (is_selinux_enabled()) {
>                prev_ctx = switch_context(pathname, mode);
>
>                if ((prev_ctx != NULL) && security_getenforce())
>                        return -1;
>        }
>
>        status = mkdir(pathname, mode);
>
>        if (prev_ctx != NULL) {
>                setfscreatecon(prev_ctx);
>                freecon(prev_ctx);
>        }
>
>        return status;
>}
>
>  
>
You do not necessarily want to return an error or matchpathcon failure.  
matchpathcon can return ENOENT to indicate that it matched <<none>>

In this case the setfscreatecon should not be called but the code should 
continue.  IE the
file should get created with the default context.

-- 



--
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: file_type_auto_trans is not sufficient

[Ivan Gyurdiev]

> >/* Performs a context match, and changes the file creation context.
> > * On success, returns the old context. On failure, returns NULL.
> > * The context returned must be freed with freecon() */
> >
> >security_context_t switch_context(const char* pathname, mode_t mode) {
> >        security_context_t prev_ctx = NULL;
> >        security_context_t tmp_ctx = NULL;
> >
> >        /* Attempt to get the current context. */
> >        if (getfscreatecon(&prev_ctx) < 0)
> >                return NULL;
> >
> >        /* Attempt a match. */
> >        if (matchpathcon(pathname, mode, &tmp_ctx) >= 0) {
> >                if (setfscreatecon(tmp_ctx) < 0) {
> >                        freecon(tmp_ctx);
> >                        freecon(prev_ctx);
> >                        return NULL;
> >                }
> >                freecon(tmp_ctx);
> >        }
> >
> >        return prev_ctx;
> >}
> >
> >...and then do this in every app that needs it, replacing
> >mkdir with the appropriate function. This is annoying.... 
> >but I can't think how else to write a better interface.
> >
> >/* Performs a mkdir call, and sets the context of the directory
> > * being created, according to matchpathcon. On SElinux failure
> > * returns -1. Otherwise, returns the usual mkdir status. */
> >
> >int mkdir_restorecon(const char *pathname, mode_t mode) {
> >        security_context_t prev_ctx = NULL;
> >        int status;
> >
> >        if (is_selinux_enabled()) {
> >                prev_ctx = switch_context(pathname, mode);
> >
> >                if ((prev_ctx != NULL) && security_getenforce())
> >                        return -1;
> >        }
> >
> >        status = mkdir(pathname, mode);
> >
> >        if (prev_ctx != NULL) {
> >                setfscreatecon(prev_ctx);
> >                freecon(prev_ctx);
> >        }
> >
> >        return status;
> >}
> >
> >  
> >
> You do not necessarily want to return an error or matchpathcon failure.  
> matchpathcon can return ENOENT to indicate that it matched <<none>>

>                if ((prev_ctx != NULL) && security_getenforce())

This should be if ((prev_ctx == NULL) ... 
Given that, there is no error on matchpathcon failure.

> In this case the setfscreatecon should not be called but the code should 
> continue.  IE the
> file should get created with the default context.

That's what it does... it also tries to setfscreatecon back to 
restore the old context on no change, but I thought that was acceptable.

The issue is - this interface is rather ugly - can anyone come up 
with a better one, or should I go ahead and patch various programs like
this. 

-- 
Ivan Gyurdiev <ivg2@cornell.edu>
Cornell University


--
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: file_type_auto_trans is not sufficient

[Ivan Gyurdiev]

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


> The issue is - this interface is rather ugly - can anyone come up 
> with a better one, or should I go ahead and patch various programs like
> this. 

Sample patches attached. I also have to patch libICE. Fonts patch
works fine, but I can't get gnome/ORBit to compile because of docbook
problems. Any domain calling orbit_connect, ice_connect, read_fonts, 
or gnome_application (see my other mail - PATCH) 
executes the following macro:

################################################################
#
# can_restore_context(domain)
#
# Permissions for restoring the context
# of a file via setfscreatecon/getfscreatecon/matchpathcon
#

define(`can_restore_context', `

# Protect against double inclusion
ifdef(`can_restore_context_$1', `', `
define(`can_restore_context_$1')

can_setfscreate($1)
can_getsecurity($1)
r_dir_file($1, selinux_config_t)
r_dir_file($1, file_context_t)
allow $1 default_context_t:dir search;

') dnl ifdef can_restore_context_args
') dnl can_restore_context

It also makes virtually everything depend on libselinux.

I'm really starting to think that this is too ugly, and not an
acceptable solution, but I don't have another suggestion at this time.

-- 
Ivan Gyurdiev <ivg2@cornell.edu>
Cornell University

[-- Attachment #2: fontconfig-2.2.3-selinux_restore.patch --]
[-- Type: text/x-patch, Size: 2900 bytes --]

diff -aur fontconfig-2.2.3.orig/configure.in fontconfig-2.2.3/configure.in
--- fontconfig-2.2.3.orig/configure.in	2004-06-30 14:53:39.000000000 -0400
+++ fontconfig-2.2.3/configure.in	2005-05-29 20:59:49.000000000 -0400
@@ -132,6 +132,17 @@
 CFLAGS="$fontconfig_save_cflags"
 LIBS="$fontconfig_save_libs"
 
+dnl Checks for SELinux
+AC_CHECK_LIB(selinux, security_switch_context, have_switch_context=yes)
+AC_CHECK_HEADER(selinux/selinux.h, have_selinux_h=yes)
+if test "x$have_switch_context" = "xyes" && test "x$have_selinux_h" = "xyes"; then
+  AC_DEFINE([WITH_SELINUX], 1, [define to enable SELinux support])
+  SELINUX_CFLAGS="-I/usr/include/selinux"
+  SELINUX_LDFLAGS="-lselinux"
+fi
+AC_SUBST(SELINUX_LDFLAGS)
+AC_SUBST(SELINUX_CFLAGS)
+
 #
 # Check expat configuration
 #
diff -aur fontconfig-2.2.3.orig/src/fccache.c fontconfig-2.2.3/src/fccache.c
--- fontconfig-2.2.3.orig/src/fccache.c	2005-05-28 21:56:57.000000000 -0400
+++ fontconfig-2.2.3/src/fccache.c	2005-05-29 21:27:36.000000000 -0400
@@ -23,6 +23,9 @@
  */
 
 #include "fcint.h"
+#ifdef WITH_SELINUX
+#include <selinux/selinux.h>
+#endif
 
 /*
  * POSIX has broken stdio so that getc must do thread-safe locking,
@@ -855,6 +858,10 @@
     FcGlobalCacheFile	*file;
     FcAtomic		*atomic;
 
+#ifdef WITH_SELINUX
+    security_context_t prev_ctx = NULL;
+#endif
+
     if (!cache->updated && cache->referenced == cache->entries)
 	return FcTrue;
     
@@ -866,16 +873,33 @@
     if (getuid () != geteuid ())
 	return FcFalse;
 #endif
-    
+
+#ifdef WITH_SELINUX
+    if (is_selinux_enabled()) {
+        prev_ctx = security_switch_context((char*) cache_file, 0200);
+
+            if ((prev_ctx == NULL) && security_getenforce()) 
+                 goto bail0;
+    }
+#endif
+
     atomic = FcAtomicCreate (cache_file);
     if (!atomic)
 	goto bail0;
     if (!FcAtomicLock (atomic))
 	goto bail1;
+
     f = fopen ((char *) FcAtomicNewFile(atomic), "w");
     if (!f)
 	goto bail2;
 
+#ifdef WITH_SELINUX
+    if (prev_ctx != NULL) {
+        setfscreatecon(prev_ctx);
+        freecon(prev_ctx);
+    }
+#endif
+
     for (dir_hash = 0; dir_hash < FC_GLOBAL_CACHE_DIR_HASH_SIZE; dir_hash++)
     {
 	for (dir = cache->ents[dir_hash]; dir; dir = dir->next)
diff -aur fontconfig-2.2.3.orig/src/Makefile.am fontconfig-2.2.3/src/Makefile.am
--- fontconfig-2.2.3.orig/src/Makefile.am	2004-03-30 12:28:44.000000000 -0500
+++ fontconfig-2.2.3/src/Makefile.am	2005-05-29 20:40:37.000000000 -0400
@@ -44,6 +44,7 @@
 INCLUDES = 						\
 	$(FREETYPE_CFLAGS)				\
 	$(EXPAT_CFLAGS)					\
+	$(SELINUX_CFLAGS)				\	
 	-DFONTCONFIG_PATH='"$(CONFDIR)"'		\
 	-I$(top_srcdir)					\
 	-I$(top_srcdir)/src
@@ -76,6 +77,7 @@
 lib_LTLIBRARIES = libfontconfig.la
 
 libfontconfig_la_LDFLAGS =			\
+	$(SELINUX_LDFLAGS)			\
 	-version-info @LT_VERSION_INFO@ $(no_undefined) $(export_symbols)
 
 libfontconfig_la_LIBADD = $(FREETYPE_LIBS) $(EXPAT_LIBS)

[-- Attachment #3: fontconfig.spec.diff --]
[-- Type: text/x-patch, Size: 904 bytes --]

--- fontconfig.spec.orig	2005-05-28 22:23:28.000000000 -0400
+++ fontconfig.spec	2005-05-29 20:44:19.000000000 -0400
@@ -41,10 +41,13 @@
 # https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=148748
 Patch30: fontconfig-2.2.3-add-sazanami.patch
 
+# Restore SELinux context of the global font cache
+Patch31: fontconfig-2.2.3-selinux_restore.patch
+
 BuildRequires: freetype-devel >= %{freetype_version}
 BuildRequires: expat-devel
 BuildRequires: perl
-# For nodocs patch
+BuildRequires: /usr/bin/autoconf
 BuildRequires: /usr/bin/automake-1.7
 
 PreReq: freetype >= %{freetype_version}
@@ -86,15 +89,16 @@
 
 %patch30 -p1 -b .sazanami
 
+%patch31 -p1 -b .selinux_restore
+
 %if %{disable_docs}
 %patch14 -p1 -b .nodocs
 %endif
 
 %build
-
-%if %{disable_docs}
+autoconf
 automake-1.7
-%endif
+autoheader
 
 %configure --with-add-fonts=/usr/X11R6/lib/X11/fonts/Type1,/usr/X11R6/lib/X11/fonts/OTF
 make

[-- Attachment #4: libgnome-2.10.0-selinux_restore.patch --]
[-- Type: text/x-patch, Size: 2758 bytes --]

diff -aur libgnome-2.10.0.orig/configure.in libgnome-2.10.0/configure.in
--- libgnome-2.10.0.orig/configure.in	2005-03-07 04:53:04.000000000 -0500
+++ libgnome-2.10.0/configure.in	2005-05-29 20:59:02.000000000 -0400
@@ -94,6 +94,17 @@
 
 GNOME_COMPILE_WARNINGS
 
+dnl Checks for SELinux
+AC_CHECK_LIB(selinux, security_switch_context, have_switch_context=yes)
+AC_CHECK_HEADER(selinux/selinux.h, have_selinux_h=yes)
+if test "x$have_switch_context" = "xyes" && test "x$have_selinux_h" = "xyes"; then
+  AC_DEFINE([WITH_SELINUX], 1, [define to enable SELinux support])
+  SELINUX_CFLAGS="-I/usr/include/selinux"
+  SELINUX_LDFLAGS="-lselinux"
+fi
+AC_SUBST(SELINUX_LDFLAGS)
+AC_SUBST(SELINUX_CFLAGS)
+
 dnl Define GNOME_ENABLE_DEBUG if the --enable-debug switch was given.
 GNOME_DEBUG_CHECK
 
diff -aur libgnome-2.10.0.orig/libgnome/gnome-init.c libgnome-2.10.0/libgnome/gnome-init.c
--- libgnome-2.10.0.orig/libgnome/gnome-init.c	2005-05-28 20:28:38.000000000 -0400
+++ libgnome-2.10.0/libgnome/gnome-init.c	2005-05-29 19:37:30.000000000 -0400
@@ -53,6 +53,10 @@
 
 #include <libgnomevfs/gnome-vfs-init.h>
 
+#ifdef WITH_SELINUX
+#include <selinux/selinux.h>
+#endif
+
 /*****************************************************************************
  * bonobo
  *****************************************************************************/
@@ -266,6 +270,9 @@
 {
 	char *safe_pathname;
 	int len, ret;
+#ifdef WITH_SELINUX
+	security_context_t prev_ctx = NULL;
+#endif
 	
 	safe_pathname = g_strdup (pathname);
 	len = strlen (safe_pathname);
@@ -273,8 +280,25 @@
 	if (len > 1 && safe_pathname[len - 1] == '/')
 		safe_pathname[len - 1] = '\0';
 
+#ifdef WITH_SELINUX
+	if (is_selinux_enabled()) {
+		prev_ctx = security_switch_context(pathname, mode);
+
+		if ((prev_ctx == NULL) && security_getenforce()) {
+			ret = -1;	
+			goto exit;
+		}
+        }
+#endif
 	ret = mkdir (safe_pathname, mode);
 
+	exit:
+#ifdef WITH_SELINUX
+	if (prev_ctx != NULL) {
+		setfscreatecon(prev_ctx);
+		freecon(prev_ctx);
+	}
+#endif
 	g_free (safe_pathname);
 
 	return ret;
diff -aur libgnome-2.10.0.orig/libgnome/Makefile.am libgnome-2.10.0/libgnome/Makefile.am
--- libgnome-2.10.0.orig/libgnome/Makefile.am	2004-05-07 07:28:31.000000000 -0400
+++ libgnome-2.10.0/libgnome/Makefile.am	2005-05-28 20:40:04.000000000 -0400
@@ -17,6 +17,7 @@
 	-I$(srcdir)/..						\
 	$(WARN_CFLAGS)						\
 	$(LIBGNOME_CFLAGS)					\
+	$(SELINUX_CFLAGS)					\
 	-DG_DISABLE_DEPRECATED					\
 	-DLIBGNOME_PREFIX=\""$(prefix)"\"			\
 	-DLIBGNOME_LIBDIR=\""$(libdir)"\"			\
@@ -129,6 +130,7 @@
 	parse-path.cP
 
 libgnome_2_la_LDFLAGS = \
+	$(SELINUX_LDFLAGS)	\
 	-version-info $(LIBGNOME_CURRENT):$(LIBGNOME_REVISION):$(LIBGNOME_AGE) \
 	-no-undefined \
 	-export-symbols-regex "^[^_].*"

[-- Attachment #5: libgnome.spec.diff --]
[-- Type: text/x-patch, Size: 1161 bytes --]

--- libgnome.spec.orig	2005-05-28 21:29:48.000000000 -0400
+++ libgnome.spec	2005-05-28 22:25:21.000000000 -0400
@@ -6,6 +6,7 @@
 %define gnome_vfs2_version 2.5.3
 %define orbit2_version 2.5.1
 %define esound_version 0.2.27
+%define automake17_version 1.7.9
 
 %define po_package libgnome-2.0
 
@@ -41,6 +42,8 @@
 BuildRequires:  libxslt-devel >= %{libxslt_version}
 BuildRequires:  intltool
 BuildRequires: gtk-doc
+BuildRequires: autoconf
+BuildRequires: automake17 >= %{automake17_version}
 
 Patch0: libgnome-2.7.2-default-gtk-theme.patch
 Patch1: libgnome-2.7.2-default-background.patch
@@ -50,6 +53,7 @@
 Patch5: libgnome-2.8.0-default-browser.patch
 Patch6: libgnome-2.8.0-stat-homedir.patch
 Patch7: libgnome-2.9.1-popt.patch
+Patch8: libgnome-2.10.0-selinux_restore.patch
 
 # Added to avoid the warning messages about utmp group, bug #24171
 # fixme, just libzvt?
@@ -103,8 +107,12 @@
 %patch5 -p1 -b .default-browser
 %patch6 -p1 -b .stat-homedir
 %patch7 -p1 -b .popt
+%patch8 -p1 -b .selinux_restore
 
 %build
+autoconf
+automake-1.7
+autoheader
 intltoolize -f
 %configure --enable-gtk-doc
 # Having strange problems adding it to CFLAGS. Oh well.

[-- Attachment #6: libselinux-context_restore.patch --]
[-- Type: text/x-patch, Size: 1643 bytes --]

diff -Naur libselinux-1.23.10.orig/include/selinux/selinux.h libselinux-1.23.10/include/selinux/selinux.h
--- libselinux-1.23.10.orig/include/selinux/selinux.h	2005-04-29 14:07:14.000000000 -0400
+++ libselinux-1.23.10/include/selinux/selinux.h	2005-05-29 19:27:22.000000000 -0400
@@ -307,6 +307,13 @@
    be relabeled . */
 extern int is_context_customizable (security_context_t scontext);
 
+
+/* Performs a context match (matchpathcon), and changes the file creation  
+ * context. On success, returns the old context. On failure, returns NULL.
+ * The context returned must be freed with freecon() */
+
+extern security_context_t security_switch_context(const char *pathname, mode_t mode);
+
 #ifdef __cplusplus
 }
 #endif
diff -Naur libselinux-1.23.10.orig/src/switch_context.c libselinux-1.23.10/src/switch_context.c
--- libselinux-1.23.10.orig/src/switch_context.c	1969-12-31 19:00:00.000000000 -0500
+++ libselinux-1.23.10/src/switch_context.c	2005-05-29 19:28:35.000000000 -0400
@@ -0,0 +1,27 @@
+#include <stdlib.h>
+#include <sys/types.h>
+#include <selinux/selinux.h>
+
+security_context_t security_switch_context(const char* pathname, mode_t mode) {
+	security_context_t prev_ctx = NULL;
+	security_context_t tmp_ctx = NULL;
+
+	/* Attempt to get the current context. */
+	if (getfscreatecon(&prev_ctx) < 0)
+		return NULL;
+
+	/* Attempt a match. */
+	if (matchpathcon(pathname, mode, &tmp_ctx) >= 0) {
+
+		/* Successful match - switch context */
+		if (setfscreatecon(tmp_ctx) < 0) {
+			freecon(tmp_ctx);
+			freecon(prev_ctx);
+			return NULL;
+		}
+		freecon(tmp_ctx);
+	}
+
+	/* Return old context */
+	return prev_ctx;
+}

[-- Attachment #7: libselinux.spec.diff --]
[-- Type: text/x-patch, Size: 497 bytes --]

--- libselinux.spec.orig	2005-05-28 22:23:37.000000000 -0400
+++ libselinux.spec	2005-05-28 22:26:32.000000000 -0400
@@ -6,6 +6,7 @@
 Group: System Environment/Libraries
 Source: http://www.nsa.gov/selinux/archives/%{name}-%{version}.tgz
 Patch: libselinux-rhat.patch
+Patch1: libselinux-context_restore.patch
 
 BuildRoot: %{_tmppath}/%{name}-%{version}-buildroot
 
@@ -36,6 +37,7 @@
 %prep
 %setup -q
 %patch -p1 -b .rhat
+%patch1 -p1 -b .context_restore
 
 %build
 make CFLAGS="-g %{optflags}"

[-- Attachment #8: ORBit2-2.12.1-selinux_restore.patch --]
[-- Type: text/x-patch, Size: 3119 bytes --]

diff -aur ORBit2-2.12.1.orig/configure.in ORBit2-2.12.1/configure.in
--- ORBit2-2.12.1.orig/configure.in	2005-02-04 17:34:45.000000000 -0500
+++ ORBit2-2.12.1/configure.in	2005-05-29 20:59:20.000000000 -0400
@@ -128,6 +128,17 @@
 AC_SUBST(LOCAL_LINC_LIBS)
 AC_SUBST(LOCAL_LINC_CFLAGS)
 
+dnl Checks for SELinux
+AC_CHECK_LIB(selinux, security_switch_context, have_switch_context=yes)
+AC_CHECK_HEADER(selinux/selinux.h, have_selinux_h=yes)
+if test "x$have_switch_context" = "xyes" && test "x$have_selinux_h" = "xyes"; then
+  AC_DEFINE([WITH_SELINUX], 1, [define to enable SELinux support])
+  SELINUX_CFLAGS="-I/usr/include/selinux"
+  SELINUX_LDFLAGS="-lselinux"
+fi
+AC_SUBST(SELINUX_LDFLAGS)
+AC_SUBST(SELINUX_CFLAGS)
+
 dnl Checks for libraries.
 PKG_CHECK_MODULES(ORBIT, \
 	glib-2.0 >= $GLIB_REQUIRED \
diff -aur ORBit2-2.12.1.orig/src/orb/GIOP/giop.c ORBit2-2.12.1/src/orb/GIOP/giop.c
--- ORBit2-2.12.1.orig/src/orb/GIOP/giop.c	2005-02-01 15:48:58.000000000 -0500
+++ ORBit2-2.12.1/src/orb/GIOP/giop.c	2005-05-29 21:29:37.000000000 -0400
@@ -26,6 +26,10 @@
 #define mkdir(path, mode) _mkdir (path)
 #endif
 
+#ifdef WITH_SELINUX
+#include <selinux/selinux.h>
+#endif
+
 /* FIXME: need to clean this up at shutdown */
 static int      corba_wakeup_fds[2];
 #define WAKEUP_POLL  corba_wakeup_fds [0]
@@ -120,6 +124,37 @@
 	return cur_dir;
 }
 
+/* Performs a standard mkdir call, but restores
+ * the context of the directory being created from
+ * via matchpathcon */
+
+static int
+mkdir_restorecon(const char* pathname, mode_t mode) {
+	int status;
+
+#ifdef WITH_SELINUX
+	security_context_t prev_ctx = NULL;
+
+	if (is_selinux_enabled()) {
+		prev_ctx = security_switch_context(pathname, mode);
+
+		if ((prev_ctx == NULL) && security_getenforce()) 
+			return -1;
+	}
+#endif
+
+	status = mkdir(pathname, mode);
+
+#ifdef WITH_SELINUX
+	if (prev_ctx != NULL) {
+		setfscreatecon(prev_ctx);
+		freecon(prev_ctx);
+	}
+#endif
+	return status;
+}
+
+
 static void
 giop_tmpdir_init (void)
 {
@@ -161,7 +196,7 @@
 				"%s/%s-%4x", tmp_root, dirname, id.b);
 		}
 
-		if (mkdir (newname, 0700) < 0) {
+		if (mkdir_restorecon(newname, 0700) < 0) {
 			switch (errno) {
 			case EACCES:
 				g_error ("I can't write to '%s', ORB init failed",
diff -aur ORBit2-2.12.1.orig/src/orb/GIOP/Makefile.am ORBit2-2.12.1/src/orb/GIOP/Makefile.am
--- ORBit2-2.12.1.orig/src/orb/GIOP/Makefile.am	2003-05-30 11:55:00.000000000 -0400
+++ ORBit2-2.12.1/src/orb/GIOP/Makefile.am	2005-05-29 19:20:17.000000000 -0400
@@ -6,7 +6,8 @@
 	$(ORBIT_DEBUG_CFLAGS)		\
 	$(DISABLE_DEPRECATED_CFLAGS)	\
 	$(LOCAL_LINC_CFLAGS)		\
-	$(ORBIT_CFLAGS)
+	$(ORBIT_CFLAGS)			\
+	$(SELINUX_CFLAGS)
 
 noinst_LTLIBRARIES=libGIOP.la
 
diff -aur ORBit2-2.12.1.orig/src/orb/Makefile.am ORBit2-2.12.1/src/orb/Makefile.am
--- ORBit2-2.12.1.orig/src/orb/Makefile.am	2003-06-06 11:49:52.000000000 -0400
+++ ORBit2-2.12.1/src/orb/Makefile.am	2005-05-29 19:20:05.000000000 -0400
@@ -20,6 +20,7 @@
 	-version-info $(LT_VERSION)   \
 	-no-undefined		      \
 	$(ORBIT_LIBS)                 \
+	$(SELINUX_LDFLAGS)            \
 	-lpopt
 
 libORBit_2_la_LIBADD= \

[-- Attachment #9: ORBit2.spec.diff --]
[-- Type: text/x-patch, Size: 687 bytes --]

--- ORBit2.spec.orig	2005-05-28 22:23:22.000000000 -0400
+++ ORBit2.spec	2005-05-29 20:51:49.000000000 -0400
@@ -14,8 +14,11 @@
 BuildRequires: glib2-devel >= %{glib2_version}
 BuildRequires: pkgconfig >= 0.14
 BuildRequires: gtk-doc >= 1.1
+BuildRequires: autoconf
+BuildRequires: automake17 >= 1.7.9
 
 Patch0: ORBit2-2.12.1-reduce-size-of-io-thread-stack.patch
+Patch1: ORBit2-2.12.1-selinux_restore.patch
 
 %description
 ORBit is a high-performance CORBA (Common Object Request Broker 
@@ -52,8 +55,12 @@
 %setup -q
 
 %patch0 -p1 -b .reduce-size-of-io-thread-stack
+%patch1 -p1 -b .selinux_restore
 
 %build
+autoconf
+automake-1.7
+autoheader
 %configure --enable-gtk-doc
 make
 

Re: file_type_auto_trans is not sufficient

[Ivan Gyurdiev]

> I'm really starting to think that this is too ugly, and not an
> acceptable solution, but I don't have another suggestion at this time.

The fontconfig patch is wrong - does not always restore context...

More significantly, however, how does this scheme work in multithreaded
context? It seems like it won't work - the switch-create-restore
sequence should not be interruptible if multiple threads share
the same creation context...

-- 
Ivan Gyurdiev <ivg2@cornell.edu>
Cornell University


--
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: file_type_auto_trans is not sufficient

[Stephen Smalley]

On Fri, 2005-05-27 at 23:09 -0400, Ivan Gyurdiev wrote:
> To address those problems, I think I need to add selinux support
> to a number of applications, and perform the transition in the code. 
> I'm not sure what's the best way to do that. Does adding 
> the following functions to libselinux (or elsewhere) make sense?
> 
> int mkdir_restorecon(const char *pathname, mode_t mode);
> int creat_restorecon(const char *pathname, mode_t mode);
> int mknod_restorecon(const char *pathname, mode_t mode, dev_t dev);
> 
> Those would perform getfscreate/matchpathcon/setfscreate cycle,
> and would ignore errors in permissive mode.

I'd advise against creating a composite interface like this, as it runs
into the same problems that we had with the original SELinux API (which
had extended forms of mkdir/creat/mknod/exec), i.e. use of glibc
functions that internally use these functions, as you note in a later
message.  Instead, keep the setting and resetting of the fscreate
context as a separate operation, and then let the application continue
to use ordinary mkdir/create/mknod or glibc functions for the actual
creation.

-- 
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: file_type_auto_trans is not sufficient

[Ivan Gyurdiev]

> I'd advise against creating a composite interface like this, as it runs
> into the same problems that we had with the original SELinux API (which
> had extended forms of mkdir/creat/mknod/exec), i.e. use of glibc
> functions that internally use these functions, as you note in a later
> message.

I agree, that was a bad idea.

>   Instead, keep the setting and resetting of the fscreate
> context as a separate operation, and then let the application continue
> to use ordinary mkdir/create/mknod or glibc functions for the actual
> creation.

Yes, but there's problems with that - in particular:

- is this thread-safe - see my later message

- is this a good idea - it pushes dynamic type changes into various
programs, while otherwise it's all in the policy, and easier to analyze 

- makes virtually everything depend on libselinux

- I'm replicating the same code pattern in lots of places...

- it puts linux-specific code into otherwise portable apps. I've
surrounded it all by WITH_SELINUX, but it's still rather ugly - 
don't think upstream will like it.



--
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: file_type_auto_trans is not sufficient

[Stephen Smalley]

On Mon, 2005-05-30 at 04:05 -0400, Ivan Gyurdiev wrote:
> More significantly, however, how does this scheme work in multithreaded
> context? It seems like it won't work - the switch-create-restore
> sequence should not be interruptible if multiple threads share
> the same creation context...

The issue of multi-threaded apps came up when the SELinux API was
overhauled for 2.6 and the original extended operations like
mkdir_secure() and execve_secure() were replaced by setfscreatecon() and
setexeccon() prior to the normal operation.  At that time, it was
possible to use them in multi-threaded apps because the fscreate and
exec contexts are stored per-kernel-thread, NPTL used a 1:1 user:kernel
threading model, and /proc/self referenced the per-thread state.  Then,
circa 2.6.0-test6, /proc was suddenly changed such that top-level /proc
only contains the thread group leaders and /proc/self refers to the
thread group leader rather than the per-thread state, and you have to
use /proc/self/task/<tid> to access the per-thread state.  Thus, at
present, any multi-threaded app will encounter a denial upon attempting
to use setfscreatecon(3) or setexeccon(3) from a thread other than the
thread group  leader.  In short, the API doesn't presently allow for use
by multiple threads, although the implementation could support it (for
any threading library that uses a 1:1 user-to-kernel threading model).

-- 
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: file_type_auto_trans is not sufficient

[Stephen Smalley]

On Tue, 2005-05-31 at 09:35 -0400, Ivan Gyurdiev wrote:
> Yes, but there's problems with that - in particular:
> 
> - is this thread-safe - see my later message

Answer:  Thread-safe, yes.  Allowed by current libselinux, no.

> - is this a good idea - it pushes dynamic type changes into various
> programs, while otherwise it's all in the policy, and easier to analyze 

Everything still has to be allowed by the policy, so analysis is still
feasible.  setfscreatecon() just selects one of the types allowed by the
policy for that domain to create.  Further, as you are using
matchpathcon(3), you can still see the filesystem mapping via
file_contexts.  Possibly the real question is whether the fine-grained
typing is truly justified and/or whether it might be feasible to achieve
via relocation so that the parent directory can be the distinguisher.

> - makes virtually everything depend on libselinux

Already true, e.g. /sbin/init, coreutils, ...
If it is a real concern, then others have suggested dlopen() and
friends.  But given that distros have been willing to date to accept
fundamental dependency for init and coreutils, it seems unlikely to be
needed.

> - I'm replicating the same code pattern in lots of places...

True.

> - it puts linux-specific code into otherwise portable apps. I've
> surrounded it all by WITH_SELINUX, but it's still rather ugly - 
> don't think upstream will like it.

True.

-- 
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: file_type_auto_trans is not sufficient

[Karl MacMillan]

> -----Original Message-----
> From: owner-selinux@tycho.nsa.gov [mailto:owner-selinux@tycho.nsa.gov] On
> Behalf Of Ivan Gyurdiev
> Sent: Tuesday, May 31, 2005 9:36 AM
> To: Stephen Smalley
> Cc: SELinux@tycho.nsa.gov; dwalsh@redhat.com
> Subject: Re: file_type_auto_trans is not sufficient
> 
> 
> > I'd advise against creating a composite interface like this, as it runs
> > into the same problems that we had with the original SELinux API (which
> > had extended forms of mkdir/creat/mknod/exec), i.e. use of glibc
> > functions that internally use these functions, as you note in a later
> > message.
> 
> I agree, that was a bad idea.
> 
> >   Instead, keep the setting and resetting of the fscreate
> > context as a separate operation, and then let the application continue
> > to use ordinary mkdir/create/mknod or glibc functions for the actual
> > creation.
> 
> Yes, but there's problems with that - in particular:
> 
> - is this thread-safe - see my later message
> 
> - is this a good idea - it pushes dynamic type changes into various
> programs, while otherwise it's all in the policy, and easier to analyze
> 
> - makes virtually everything depend on libselinux
> 
> - I'm replicating the same code pattern in lots of places...
> 
> - it puts linux-specific code into otherwise portable apps. I've
> surrounded it all by WITH_SELINUX, but it's still rather ugly -
> don't think upstream will like it.
> 

The other option, of course, is to change the applications to use/create many
more directories, each with a separate type to allow the file_type_auto_trans
rules to work. Your orbit example might mean that there is a /tmp/orbit
directory where all orbit files are created. This may not be any more feasible,
but I think it should at least be considered.

Karl

---
Karl MacMillan
Tresys Technology
http://www.tresys.com
(410) 290-1411 ext 134

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



--
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: file_type_auto_trans is not sufficient

[Ivan Gyurdiev]

> The other option, of course, is to change the applications to use/create many
> more directories, each with a separate type to allow the file_type_auto_trans
> rules to work. Your orbit example might mean that there is a /tmp/orbit
> directory where all orbit files are created.

The problem is not multiple source domains - that can be addressed
through macros. The problem is that those domains use the same directory
(Usually /tmp, or /home), for their own purposes, and they need the same
transition (same directory and target class (dir/file)). 

Because you can have only one transition, this creates a problem.

For example, look at mozilla, using the patches I posted earlier:

Needs transition on :

(ROLE_home_dir_t, file) -> ROLE_untrusted_content_t
     when saving web pages
(ROLE_home_dir_t, file) -> ROLE_fonts_cache_t 
     when updating the font cache (read_fonts macro, libfontconfig)
(ROLE_home_dir_t, dir) -> ROLE_mozilla_home_t 
     when creating its home directory
(ROLE_home_dir_t, dir) -> ROLE_untrusted_content_t
     when saving web pages image data

(tmp_t, file) -> ROLE_untrusted_content_t
     when saving temporary files from the internet
(tmp_t, dir) -> ROLE_untrusted_content_t
     same problem
(tmp_t, dir) -> ROLE_orbit_tmp_t 
      when creating the ORBit temp folder, libORBit2 (through bonobo)

Evolution has most of the same problems.

This is most problematic when the creation code is in a shared library,
because that gets called from lots of domains, which may use the same 
container directory/mode pair for their own data.

Earlier we discussed how keeping settings away from content would be a
good idea. Still, that wouldn't solve the problem, since then you would 
have to distinguish between different types of settings, which would
all need a transition (and an app may need to use all of them via 
shared libraries)

You're also suggesting that the problem is with the application, while
to me this seems like a SELinux problem. I'm not sure restructuring
directories so that they only store homogenous data (labeled the same
way) is feasable (or desirable). 


--
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: file_type_auto_trans is not sufficient

[Ivan Gyurdiev]

>   At that time, it was
> possible to use them in multi-threaded apps because the fscreate and
> exec contexts are stored per-kernel-thread, NPTL used a 1:1 user:kernel
> threading model, and /proc/self referenced the per-thread state.  Then,
> circa 2.6.0-test6, /proc was suddenly changed such that top-level /proc
> only contains the thread group leaders and /proc/self refers to the
> thread group leader rather than the per-thread state, and you have to
> use /proc/self/task/<tid> to access the per-thread state.  Thus, at
> present, any multi-threaded app will encounter a denial upon attempting
> to use setfscreatecon(3) or setexeccon(3) from a thread other than the
> thread group  leader.  In short, the API doesn't presently allow for use
> by multiple threads, although the implementation could support it (for
> any threading library that uses a 1:1 user-to-kernel threading model).

So other threads will fail to create the desired file in enforcing mode.
This certainly seems like a bad thing...

Would you recommend I go ahead with this setfscreatecon scheme, though?

I don't see any other way to create things in the proper context when
you have two (or more) conflicting file_type_auto_trans rules.


--
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: file_type_auto_trans is not sufficient

[Karl MacMillan]

> -----Original Message-----
> From: Ivan Gyurdiev [mailto:ivg2@cornell.edu]
> Sent: Tuesday, May 31, 2005 10:57 AM
> To: Karl MacMillan
> Cc: 'Stephen Smalley'; SELinux@tycho.nsa.gov; dwalsh@redhat.com
> Subject: RE: file_type_auto_trans is not sufficient
> 
> 
> > The other option, of course, is to change the applications to use/create
> many
> > more directories, each with a separate type to allow the
> file_type_auto_trans
> > rules to work. Your orbit example might mean that there is a /tmp/orbit
> > directory where all orbit files are created.
> 
> The problem is not multiple source domains - that can be addressed
> through macros. The problem is that those domains use the same directory
> (Usually /tmp, or /home), for their own purposes, and they need the same
> transition (same directory and target class (dir/file)).
> 

I know - that is why I am suggesting that each application could use multiple
directories. That means that orbit might put files into multiple directories
that were previously created, e.g. both /tmp and /tmp/orbit. The net result is
the same as making them selinux aware, but without the problem of selinux
specific code. It also works fine for multiple threads.

Again, this might mean creating many directory types and forcing directory
layouts that upstream / users might not like so it may not be an real option,
but technically it would work.

Karl

---
Karl MacMillan
Tresys Technology
http://www.tresys.com
(410) 290-1411 ext 134

> Because you can have only one transition, this creates a problem.
> 
> For example, look at mozilla, using the patches I posted earlier:
> 
> Needs transition on :
> 
> (ROLE_home_dir_t, file) -> ROLE_untrusted_content_t
>      when saving web pages
> (ROLE_home_dir_t, file) -> ROLE_fonts_cache_t
>      when updating the font cache (read_fonts macro, libfontconfig)
> (ROLE_home_dir_t, dir) -> ROLE_mozilla_home_t
>      when creating its home directory
> (ROLE_home_dir_t, dir) -> ROLE_untrusted_content_t
>      when saving web pages image data
> 
> (tmp_t, file) -> ROLE_untrusted_content_t
>      when saving temporary files from the internet
> (tmp_t, dir) -> ROLE_untrusted_content_t
>      same problem
> (tmp_t, dir) -> ROLE_orbit_tmp_t
>       when creating the ORBit temp folder, libORBit2 (through bonobo)
> 
> Evolution has most of the same problems.
> 
> This is most problematic when the creation code is in a shared library,
> because that gets called from lots of domains, which may use the same
> container directory/mode pair for their own data.
> 
> Earlier we discussed how keeping settings away from content would be a
> good idea. Still, that wouldn't solve the problem, since then you would
> have to distinguish between different types of settings, which would
> all need a transition (and an app may need to use all of them via
> shared libraries)
> 
> You're also suggesting that the problem is with the application, while
> to me this seems like a SELinux problem. I'm not sure restructuring
> directories so that they only store homogenous data (labeled the same
> way) is feasable (or desirable).



--
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: file_type_auto_trans is not sufficient

[Ivan Gyurdiev]

> I know - that is why I am suggesting that each application could use multiple
> directories. That means that orbit might put files into multiple directories
> that were previously created, e.g. both /tmp and /tmp/orbit.

I am not following this - can you give an example.

Say you have an application such as gconf, which stores its data 
in /tmp/gconfd-$USER (so it needs to be able to create that). 
GConf is linked to libORBit2, hence it needs to be able to
create /tmp/orbit-$USER.

Running gconfd in an individual domain is possible (and that's exactly
what I've done). Running orbit in its domain does not work (at least not
without a dynamic transition), because it's library code.

Are you saying that either gconfd or orbit need to move their files
outside their designated directory and into /tmp?




--
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: file_type_auto_trans is not sufficient

[Stephen Smalley]

On Tue, 2005-05-31 at 12:48 -0400, Ivan Gyurdiev wrote:
> I am not following this - can you give an example.
> 
> Say you have an application such as gconf, which stores its data 
> in /tmp/gconfd-$USER (so it needs to be able to create that). 
> GConf is linked to libORBit2, hence it needs to be able to
> create /tmp/orbit-$USER.
> 
> Running gconfd in an individual domain is possible (and that's exactly
> what I've done). Running orbit in its domain does not work (at least not
> without a dynamic transition), because it's library code.
> 
> Are you saying that either gconfd or orbit need to move their files
> outside their designated directory and into /tmp?

Problem is that they both want to create directly in /tmp.  It would be
preferable if they had a dedicated subtree, e.g. /tmp/gconfd
and /tmp/orbit, with all per-user subdirectories underneath, so that the
top-level directory could be typed separately and set up a priori (at
boot if truly under /tmp, as they might otherwise have been deleted).
BTW, what will per-user /tmp directories due to these conventions
anyway, even aside from any possible SELinux-related change?

-- 
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: file_type_auto_trans is not sufficient

[Ivan Gyurdiev]

> Problem is that they both want to create directly in /tmp.  It would be
> preferable if they had a dedicated subtree, e.g. /tmp/gconfd
> and /tmp/orbit, with all per-user subdirectories underneath, so that the
> top-level directory could be typed separately and set up a priori (at
> boot if truly under /tmp, as they might otherwise have been deleted).

So you're saying that the directories should be created ahead of time by
a startup script, and restorecon executed on them... something 
like tmpskel? Maybe that can be used for libICE, which I want to
label /tmp/.ICE-unix as ice_tmp_t.

What about /home, which has the same problem, but directories can't be
created ahead of time (adding to /skel doesn't work - if an application
is installed, the users created prior to installation have no folder).

What about file conflicts - then you can't create directories ahead of
time... 

> BTW, what will per-user /tmp directories due to these conventions
> anyway, even aside from any possible SELinux-related change?

What's the question again?


--
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: file_type_auto_trans is not sufficient

[Stephen Smalley]

On Tue, 2005-05-31 at 13:37 -0400, Ivan Gyurdiev wrote:
> > BTW, what will per-user /tmp directories due to these conventions
> > anyway, even aside from any possible SELinux-related change?
> 
> What's the question again?

If Fedora implements private tmp directories (regardless of approach,
whether using namespaces and bind mounts ala polyinstantiated
directories or using the simple profile script suggested on fedora-
devel-list), then creating $TMPDIR/gconfd-$USER becomes rather silly, as
$TMPDIR becomes per-user anyway.
 
-- 
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: file_type_auto_trans is not sufficient

[Ivan Gyurdiev]

On Tue, 2005-05-31 at 13:39 -0400, Stephen Smalley wrote:
> On Tue, 2005-05-31 at 13:37 -0400, Ivan Gyurdiev wrote:
> > > BTW, what will per-user /tmp directories due to these conventions
> > > anyway, even aside from any possible SELinux-related change?
> > 
> > What's the question again?
> 
> If Fedora implements private tmp directories (regardless of approach,
> whether using namespaces and bind mounts ala polyinstantiated
> directories or using the simple profile script suggested on fedora-
> devel-list), then creating $TMPDIR/gconfd-$USER becomes rather silly, as
> $TMPDIR becomes per-user anyway.

That's true... but something still needs to create those directories
(with our without the USER in it). If they're not created ahead of time
then you run into transition ambiguity. 

I suppose they could be created ahead of time:

- on-boot script for creating those "common-root" directories in /tmp,
based on what applications are currently installed (...need apps to 
put folders in this "tmpskel")

- applications could add /home/.* folders for users that already
exist when installed, and at the same time install their folder in /skel
to deal with future users. All of this seems rather fragile though.

- files: move into directories to eliminate the problem.
 


--
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: file_type_auto_trans is not sufficient

[Luke Kenneth Casson Leighton]

On Tue, May 31, 2005 at 01:37:23PM -0400, Ivan Gyurdiev wrote:
> 
> > Problem is that they both want to create directly in /tmp.  It would be
> > preferable if they had a dedicated subtree, e.g. /tmp/gconfd
> > and /tmp/orbit, with all per-user subdirectories underneath, so that the
> > top-level directory could be typed separately and set up a priori (at
> > boot if truly under /tmp, as they might otherwise have been deleted).
> 
> So you're saying that the directories should be created ahead of time by
> a startup script, and restorecon executed on them... something 
> like tmpskel? Maybe that can be used for libICE, which I want to
> label /tmp/.ICE-unix as ice_tmp_t.
 
 there is a whole slew of legacy applications that assume
 access to /tmp/.ICE-unix, /tmp/.X11-unix etc.

 it's a known problem for which the solution - creating tmp
 subdirectories - has been "scheduled" / "shelved".

 l.


--
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: file_type_auto_trans is not sufficient

[Luke Kenneth Casson Leighton]

On Tue, May 31, 2005 at 12:48:34PM -0400, Ivan Gyurdiev wrote:
> 
> > I know - that is why I am suggesting that each application could use multiple
> > directories. That means that orbit might put files into multiple directories
> > that were previously created, e.g. both /tmp and /tmp/orbit.
> 
> I am not following this - can you give an example.
> 
> Say you have an application such as gconf, which stores its data 
> in /tmp/gconfd-$USER (so it needs to be able to create that). 
> GConf is linked to libORBit2, hence it needs to be able to
> create /tmp/orbit-$USER.
> 
> Running gconfd in an individual domain is possible (and that's exactly
> what I've done). Running orbit in its domain does not work (at least not
> without a dynamic transition), because it's library code.
> 
> Are you saying that either gconfd or orbit need to move their files
> outside their designated directory and into /tmp?
 
 into /tmp/gconfd/something-$USER.

 yep.

 maybe the way forward is to create a [tiny] library with two
 functions in it: one that creates /tmp/socket and another
 that opens it, convert all programs to use that library, then
 convert the library to create /tmp/dir/socket.
 
 l.


--
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: file_type_auto_trans is not sufficient

[Luke Kenneth Casson Leighton]

On Tue, May 31, 2005 at 10:57:20AM -0400, Ivan Gyurdiev wrote:
> 
> > The other option, of course, is to change the applications to use/create many
> > more directories, each with a separate type to allow the file_type_auto_trans
> > rules to work. Your orbit example might mean that there is a /tmp/orbit
> > directory where all orbit files are created.
> 
> The problem is not multiple source domains - that can be addressed
> through macros. The problem is that those domains use the same directory
> (Usually /tmp, or /home), for their own purposes, and they need the same
> transition (same directory and target class (dir/file)). 
> 
> Because you can have only one transition, this creates a problem.
 
 ...

 thinking "sideways" again - as i am wont to do.

 how about... a "sideways" solution to this - at the kernel level?

 a "silent" redirection / remount, on a per-application basis?

 no, i'm not joking.

 an option to "mount" which allows a specific APPLICATION (or group of
 applications) to have any files/directories it creates/accesses in a
 subdirectory ACTUALLY occur ELSEWHERE.

 e.g.:

 mount -o redirectexe=/usr/bin/mozilla-firefox /tmp /tmp/mozilla
 mount -o redirectexe=/usr/bin/gnomeshite,/usr/bin/gnomemoreshite /tmp /tmp/gconf

 hm, that could get out-of-hand - the number of programs involved
 that would need redirection..

 *thinks* ... some other mechanism for "grouping" executables...

 you could even hang it off of an selinux context (!) or selinux domain
 (!) such that a set of executables, possibly those executed by
 certain users, would result in filesystem redirection - but not others.

 at your own discretion.

 then, you _could_ specify /tmp/gconf equals "a different file context".

 l.


--
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: file_type_auto_trans is not sufficient

[Luke Kenneth Casson Leighton]

On Tue, May 31, 2005 at 10:57:20AM -0400, Ivan Gyurdiev wrote:
> 
> > The other option, of course, is to change the applications to use/create many
> > more directories, each with a separate type to allow the file_type_auto_trans
> > rules to work. Your orbit example might mean that there is a /tmp/orbit
> > directory where all orbit files are created.
> 
> The problem is not multiple source domains - that can be addressed
> through macros. The problem is that those domains use the same directory
> (Usually /tmp, or /home), for their own purposes, and they need the same
> transition (same directory and target class (dir/file)). 
> 
> Because you can have only one transition, this creates a problem.
 
 ...

 thinking "sideways" again - as i am wont to do.

 how about... a "sideways" solution to this - at the kernel level?

 a "silent" redirection / remount, on a per-application basis?

 no, i'm not joking.

 an option to "mount" which allows a specific APPLICATION (or group of
 applications) to have any files/directories it creates/accesses in a
 subdirectory ACTUALLY occur ELSEWHERE.

 e.g.:

 mount -o redirectexe=/usr/bin/mozilla-firefox /tmp /tmp/mozilla
 mount -o redirectexe=/usr/bin/gnomeshite,/usr/bin/gnomemoreshite /tmp /tmp/gconf

 hm, that could get out-of-hand - the number of programs involved
 that would need redirection..

 *thinks* ... some other mechanism for "grouping" executables...

 you could even hang it off of an selinux context (!) or selinux domain
 (!) such that a set of executables, possibly those executed by
 certain users, would result in filesystem redirection - but not others.

 at your own discretion.

 then, you _could_ specify /tmp/gconf equals "a different file context".

 l.

Re: file_type_auto_trans is not sufficient

[Chad Sellers]

On May 31, 2005, at 5:21 PM, Luke Kenneth Casson Leighton wrote:


> On Tue, May 31, 2005 at 10:57:20AM -0400, Ivan Gyurdiev wrote:
>
>
>>
>>
>>
>>> The other option, of course, is to change the applications to use/ 
>>> create many
>>> more directories, each with a separate type to allow the  
>>> file_type_auto_trans
>>> rules to work. Your orbit example might mean that there is a /tmp/ 
>>> orbit
>>> directory where all orbit files are created.
>>>
>>>
>>
>> The problem is not multiple source domains - that can be addressed
>> through macros. The problem is that those domains use the same  
>> directory
>> (Usually /tmp, or /home), for their own purposes, and they need  
>> the same
>> transition (same directory and target class (dir/file)).
>>
>> Because you can have only one transition, this creates a problem.
>>
>>
>
>  ...
>
>  thinking "sideways" again - as i am wont to do.
>
>  how about... a "sideways" solution to this - at the kernel level?
>
>  a "silent" redirection / remount, on a per-application basis?
>
>  no, i'm not joking.
>
>  an option to "mount" which allows a specific APPLICATION (or group of
>  applications) to have any files/directories it creates/accesses in a
>  subdirectory ACTUALLY occur ELSEWHERE.
>
>  e.g.:
>
>  mount -o redirectexe=/usr/bin/mozilla-firefox /tmp /tmp/mozilla
>  mount -o redirectexe=/usr/bin/gnomeshite,/usr/bin/gnomemoreshite / 
> tmp /tmp/gconf
>
>  hm, that could get out-of-hand - the number of programs involved
>  that would need redirection..
>
>  *thinks* ... some other mechanism for "grouping" executables...
>
>  you could even hang it off of an selinux context (!) or selinux  
> domain
>  (!) such that a set of executables, possibly those executed by
>  certain users, would result in filesystem redirection - but not  
> others.
>
>  at your own discretion.
>
>  then, you _could_ specify /tmp/gconf equals "a different file  
> context".
>
>

Something like this already exists in userspace, though it's not  
entirely transparent.  The polyinsantiation library I posted a couple  
of weeks ago allows applications to bind mount (in a private  
namespace) member directories according to policy (type member  
rules).  This is mostly thought of as useful for user separation, but  
it can separate any types.  So, add a short wrapper program to call  
security_setupns() (from my patch) around mozilla and appropriate  
policy, and mozilla can have a private /tmp.  (note:  the wrapper  
would need to link any important files out of the original /tmp, such  
as X11 sockfiles).

That said, this doesn't solve Ivan's problem.  You still have a  
single application (gconfd in his example) creating /tmp/gconfd and / 
tmp/orbit, with only one type transition rule allowed.  You can't  
mount /tmp/gconfd over /tmp for portions of execution, and then /tmp/ 
orbit over /tmp for other parts of execution.

Chad



--
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: file_type_auto_trans is not sufficient

[Luke Kenneth Casson Leighton]

On Tue, May 31, 2005 at 07:09:43PM -0400, Chad Sellers wrote:
> That said, this doesn't solve Ivan's problem.  You still have a  
> single application (gconfd in his example) creating /tmp/gconfd and / 
> tmp/orbit, with only one type transition rule allowed.  You can't  
> mount /tmp/gconfd over /tmp for portions of execution, and then /tmp/ 
> orbit over /tmp for other parts of execution.

 drat - duh, course you can't.

 "transitional" library it is, then.


--
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: file_type_auto_trans is not sufficient

[Stephen Smalley]

On Tue, 2005-05-31 at 22:21 +0100, Luke Kenneth Casson Leighton wrote:
>  thinking "sideways" again - as i am wont to do.
> 
>  how about... a "sideways" solution to this - at the kernel level?
> 
>  a "silent" redirection / remount, on a per-application basis?
> 
>  no, i'm not joking.
> 
>  an option to "mount" which allows a specific APPLICATION (or group of
>  applications) to have any files/directories it creates/accesses in a
>  subdirectory ACTUALLY occur ELSEWHERE.

That's polyinstantiated directories.  See Chad Seller's postings.
However, it uses the kernel's existing support for per-process
namespaces and bind mounts rather than anything new in the kernel.

-- 
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: file_type_auto_trans is not sufficient

[Stephen Smalley]

On Tue, 2005-05-31 at 22:21 +0100, Luke Kenneth Casson Leighton wrote:
>  thinking "sideways" again - as i am wont to do.
> 
>  how about... a "sideways" solution to this - at the kernel level?
> 
>  a "silent" redirection / remount, on a per-application basis?
> 
>  no, i'm not joking.
> 
>  an option to "mount" which allows a specific APPLICATION (or group of
>  applications) to have any files/directories it creates/accesses in a
>  subdirectory ACTUALLY occur ELSEWHERE.

That's polyinstantiated directories.  See Chad Seller's postings.
However, it uses the kernel's existing support for per-process
namespaces and bind mounts rather than anything new in the kernel.

-- 
Stephen Smalley
National Security Agency