[PATCH] newrole: use pam session management services - v4

[PATCH] newrole: use pam session management services - v4

[Janak Desai]

This patch updates newrole to allow it to use pam session mangement
services. Currently newrole only uses the authenticaion services of
pam. Session management services are needed to allow pam_namespace
to appropriately reconfigure polyinstantiated namespace for the
new session being established with newrole.

For newrole to work correctly with pam_namespace, in addtion to
this patch, a patch to pam_namespace and a patch to the lssp 
policy will also be required. These additional patches will be
posted the selinux mailing list following this patch.

Changes since v3 of this patch, posted on 8/27/06:
    1. Incorporated feedback to v2
       a. Create/install an lspp version of newrole.pamd when
          building with LSPP_PRIV=y
       b. Removed duplicate definition of _GNU_SOURCE
       c. Keep CAP_SYS_ADMIN, CAP_FOWNER, CAP_CHOWN and
          CAP_DAC_OVERRIDE in permitted set and raise them in the
          effective set prior to calling pam session management
          functions.
    2. Forward ported to the latest selinux subversion tree (version 2014)
       on sourceforge and tested with fedora development package
       policycoreutils-1.30.28-1.src.rpm.

Signed-off-by: Janak Desai <janak@us.ibm.com>

---

 Makefile          |   18 +++-
 newrole-lspp.pamd |    5 +
 newrole.c         |  201 ++++++++++++++++++++++++++++++++++++++----------------
 3 files changed, 161 insertions(+), 63 deletions(-)

diff -Naurp policycoreutils/newrole/Makefile policycoreutils+newrolepatch/newrole/Makefile
--- policycoreutils/newrole/Makefile	2006-09-04 15:35:02.000000000 +0000
+++ policycoreutils+newrolepatch/newrole/Makefile	2006-09-04 16:04:11.000000000 +0000
@@ -6,10 +6,12 @@ ETCDIR ?= $(DESTDIR)/etc
 LOCALEDIR = /usr/share/locale
 PAMH = $(shell ls /usr/include/security/pam_appl.h 2>/dev/null)
 AUDITH = $(shell ls /usr/include/libaudit.h 2>/dev/null)
-# If LOG_AUDIT_PRIV is y, then newrole will be made into setuid root program.
-# This is so that we have the CAP_AUDIT_WRITE capability. newrole will
-# shed all privileges and change to the user's uid.
-LOG_AUDIT_PRIV ?= n
+# If LSPP_PRIV is y, then newrole will be made into setuid root program.
+# This is so that we have the CAP_AUDIT_WRITE capability for creating
+# and audit record and CAP_SYS_ADMIN, CAP_CHOWN, CAP_FOWNER and
+# CAP_DAC_OVERRIDE capabilities for pam_namespace module.
+# newrole will shed all privileges and change to the user's uid.
+LSPP_PRIV ?= n
 VERSION = $(shell cat ../VERSION)
 
 CFLAGS ?= -Werror -Wall -W
@@ -26,8 +28,8 @@ ifeq (${AUDITH}, /usr/include/libaudit.h
 	override CFLAGS += -DUSE_AUDIT
 	LDLIBS += -laudit
 endif
-ifeq (${LOG_AUDIT_PRIV},y)
-	override CFLAGS += -DLOG_AUDIT_PRIV -D_GNU_SOURCE
+ifeq (${LSPP_PRIV},y)
+	override CFLAGS += -DLSPP_PRIV
 	LDLIBS += -lcap
 	MODE := 4555
 else
@@ -46,8 +48,12 @@ install: all
 	install -m 644 newrole.1 $(MANDIR)/man1/
 ifeq (${PAMH}, /usr/include/security/pam_appl.h)
 	test -d $(ETCDIR)/pam.d || install -m 755 -d $(ETCDIR)/pam.d
+ifeq (${LSPP_PRIV},y)
+	install -m 644 newrole-lspp.pamd $(ETCDIR)/pam.d/newrole
+else
 	install -m 644 newrole.pamd $(ETCDIR)/pam.d/newrole
 endif
+endif
 
 clean:
 	rm -f $(TARGETS) *.o 
diff -Naurp policycoreutils/newrole/newrole-lspp.pamd policycoreutils+newrolepatch/newrole/newrole-lspp.pamd
--- policycoreutils/newrole/newrole-lspp.pamd	1970-01-01 00:00:00.000000000 +0000
+++ policycoreutils+newrolepatch/newrole/newrole-lspp.pamd	2006-09-04 16:04:11.000000000 +0000
@@ -0,0 +1,5 @@
+#%PAM-1.0
+auth       include	system-auth
+account    include	system-auth
+password   include	system-auth
+session    required	pam_namespace.so unmnt_remnt no_unmount_on_close
diff -Naurp policycoreutils/newrole/newrole.c policycoreutils+newrolepatch/newrole/newrole.c
--- policycoreutils/newrole/newrole.c	2006-09-04 15:35:02.000000000 +0000
+++ policycoreutils+newrolepatch/newrole/newrole.c	2006-09-04 16:14:06.000000000 +0000
@@ -66,9 +66,9 @@
 #ifdef USE_AUDIT
 #include <libaudit.h>
 #endif
-#ifdef LOG_AUDIT_PRIV
+#ifdef LSPP_PRIV
 #ifndef USE_AUDIT
-#error LOG_AUDIT_PRIV needs the USE_AUDIT option
+#error LSPP_PRIV needs the USE_AUDIT option
 #endif
 #include <sys/prctl.h>
 #include <sys/capability.h>
@@ -84,6 +84,17 @@
 #define PACKAGE "policycoreutils"	/* the name of this package lang translation */
 #endif
 
+#ifdef USE_PAM
+#include <unistd.h>             /* for getuid(), exit(), getopt() */
+
+#include <security/pam_appl.h>  /* for PAM functions */
+#include <security/pam_misc.h>  /* for misc_conv PAM utility function */
+
+#define SERVICE_NAME "newrole"  /* the name of this program for PAM */
+
+int authenticate_via_pam(const char *, pam_handle_t *);
+#endif
+
 /* USAGE_STRING describes the command-line args of this program. */
 #define USAGE_STRING "USAGE: newrole [ -r role ] [ -t type ] [ -l level ] [ -V ] [ -- args ]"
 
@@ -144,22 +155,6 @@ static char *build_new_range(char *newle
 }
 
 #ifdef USE_PAM
-
-/************************************************************************
- *
- * All PAM code goes in this section.
- *
- ************************************************************************/
-
-#include <unistd.h>		/* for getuid(), exit(), getopt() */
-
-#include <security/pam_appl.h>	/* for PAM functions */
-#include <security/pam_misc.h>	/* for misc_conv PAM utility function */
-
-#define SERVICE_NAME "newrole"	/* the name of this program for PAM */
-
-int authenticate_via_pam(const struct passwd *, const char *);
-
 /* authenticate_via_pam()
  *
  * in:     pw - struct containing data from our user's line in 
@@ -176,31 +171,13 @@ int authenticate_via_pam(const struct pa
  *
  */
 
-int authenticate_via_pam(const struct passwd *pw, const char *ttyn)
+int authenticate_via_pam(const char *ttyn, pam_handle_t *pam_handle)
 {
 
-	int result = 0;		/* our result, set to 0 (not authenticated) by default */
 	int rc;			/* pam return code */
-	pam_handle_t *pam_handle;	/* opaque handle used by all PAM functions */
+	int result = 0;		/* our result, set to 0 (not authenticated) by default */
 	const char *tty_name;
 
-	/* This is a jump table of functions for PAM to use when it wants to *
-	 * communicate with the user.  We'll be using misc_conv(), which is  *
-	 * provided for us via pam_misc.h.                                   */
-	struct pam_conv pam_conversation = {
-		misc_conv,
-		NULL
-	};
-
-	/* Make `p_pam_handle' a valid PAM handle so we can use it when *
-	 * calling PAM functions.                                       */
-	rc = pam_start(SERVICE_NAME,
-		       pw->pw_name, &pam_conversation, &pam_handle);
-	if (rc != PAM_SUCCESS) {
-		fprintf(stderr, _("failed to initialize PAM\n"));
-		exit(-1);
-	}
-
 	if (strncmp(ttyn, "/dev/", 5) == 0)
 		tty_name = ttyn + 5;
 	else
@@ -224,10 +201,7 @@ int authenticate_via_pam(const struct pa
 		result = 1;	/* user authenticated OK! */
 	}
 
-	/* We're done with PAM.  Free `pam_handle'. */
       out:
-	pam_end(pam_handle, rc);
-
 	return (result);
 
 }				/* authenticate_via_pam() */
@@ -334,19 +308,34 @@ static int verify_shell(const char *shel
 
 /*
  * This function will drop the capabilities so that we are left
- * only with access to the audit system. If the user is root, we leave
- * the capabilities alone since they already should have access to the
- * audit netlink socket.
+ * only with access to the audit system and the ability to raise
+ * CAP_SYS_ADMIN, CAP_DAC_OVERRIDE, CAP_FOWNER and CAP_CHOWN,
+ * before invoking pam_namespace.  These capabilities are needed
+ * for performing bind mounts/unmounts and to create potential new
+ * instance directories with appropriate DAC attributes. If the
+ * user is root, we leave the capabilities alone since they already
+ * should have access to the audit netlink socket and should have
+ * the ability to create/mount/unmount instance directories.
  */
-#ifdef LOG_AUDIT_PRIV
+#ifdef LSPP_PRIV
 static void drop_capabilities(void)
 {
 	uid_t uid = getuid();
 
 	if (uid) {		/* Non-root path */
 		cap_t new_caps, tmp_caps;
-		cap_value_t cap_list[] = { CAP_AUDIT_WRITE };
-		cap_value_t tmp_cap_list[] = { CAP_AUDIT_WRITE, CAP_SETUID };
+		cap_value_t cap_list_per[] = { CAP_AUDIT_WRITE,
+					       CAP_SYS_ADMIN,
+					       CAP_FOWNER,
+					       CAP_CHOWN,
+					       CAP_DAC_OVERRIDE };
+		cap_value_t cap_list_eff[] = { CAP_AUDIT_WRITE };
+		cap_value_t tmp_cap_list_per[] = { CAP_AUDIT_WRITE, CAP_SETUID,
+						   CAP_SYS_ADMIN, CAP_FOWNER,
+						   CAP_CHOWN,
+						   CAP_DAC_OVERRIDE };
+		cap_value_t tmp_cap_list_eff[] = { CAP_AUDIT_WRITE,
+						   CAP_SETUID };
 
 		new_caps = cap_init();
 		tmp_caps = cap_init();
@@ -355,10 +344,12 @@ static void drop_capabilities(void)
 				_("Error initing capabilities, aborting.\n"));
 			exit(-1);
 		}
-		cap_set_flag(new_caps, CAP_PERMITTED, 1, cap_list, CAP_SET);
-		cap_set_flag(new_caps, CAP_EFFECTIVE, 1, cap_list, CAP_SET);
-		cap_set_flag(tmp_caps, CAP_PERMITTED, 2, tmp_cap_list, CAP_SET);
-		cap_set_flag(tmp_caps, CAP_EFFECTIVE, 2, tmp_cap_list, CAP_SET);
+		cap_set_flag(new_caps, CAP_PERMITTED, 5, cap_list_per, CAP_SET);
+		cap_set_flag(new_caps, CAP_EFFECTIVE, 1, cap_list_eff, CAP_SET);
+		cap_set_flag(tmp_caps, CAP_PERMITTED, 6, tmp_cap_list_per,
+			     CAP_SET);
+		cap_set_flag(tmp_caps, CAP_EFFECTIVE, 2, tmp_cap_list_eff,
+			     CAP_SET);
 
 		/* Keep capabilities across uid change */
 		prctl(PR_SET_KEEPCAPS, 1, 0, 0, 0);
@@ -387,14 +378,56 @@ static void drop_capabilities(void)
 		/* Finish dropping capabilities. */
 		if (cap_set_proc(new_caps)) {
 			fprintf(stderr,
-				_
-				("Error dropping SETUID capability, aborting\n"));
+				_("Error dropping SETUID capability, aborting\n"));
 			exit(-1);
 		}
 		cap_free(new_caps);
 	}
 }
-#endif
+
+/*
+ * This function will raise/drop capabilities, in/from the effective set,
+ * needed by pam_namespace module. These were dropped from the effective
+ * set but retained in the permitted set using drop_capabilities().
+ * pam_namespace module needs CAP_DAC_OVERRIDE to create new instance
+ * directories in instance parent whose mode by default is 000. CAP_FOWNER
+ * and CAP_CHOWN is needed to set owner, group and mode of the newly
+ * created instance. CAP_SYS_ADMIN is needed to bind mount/unmount
+ * instance directories appropriately. Capabilities are raised if the
+ * argument act is set to CAP_SET, and dropped if the argument act is
+ * set to CAP_CLEAR.
+ */
+static void change_pns_effective_caps(cap_flag_value_t act)
+{
+	uid_t uid = getuid();
+
+	if (uid) {		/* Non-root path */
+		cap_t tmp_caps;
+
+		cap_value_t pns_cap_list[] = { CAP_SYS_ADMIN,
+					       CAP_FOWNER,
+					       CAP_CHOWN,
+					       CAP_DAC_OVERRIDE };
+
+		tmp_caps = cap_get_proc();
+
+		if (!tmp_caps) {
+			fprintf(stderr,
+				_("Error getting capabilities, aborting.\n"));
+			exit(-1);
+		}
+
+		cap_set_flag(tmp_caps, CAP_EFFECTIVE, 4, pns_cap_list, act);
+
+		if (cap_set_proc(tmp_caps)) {
+			fprintf(stderr,
+				_("Error dropping capabilities, aborting\n"));
+			exit(-1);
+		}
+		cap_free(tmp_caps);
+	}
+}
+#endif /* LSPP_PRIV */
 
 /************************************************************************
  *
@@ -434,8 +467,20 @@ int main(int argc, char *argv[])
 	int fd;
 	int enforcing;
 	sigset_t empty;
+#ifdef USE_PAM
+	int rc;			/* pam return code */
+	pam_handle_t *pam_handle;  /* opaque handle used by all PAM functions */
+
+	/* This is a jump table of functions for PAM to use when it wants to *
+	 * communicate with the user.  We'll be using misc_conv(), which is  *
+	 * provided for us via pam_misc.h.                                   */
+	struct pam_conv pam_conversation = {
+		misc_conv,
+		NULL
+	};
+#endif
 
-#ifdef LOG_AUDIT_PRIV
+#ifdef LSPP_PRIV
 	drop_capabilities();
 #endif
 
@@ -624,8 +669,18 @@ int main(int argc, char *argv[])
 	 * malicious software), not to authorize the operation (which is covered
 	 * by policy).  Trusted path mechanism would be preferred.
 	 */
+
 #ifdef USE_PAM
-	if (!authenticate_via_pam(pw, ttyn))
+	/* Make `p_pam_handle' a valid PAM handle so we can use it when *
+	 * calling PAM functions.                                       */
+	rc = pam_start(SERVICE_NAME,
+		       pw->pw_name, &pam_conversation, &pam_handle);
+	if (rc != PAM_SUCCESS) {
+		fprintf(stderr, _("failed to initialize PAM\n"));
+		exit(-1);
+	}
+
+	if (!authenticate_via_pam(ttyn, pam_handle))
 #else				/* !USE_PAM */
 	if (!authenticate_via_shadow_passwd(pw))
 #endif				/* if/else USE_PAM */
@@ -821,6 +876,23 @@ int main(int argc, char *argv[])
 		fsetfilecon(fd, tty_context);
 		freecon(tty_context);
 
+#ifdef USE_PAM
+#ifdef LSPP_PRIV
+		change_pns_effective_caps(CAP_SET);
+		rc = pam_close_session(pam_handle,0);
+		if(rc != PAM_SUCCESS) {
+			fprintf(stderr, "pam_close_session failed with %s\n",
+				pam_strerror(pam_handle, rc));
+			pam_end(pam_handle, rc);
+			exit(-1);
+		}
+		change_pns_effective_caps(CAP_CLEAR);
+#endif
+
+		/* We're done with PAM.  Free `pam_handle'. */
+		pam_end(pam_handle, rc);
+#endif
+
 		/* Done! */
 		exit(0);
 	}
@@ -873,7 +945,21 @@ int main(int argc, char *argv[])
 			new_context);
 		exit(-1);
 	}
-#ifdef LOG_AUDIT_PRIV
+
+#ifdef LSPP_PRIV
+	change_pns_effective_caps(CAP_SET);
+
+#ifdef USE_PAM
+	/* Ask PAM to setup session for user running this program */
+	rc = pam_open_session(pam_handle,0);
+	if(rc != PAM_SUCCESS) {
+		fprintf(stderr, "pam_open_session failed with %s\n",
+			pam_strerror(pam_handle, rc));
+		exit(-1);
+	}
+#endif
+	change_pns_effective_caps(CAP_CLEAR);
+
 	/* Send audit message */
 	{
 		char *msg;
@@ -900,6 +986,7 @@ int main(int argc, char *argv[])
 	}
 #endif
 	freecon(old_context);
+
 	execv(pw->pw_shell, argv + optind - 1);
 
 	/* If we reach here, then we failed to exec the new shell. */



--
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] newrole: use pam session management services - v4

[Joshua Brindle]

On Mon, 2006-09-04 at 17:01 -0400, Janak Desai wrote:
> This patch updates newrole to allow it to use pam session mangement
> services. Currently newrole only uses the authenticaion services of
> pam. Session management services are needed to allow pam_namespace
> to appropriately reconfigure polyinstantiated namespace for the
> new session being established with newrole.
> 
> For newrole to work correctly with pam_namespace, in addtion to
> this patch, a patch to pam_namespace and a patch to the lssp 
> policy will also be required. These additional patches will be
> posted the selinux mailing list following this patch.
> 
> Changes since v3 of this patch, posted on 8/27/06:
>     1. Incorporated feedback to v2
>        a. Create/install an lspp version of newrole.pamd when
>           building with LSPP_PRIV=y

why LSPP_PRIV? I don't think these changes are specific to lspp and
could have other applications. Also, why another binary instead of
handling the case where the capabilities aren't available gracefully?
How will users who need this automatically know to run newrole.pamd?

>        b. Removed duplicate definition of _GNU_SOURCE
>        c. Keep CAP_SYS_ADMIN, CAP_FOWNER, CAP_CHOWN and
>           CAP_DAC_OVERRIDE in permitted set and raise them in the
>           effective set prior to calling pam session management
>           functions.
>     2. Forward ported to the latest selinux subversion tree (version 2014)
>        on sourceforge and tested with fedora development package
>        policycoreutils-1.30.28-1.src.rpm.



--
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] newrole: use pam session management services - v4

[Stephen Smalley]

On Tue, 2006-09-05 at 08:20 -0400, Joshua Brindle wrote:
> On Mon, 2006-09-04 at 17:01 -0400, Janak Desai wrote:
> > This patch updates newrole to allow it to use pam session mangement
> > services. Currently newrole only uses the authenticaion services of
> > pam. Session management services are needed to allow pam_namespace
> > to appropriately reconfigure polyinstantiated namespace for the
> > new session being established with newrole.
> > 
> > For newrole to work correctly with pam_namespace, in addtion to
> > this patch, a patch to pam_namespace and a patch to the lssp 
> > policy will also be required. These additional patches will be
> > posted the selinux mailing list following this patch.
> > 
> > Changes since v3 of this patch, posted on 8/27/06:
> >     1. Incorporated feedback to v2
> >        a. Create/install an lspp version of newrole.pamd when
> >           building with LSPP_PRIV=y
> 
> why LSPP_PRIV? I don't think these changes are specific to lspp and
> could have other applications. Also, why another binary instead of
> handling the case where the capabilities aren't available gracefully?
> How will users who need this automatically know to run newrole.pamd?

The audit-related changes are presently conditional on LOG_AUDIT_PRIV;
he is generalizing that to LSPP_PRIV to cover both audit and namespace
functionality, both of which require a setuid newrole with certain
capabilities.  The .pamd files are pam config files, not binaries.
He is just following my comments on v3 of the patch, see my prior
posting.

> 
> >        b. Removed duplicate definition of _GNU_SOURCE
> >        c. Keep CAP_SYS_ADMIN, CAP_FOWNER, CAP_CHOWN and
> >           CAP_DAC_OVERRIDE in permitted set and raise them in the
> >           effective set prior to calling pam session management
> >           functions.
> >     2. Forward ported to the latest selinux subversion tree (version 2014)
> >        on sourceforge and tested with fedora development package
> >        policycoreutils-1.30.28-1.src.rpm.
> 
-- 
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] newrole: use pam session management services - v4

[Joshua Brindle]

On Tue, 2006-09-05 at 08:53 -0400, Stephen Smalley wrote:
> On Tue, 2006-09-05 at 08:20 -0400, Joshua Brindle wrote:
> > On Mon, 2006-09-04 at 17:01 -0400, Janak Desai wrote:
> > > This patch updates newrole to allow it to use pam session mangement
> > > services. Currently newrole only uses the authenticaion services of
> > > pam. Session management services are needed to allow pam_namespace
> > > to appropriately reconfigure polyinstantiated namespace for the
> > > new session being established with newrole.
> > > 
> > > For newrole to work correctly with pam_namespace, in addtion to
> > > this patch, a patch to pam_namespace and a patch to the lssp 
> > > policy will also be required. These additional patches will be
> > > posted the selinux mailing list following this patch.
> > > 
> > > Changes since v3 of this patch, posted on 8/27/06:
> > >     1. Incorporated feedback to v2
> > >        a. Create/install an lspp version of newrole.pamd when
> > >           building with LSPP_PRIV=y
> > 
> > why LSPP_PRIV? I don't think these changes are specific to lspp and
> > could have other applications. Also, why another binary instead of
> > handling the case where the capabilities aren't available gracefully?
> > How will users who need this automatically know to run newrole.pamd?
> 
> The audit-related changes are presently conditional on LOG_AUDIT_PRIV;
> he is generalizing that to LSPP_PRIV to cover both audit and namespace
> functionality, both of which require a setuid newrole with certain
> capabilities.  The .pamd files are pam config files, not binaries.
> He is just following my comments on v3 of the patch, see my prior
> posting.

Hrm, I looked back and didn't see anything, probably didn't look hard
enough. Is it really generalized if its LSPP specific, do we not see
anyone using the pam session capabilities for reasons other than LSPP?


--
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] newrole: use pam session management services - v4

[Stephen Smalley]

On Tue, 2006-09-05 at 09:00 -0400, Joshua Brindle wrote:
> On Tue, 2006-09-05 at 08:53 -0400, Stephen Smalley wrote:
> > On Tue, 2006-09-05 at 08:20 -0400, Joshua Brindle wrote:
> > > On Mon, 2006-09-04 at 17:01 -0400, Janak Desai wrote:
> > > > This patch updates newrole to allow it to use pam session mangement
> > > > services. Currently newrole only uses the authenticaion services of
> > > > pam. Session management services are needed to allow pam_namespace
> > > > to appropriately reconfigure polyinstantiated namespace for the
> > > > new session being established with newrole.
> > > > 
> > > > For newrole to work correctly with pam_namespace, in addtion to
> > > > this patch, a patch to pam_namespace and a patch to the lssp 
> > > > policy will also be required. These additional patches will be
> > > > posted the selinux mailing list following this patch.
> > > > 
> > > > Changes since v3 of this patch, posted on 8/27/06:
> > > >     1. Incorporated feedback to v2
> > > >        a. Create/install an lspp version of newrole.pamd when
> > > >           building with LSPP_PRIV=y
> > > 
> > > why LSPP_PRIV? I don't think these changes are specific to lspp and
> > > could have other applications. Also, why another binary instead of
> > > handling the case where the capabilities aren't available gracefully?
> > > How will users who need this automatically know to run newrole.pamd?
> > 
> > The audit-related changes are presently conditional on LOG_AUDIT_PRIV;
> > he is generalizing that to LSPP_PRIV to cover both audit and namespace
> > functionality, both of which require a setuid newrole with certain
> > capabilities.  The .pamd files are pam config files, not binaries.
> > He is just following my comments on v3 of the patch, see my prior
> > posting.
> 
> Hrm, I looked back and didn't see anything, probably didn't look hard
> enough. Is it really generalized if its LSPP specific, do we not see
> anyone using the pam session capabilities for reasons other than LSPP?

Entire thread is at:
http://marc.theaimsgroup.com/?t=115410947300001&r=1&w=2

We can't just add a pam_open_session() call to newrole without having an
actual session module in the config (otherwise, the call fails, and
newrole exits with an error, as I noted earlier in this thread), unless
there is some graceful way of dealing with that situation.  Further, the
patch also has to include changes to the capability manipulation code of
newrole to retain the capabilities required for pam_namespace until
after pam_open_session.  Hence, the patch is tightly coupled to
pam_namespace, which like the prior audit changes is motivated by LSPP.
The old LOG_AUDIT_PRIV option name was intended to connote both the
purpose (for audit support) and the fact that it required a privileged
newrole.  We could call it LOG_AUDIT_NAMESPACE_PRIV, but that takes me
back to my Ada days.  We could also try to split them up into separate
build options, but they have definite overlap (in capability
manipulation) and it isn't clear who will enable one without the other,
since they are both motivated by LSPP.

Anyway, the larger issue here is that this patch means that newrole will
retain a number of very powerful and general capabilities in its
permitted set for almost its entire execution, since the
pam_open_session has to occur late (after the setexeccon) for
pam_namespace to work.  This is in contrast to the audit changes, which
only required retaining CAP_AUDIT_WRITE, a very limited and specific
capability, and could drop all other capabilities permanently upon
startup.

-- 
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] newrole: use pam session management services - v4

[Stephen Smalley]

On Mon, 2006-09-04 at 17:01 -0400, Janak Desai wrote:
> This patch updates newrole to allow it to use pam session mangement
> services. Currently newrole only uses the authenticaion services of
> pam. Session management services are needed to allow pam_namespace
> to appropriately reconfigure polyinstantiated namespace for the
> new session being established with newrole.
> 
> For newrole to work correctly with pam_namespace, in addtion to
> this patch, a patch to pam_namespace and a patch to the lssp 
> policy will also be required. These additional patches will be
> posted the selinux mailing list following this patch.
> 
> Changes since v3 of this patch, posted on 8/27/06:
>     1. Incorporated feedback to v2
>        a. Create/install an lspp version of newrole.pamd when
>           building with LSPP_PRIV=y
>        b. Removed duplicate definition of _GNU_SOURCE
>        c. Keep CAP_SYS_ADMIN, CAP_FOWNER, CAP_CHOWN and
>           CAP_DAC_OVERRIDE in permitted set and raise them in the
>           effective set prior to calling pam session management
>           functions.

Implications of retaining those capabilities while still reverting to
the caller's uid?  ptrace checks capabilities, but e.g. kill does not.
This is similar to the issues associated with file capabilities, see
http://marc.theaimsgroup.com/?t=115422220700001&r=1&w=2

Now, in the case where newrole runs in its own domain, SELinux will
itself provide isolation/protection, so for the strict/MLS policy,
newrole should be protected against interference by the caller.  But
under targeted/MCS, you don't get such guarantees.  But I assume you
want to build a single newrole binary for everyone.

Does running in the caller's uid have any other implications for
pam_namespace, e.g. ownership of the directories it creates?

-- 
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] newrole: use pam session management services - v4

[Darrel Goeddel]

Janak Desai wrote:
> This patch updates newrole to allow it to use pam session mangement
> services. Currently newrole only uses the authenticaion services of
> pam. Session management services are needed to allow pam_namespace
> to appropriately reconfigure polyinstantiated namespace for the
> new session being established with newrole.
> 
> For newrole to work correctly with pam_namespace, in addtion to
> this patch, a patch to pam_namespace and a patch to the lssp 
> policy will also be required. These additional patches will be
> posted the selinux mailing list following this patch.
> 
> Changes since v3 of this patch, posted on 8/27/06:
>     1. Incorporated feedback to v2
>        a. Create/install an lspp version of newrole.pamd when
>           building with LSPP_PRIV=y
>        b. Removed duplicate definition of _GNU_SOURCE
>        c. Keep CAP_SYS_ADMIN, CAP_FOWNER, CAP_CHOWN and
>           CAP_DAC_OVERRIDE in permitted set and raise them in the
>           effective set prior to calling pam session management
>           functions.
>     2. Forward ported to the latest selinux subversion tree (version 2014)
>        on sourceforge and tested with fedora development package
>        policycoreutils-1.30.28-1.src.rpm.
> 
> Signed-off-by: Janak Desai <janak@us.ibm.com>

<snip>

> diff -Naurp policycoreutils/newrole/newrole.c policycoreutils+newrolepatch/newrole/newrole.c
> --- policycoreutils/newrole/newrole.c	2006-09-04 15:35:02.000000000 +0000
> +++ policycoreutils+newrolepatch/newrole/newrole.c	2006-09-04 16:14:06.000000000 +0000

<snip>

> @@ -821,6 +876,23 @@ int main(int argc, char *argv[])
>  		fsetfilecon(fd, tty_context);
>  		freecon(tty_context);
>  
> +#ifdef USE_PAM
> +#ifdef LSPP_PRIV
> +		change_pns_effective_caps(CAP_SET);
> +		rc = pam_close_session(pam_handle,0);
> +		if(rc != PAM_SUCCESS) {
> +			fprintf(stderr, "pam_close_session failed with %s\n",
> +				pam_strerror(pam_handle, rc));
> +			pam_end(pam_handle, rc);
> +			exit(-1);
> +		}
> +		change_pns_effective_caps(CAP_CLEAR);
> +#endif
> +
> +		/* We're done with PAM.  Free `pam_handle'. */
> +		pam_end(pam_handle, rc);
> +#endif
> +

Could we untangle the pam/lspp bits like I have below if we include
pam_permit as a session module in the "regular" pam config?  I think
that should take care of the case where we use pam, but do not have
any session management needs.  The use of pam_permit in this situation
seems perfectly acceptable to me.  This would give us real session
management capabilities via pam even if we are not using the lspp
configuration which requires privilege for pam_namespace.so.

#ifdef USE_PAM
#ifdef LSPP_PRIV
		change_pns_effective_caps(CAP_SET);
#endif /* LSPP_PRIV */
		rc = pam_close_session(pam_handle,0);
		if(rc != PAM_SUCCESS) {
			fprintf(stderr, "pam_close_session failed with %s\n",
				pam_strerror(pam_handle, rc));
			pam_end(pam_handle, rc);
			exit(-1);
		}
#ifdef LSPP_PRIV
		change_pns_effective_caps(CAP_CLEAR);
#endif /* LSPP_PRIV */

		/* We're done with PAM.  Free `pam_handle'. */
		pam_end(pam_handle, rc);
#endif /* USE_PAM */


> @@ -873,7 +945,21 @@ int main(int argc, char *argv[])
>  			new_context);
>  		exit(-1);
>  	}
> -#ifdef LOG_AUDIT_PRIV
> +
> +#ifdef LSPP_PRIV
> +	change_pns_effective_caps(CAP_SET);
> +
> +#ifdef USE_PAM
> +	/* Ask PAM to setup session for user running this program */
> +	rc = pam_open_session(pam_handle,0);
> +	if(rc != PAM_SUCCESS) {
> +		fprintf(stderr, "pam_open_session failed with %s\n",
> +			pam_strerror(pam_handle, rc));
> +		exit(-1);
> +	}
> +#endif
> +	change_pns_effective_caps(CAP_CLEAR);
> +

If the idea of using pam_permit is works out, then this section of code
would be re-bracketed as such:

#ifdef USE_PAM
#ifdef LSPP_PRIV
	change_pns_effective_caps(CAP_SET);
#endif /* LSPP_PRIV */
	/* Ask PAM to setup session for user running this program */
	rc = pam_open_session(pam_handle,0);
	if(rc != PAM_SUCCESS) {
		fprintf(stderr, "pam_open_session failed with %s\n",
			pam_strerror(pam_handle, rc));
		exit(-1);
	}
#ifdef LSPP_PRIV
	change_pns_effective_caps(CAP_CLEAR);
#endif /* LSPP_PRIV */
#endif /* USE_PAM */

#ifdef LSPP_PRIV
...do audit stuff...
#endif /* LSPP_PRIV */


We could alternatively just define the cap manipulation functions to do
nothing if LSPP_PRIV is not defined and call them unconditionally to
clean up the code a bit...

-- 

Darrel

--
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] newrole: use pam session management services - v4

[Stephen Smalley]

On Thu, 2006-09-07 at 11:30 -0500, Darrel Goeddel wrote:
> Janak Desai wrote:
> > This patch updates newrole to allow it to use pam session mangement
> > services. Currently newrole only uses the authenticaion services of
> > pam. Session management services are needed to allow pam_namespace
> > to appropriately reconfigure polyinstantiated namespace for the
> > new session being established with newrole.
> > 
> > For newrole to work correctly with pam_namespace, in addtion to
> > this patch, a patch to pam_namespace and a patch to the lssp 
> > policy will also be required. These additional patches will be
> > posted the selinux mailing list following this patch.
> > 
> > Changes since v3 of this patch, posted on 8/27/06:
> >     1. Incorporated feedback to v2
> >        a. Create/install an lspp version of newrole.pamd when
> >           building with LSPP_PRIV=y
> >        b. Removed duplicate definition of _GNU_SOURCE
> >        c. Keep CAP_SYS_ADMIN, CAP_FOWNER, CAP_CHOWN and
> >           CAP_DAC_OVERRIDE in permitted set and raise them in the
> >           effective set prior to calling pam session management
> >           functions.
> >     2. Forward ported to the latest selinux subversion tree (version 2014)
> >        on sourceforge and tested with fedora development package
> >        policycoreutils-1.30.28-1.src.rpm.
> > 
> > Signed-off-by: Janak Desai <janak@us.ibm.com>
> 
> <snip>
> 
> > diff -Naurp policycoreutils/newrole/newrole.c policycoreutils+newrolepatch/newrole/newrole.c
> > --- policycoreutils/newrole/newrole.c	2006-09-04 15:35:02.000000000 +0000
> > +++ policycoreutils+newrolepatch/newrole/newrole.c	2006-09-04 16:14:06.000000000 +0000
> 
> <snip>
> 
> > @@ -821,6 +876,23 @@ int main(int argc, char *argv[])
> >  		fsetfilecon(fd, tty_context);
> >  		freecon(tty_context);
> >  
> > +#ifdef USE_PAM
> > +#ifdef LSPP_PRIV
> > +		change_pns_effective_caps(CAP_SET);
> > +		rc = pam_close_session(pam_handle,0);
> > +		if(rc != PAM_SUCCESS) {
> > +			fprintf(stderr, "pam_close_session failed with %s\n",
> > +				pam_strerror(pam_handle, rc));
> > +			pam_end(pam_handle, rc);
> > +			exit(-1);
> > +		}
> > +		change_pns_effective_caps(CAP_CLEAR);
> > +#endif
> > +
> > +		/* We're done with PAM.  Free `pam_handle'. */
> > +		pam_end(pam_handle, rc);
> > +#endif
> > +
> 
> Could we untangle the pam/lspp bits like I have below if we include
> pam_permit as a session module in the "regular" pam config?  I think
> that should take care of the case where we use pam, but do not have
> any session management needs.  The use of pam_permit in this situation
> seems perfectly acceptable to me.  This would give us real session
> management capabilities via pam even if we are not using the lspp
> configuration which requires privilege for pam_namespace.so.
> 
> #ifdef USE_PAM
> #ifdef LSPP_PRIV
> 		change_pns_effective_caps(CAP_SET);
> #endif /* LSPP_PRIV */
> 		rc = pam_close_session(pam_handle,0);
> 		if(rc != PAM_SUCCESS) {
> 			fprintf(stderr, "pam_close_session failed with %s\n",
> 				pam_strerror(pam_handle, rc));
> 			pam_end(pam_handle, rc);
> 			exit(-1);
> 		}
> #ifdef LSPP_PRIV
> 		change_pns_effective_caps(CAP_CLEAR);
> #endif /* LSPP_PRIV */
> 
> 		/* We're done with PAM.  Free `pam_handle'. */
> 		pam_end(pam_handle, rc);
> #endif /* USE_PAM */
> 
> 
> > @@ -873,7 +945,21 @@ int main(int argc, char *argv[])
> >  			new_context);
> >  		exit(-1);
> >  	}
> > -#ifdef LOG_AUDIT_PRIV
> > +
> > +#ifdef LSPP_PRIV
> > +	change_pns_effective_caps(CAP_SET);
> > +
> > +#ifdef USE_PAM
> > +	/* Ask PAM to setup session for user running this program */
> > +	rc = pam_open_session(pam_handle,0);
> > +	if(rc != PAM_SUCCESS) {
> > +		fprintf(stderr, "pam_open_session failed with %s\n",
> > +			pam_strerror(pam_handle, rc));
> > +		exit(-1);
> > +	}
> > +#endif
> > +	change_pns_effective_caps(CAP_CLEAR);
> > +
> 
> If the idea of using pam_permit is works out, then this section of code
> would be re-bracketed as such:
> 
> #ifdef USE_PAM
> #ifdef LSPP_PRIV
> 	change_pns_effective_caps(CAP_SET);
> #endif /* LSPP_PRIV */
> 	/* Ask PAM to setup session for user running this program */
> 	rc = pam_open_session(pam_handle,0);
> 	if(rc != PAM_SUCCESS) {
> 		fprintf(stderr, "pam_open_session failed with %s\n",
> 			pam_strerror(pam_handle, rc));
> 		exit(-1);
> 	}
> #ifdef LSPP_PRIV
> 	change_pns_effective_caps(CAP_CLEAR);
> #endif /* LSPP_PRIV */
> #endif /* USE_PAM */
> 
> #ifdef LSPP_PRIV
> ...do audit stuff...
> #endif /* LSPP_PRIV */
> 
> 
> We could alternatively just define the cap manipulation functions to do
> nothing if LSPP_PRIV is not defined and call them unconditionally to
> clean up the code a bit...

Yes, that would make the code more readable.

-- 
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] newrole: use pam session management services - v4

[Janak Desai]

Stephen Smalley wrote:
> On Mon, 2006-09-04 at 17:01 -0400, Janak Desai wrote:
> 
>>This patch updates newrole to allow it to use pam session mangement
>>services. Currently newrole only uses the authenticaion services of
>>pam. Session management services are needed to allow pam_namespace
>>to appropriately reconfigure polyinstantiated namespace for the
>>new session being established with newrole.
>>
>>For newrole to work correctly with pam_namespace, in addtion to
>>this patch, a patch to pam_namespace and a patch to the lssp 
>>policy will also be required. These additional patches will be
>>posted the selinux mailing list following this patch.
>>
>>Changes since v3 of this patch, posted on 8/27/06:
>>    1. Incorporated feedback to v2
>>       a. Create/install an lspp version of newrole.pamd when
>>          building with LSPP_PRIV=y
>>       b. Removed duplicate definition of _GNU_SOURCE
>>       c. Keep CAP_SYS_ADMIN, CAP_FOWNER, CAP_CHOWN and
>>          CAP_DAC_OVERRIDE in permitted set and raise them in the
>>          effective set prior to calling pam session management
>>          functions.
> 
> 
> Implications of retaining those capabilities while still reverting to
> the caller's uid?  ptrace checks capabilities, but e.g. kill does not.
> This is similar to the issues associated with file capabilities, see
> http://marc.theaimsgroup.com/?t=115422220700001&r=1&w=2
> 
> Now, in the case where newrole runs in its own domain, SELinux will
> itself provide isolation/protection, so for the strict/MLS policy,
> newrole should be protected against interference by the caller.  But
> under targeted/MCS, you don't get such guarantees.  But I assume you
> want to build a single newrole binary for everyone.
> 
> Does running in the caller's uid have any other implications for
> pam_namespace, e.g. ownership of the directories it creates?
> 

No, pam_namespace will try and set ownership and mode of the
instance directories that it creates to those of the polyinstantiated
directory. That's why pam_namespace needs those powerful dac
capabilities. Instance parent, by default, is 000. To create
new instances, changing their ownership and mode and to
mount/unmount them requires that pam_namespace have chown,
fowner, dac_override and sys_admin capabilities.

-Janak




--
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] newrole: use pam session management services - v4

[Janak Desai]

Stephen Smalley wrote:

> On Thu, 2006-09-07 at 11:30 -0500, Darrel Goeddel wrote:
> 
>>Janak Desai wrote:
>>
>>>This patch updates newrole to allow it to use pam session mangement
>>>services. Currently newrole only uses the authenticaion services of
>>>pam. Session management services are needed to allow pam_namespace
>>>to appropriately reconfigure polyinstantiated namespace for the
>>>new session being established with newrole.
>>>
>>>For newrole to work correctly with pam_namespace, in addtion to
>>>this patch, a patch to pam_namespace and a patch to the lssp 
>>>policy will also be required. These additional patches will be
>>>posted the selinux mailing list following this patch.
>>>
>>>Changes since v3 of this patch, posted on 8/27/06:
>>>    1. Incorporated feedback to v2
>>>       a. Create/install an lspp version of newrole.pamd when
>>>          building with LSPP_PRIV=y
>>>       b. Removed duplicate definition of _GNU_SOURCE
>>>       c. Keep CAP_SYS_ADMIN, CAP_FOWNER, CAP_CHOWN and
>>>          CAP_DAC_OVERRIDE in permitted set and raise them in the
>>>          effective set prior to calling pam session management
>>>          functions.
>>>    2. Forward ported to the latest selinux subversion tree (version 2014)
>>>       on sourceforge and tested with fedora development package
>>>       policycoreutils-1.30.28-1.src.rpm.
>>>
>>>Signed-off-by: Janak Desai <janak@us.ibm.com>
>>
>><snip>
>>
>>>diff -Naurp policycoreutils/newrole/newrole.c policycoreutils+newrolepatch/newrole/newrole.c
>>>--- policycoreutils/newrole/newrole.c	2006-09-04 15:35:02.000000000 +0000
>>>+++ policycoreutils+newrolepatch/newrole/newrole.c	2006-09-04 16:14:06.000000000 +0000
>>
>><snip>
>>
>>>@@ -821,6 +876,23 @@ int main(int argc, char *argv[])
>>> 		fsetfilecon(fd, tty_context);
>>> 		freecon(tty_context);
>>> 
>>>+#ifdef USE_PAM
>>>+#ifdef LSPP_PRIV
>>>+		change_pns_effective_caps(CAP_SET);
>>>+		rc = pam_close_session(pam_handle,0);
>>>+		if(rc != PAM_SUCCESS) {
>>>+			fprintf(stderr, "pam_close_session failed with %s\n",
>>>+				pam_strerror(pam_handle, rc));
>>>+			pam_end(pam_handle, rc);
>>>+			exit(-1);
>>>+		}
>>>+		change_pns_effective_caps(CAP_CLEAR);
>>>+#endif
>>>+
>>>+		/* We're done with PAM.  Free `pam_handle'. */
>>>+		pam_end(pam_handle, rc);
>>>+#endif
>>>+
>>
>>Could we untangle the pam/lspp bits like I have below if we include
>>pam_permit as a session module in the "regular" pam config?  I think
>>that should take care of the case where we use pam, but do not have
>>any session management needs.  The use of pam_permit in this situation
>>seems perfectly acceptable to me.  This would give us real session
>>management capabilities via pam even if we are not using the lspp
>>configuration which requires privilege for pam_namespace.so.
>>
>>#ifdef USE_PAM
>>#ifdef LSPP_PRIV
>>		change_pns_effective_caps(CAP_SET);
>>#endif /* LSPP_PRIV */
>>		rc = pam_close_session(pam_handle,0);
>>		if(rc != PAM_SUCCESS) {
>>			fprintf(stderr, "pam_close_session failed with %s\n",
>>				pam_strerror(pam_handle, rc));
>>			pam_end(pam_handle, rc);
>>			exit(-1);
>>		}
>>#ifdef LSPP_PRIV
>>		change_pns_effective_caps(CAP_CLEAR);
>>#endif /* LSPP_PRIV */
>>
>>		/* We're done with PAM.  Free `pam_handle'. */
>>		pam_end(pam_handle, rc);
>>#endif /* USE_PAM */
>>
>>
>>
>>>@@ -873,7 +945,21 @@ int main(int argc, char *argv[])
>>> 			new_context);
>>> 		exit(-1);
>>> 	}
>>>-#ifdef LOG_AUDIT_PRIV
>>>+
>>>+#ifdef LSPP_PRIV
>>>+	change_pns_effective_caps(CAP_SET);
>>>+
>>>+#ifdef USE_PAM
>>>+	/* Ask PAM to setup session for user running this program */
>>>+	rc = pam_open_session(pam_handle,0);
>>>+	if(rc != PAM_SUCCESS) {
>>>+		fprintf(stderr, "pam_open_session failed with %s\n",
>>>+			pam_strerror(pam_handle, rc));
>>>+		exit(-1);
>>>+	}
>>>+#endif
>>>+	change_pns_effective_caps(CAP_CLEAR);
>>>+
>>
>>If the idea of using pam_permit is works out, then this section of code
>>would be re-bracketed as such:
>>
>>#ifdef USE_PAM
>>#ifdef LSPP_PRIV
>>	change_pns_effective_caps(CAP_SET);
>>#endif /* LSPP_PRIV */
>>	/* Ask PAM to setup session for user running this program */
>>	rc = pam_open_session(pam_handle,0);
>>	if(rc != PAM_SUCCESS) {
>>		fprintf(stderr, "pam_open_session failed with %s\n",
>>			pam_strerror(pam_handle, rc));
>>		exit(-1);
>>	}
>>#ifdef LSPP_PRIV
>>	change_pns_effective_caps(CAP_CLEAR);
>>#endif /* LSPP_PRIV */
>>#endif /* USE_PAM */
>>
>>#ifdef LSPP_PRIV
>>...do audit stuff...
>>#endif /* LSPP_PRIV */
>>
>>
>>We could alternatively just define the cap manipulation functions to do
>>nothing if LSPP_PRIV is not defined and call them unconditionally to
>>clean up the code a bit...
> 
> 
> Yes, that would make the code more readable.
> 

Ok, thanks. I will try and finish this before Sunday, when I leave for
another training trip with limited access to email and no access to
my lspp test machine.

-Janak


--
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] newrole: use pam session management services - v4

[Stephen Smalley]

On Thu, 2006-09-07 at 11:30 -0500, Darrel Goeddel wrote:
> Could we untangle the pam/lspp bits like I have below if we include
> pam_permit as a session module in the "regular" pam config?  I think
> that should take care of the case where we use pam, but do not have
> any session management needs.  The use of pam_permit in this situation
> seems perfectly acceptable to me.  This would give us real session
> management capabilities via pam even if we are not using the lspp
> configuration which requires privilege for pam_namespace.so.

Even better would be if there was an easy way for newrole to dynamically
probe for whether pam_namespace is in its pam config, and to only enable
those capabilities if it is there.  Then we can have a single newrole
binary built with the LSPP support, but it will still drop all
capabilities other than CAP_AUDIT_WRITE at startup if there is no
pam_namespace in its config (as in a non-LSPP system).

-- 
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] newrole: use pam session management services - v4

[Daniel J Walsh]

Stephen Smalley wrote:
> On Thu, 2006-09-07 at 11:30 -0500, Darrel Goeddel wrote:
>   
>> Could we untangle the pam/lspp bits like I have below if we include
>> pam_permit as a session module in the "regular" pam config?  I think
>> that should take care of the case where we use pam, but do not have
>> any session management needs.  The use of pam_permit in this situation
>> seems perfectly acceptable to me.  This would give us real session
>> management capabilities via pam even if we are not using the lspp
>> configuration which requires privilege for pam_namespace.so.
>>     
>
> Even better would be if there was an easy way for newrole to dynamically
> probe for whether pam_namespace is in its pam config, and to only enable
> those capabilities if it is there.  Then we can have a single newrole
> binary built with the LSPP support, but it will still drop all
> capabilities other than CAP_AUDIT_WRITE at startup if there is no
> pam_namespace in its config (as in a non-LSPP system).
>
>   
Could we label it differently.  So if it runs in newrole_lspp_t domain 
it does not drop, otherwise it does.

--
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] newrole: use pam session management services - v4

[Stephen Smalley]

On Fri, 2006-09-08 at 13:28 -0400, Daniel J Walsh wrote:
> Stephen Smalley wrote:
> > On Thu, 2006-09-07 at 11:30 -0500, Darrel Goeddel wrote:
> >   
> >> Could we untangle the pam/lspp bits like I have below if we include
> >> pam_permit as a session module in the "regular" pam config?  I think
> >> that should take care of the case where we use pam, but do not have
> >> any session management needs.  The use of pam_permit in this situation
> >> seems perfectly acceptable to me.  This would give us real session
> >> management capabilities via pam even if we are not using the lspp
> >> configuration which requires privilege for pam_namespace.so.
> >>     
> >
> > Even better would be if there was an easy way for newrole to dynamically
> > probe for whether pam_namespace is in its pam config, and to only enable
> > those capabilities if it is there.  Then we can have a single newrole
> > binary built with the LSPP support, but it will still drop all
> > capabilities other than CAP_AUDIT_WRITE at startup if there is no
> > pam_namespace in its config (as in a non-LSPP system).
> >
> >   
> Could we label it differently.  So if it runs in newrole_lspp_t domain 
> it does not drop, otherwise it does.

For the strict policy, we can easily wrap the allow rules for the
additional capabilities for newrole_t in a conditional with a boolean
that is only enabled in the LSPP config, or we can put the allow rules
in a separate policy module that is only added in the LSPP config.  But
that doesn't help in the case of the default targeted policy where
neither newrole nor its caller are confined by SELinux.

Part of the confusion here is what you plan to put in vanilla
Fedora/RHEL versus the LSPP certified configuration.  I assume you want
a single newrole binary that can handle either case (which means it has
to be setuid root, and include the capability manipulation code and
pam_open_session call).  Do you plan to include pam_namespace in the pam
config always, or only in the LSPP certified configuration?  If the
former, then checking for it at runtime serves no purpose; the build
time option is sufficient.  If the latter, then policycoreutils itself
should never install a newrole pam config that includes pam_namespace;
that should only be done by some LSPP-specific package, and having a
runtime check of whether pam_namespace is present would allow newrole to
immediately shed those capabilities for vanilla Fedora/RHEL users so
that they have no additional exposure.

-- 
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] newrole: use pam session management services - v4

[Daniel J Walsh]

Stephen Smalley wrote:
> On Fri, 2006-09-08 at 13:28 -0400, Daniel J Walsh wrote:
>   
>> Stephen Smalley wrote:
>>     
>>> On Thu, 2006-09-07 at 11:30 -0500, Darrel Goeddel wrote:
>>>   
>>>       
>>>> Could we untangle the pam/lspp bits like I have below if we include
>>>> pam_permit as a session module in the "regular" pam config?  I think
>>>> that should take care of the case where we use pam, but do not have
>>>> any session management needs.  The use of pam_permit in this situation
>>>> seems perfectly acceptable to me.  This would give us real session
>>>> management capabilities via pam even if we are not using the lspp
>>>> configuration which requires privilege for pam_namespace.so.
>>>>     
>>>>         
>>> Even better would be if there was an easy way for newrole to dynamically
>>> probe for whether pam_namespace is in its pam config, and to only enable
>>> those capabilities if it is there.  Then we can have a single newrole
>>> binary built with the LSPP support, but it will still drop all
>>> capabilities other than CAP_AUDIT_WRITE at startup if there is no
>>> pam_namespace in its config (as in a non-LSPP system).
>>>
>>>   
>>>       
>> Could we label it differently.  So if it runs in newrole_lspp_t domain 
>> it does not drop, otherwise it does.
>>     
>
> For the strict policy, we can easily wrap the allow rules for the
> additional capabilities for newrole_t in a conditional with a boolean
> that is only enabled in the LSPP config, or we can put the allow rules
> in a separate policy module that is only added in the LSPP config.  But
> that doesn't help in the case of the default targeted policy where
> neither newrole nor its caller are confined by SELinux.
>
> Part of the confusion here is what you plan to put in vanilla
> Fedora/RHEL versus the LSPP certified configuration.  I assume you want
> a single newrole binary that can handle either case (which means it has
> to be setuid root, and include the capability manipulation code and
> pam_open_session call).  Do you plan to include pam_namespace in the pam
> config always, or only in the LSPP certified configuration?  If the
> former, then checking for it at runtime serves no purpose; the build
> time option is sufficient.  If the latter, then policycoreutils itself
> should never install a newrole pam config that includes pam_namespace;
> that should only be done by some LSPP-specific package, and having a
> runtime check of whether pam_namespace is present would allow newrole to
> immediately shed those capabilities for vanilla Fedora/RHEL users so
> that they have no additional exposure.
>
>   

Why not have newrole not be setuid at all, but when you install the LSPP 
package is sets it setuid.  Then we can only call pam_session if we are 
setuid.  (I think you can check that.)
If you want to use pam_namespace you need to setuid the app, for strict 
policy.

This way the bulk of users do not have another setuid app around.  
newrole is of little use currently in targeted policy.

--
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] newrole: use pam session management services - v4

[Russell Coker]

On Saturday 09 September 2006 04:50, Daniel J Walsh <dwalsh@redhat.com> wrote:
> Why not have newrole not be setuid at all, but when you install the LSPP
> package is sets it setuid.  Then we can only call pam_session if we are
> setuid.  (I think you can check that.)
> If you want to use pam_namespace you need to setuid the app, for strict
> policy.

Yes, namespaces with strict policy is a desirable configuration, so having it 
depend on the LSPP package isn't going to solve all problems.

I guess you could have the strict policy package make it setuid.

-- 
http://etbe.blogspot.com/          My Blog
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages

http://www.coker.com.au/sponsorship.html Sponsoring Free Software development


--
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] newrole: use pam session management services - v4

[Russell Coker]

On Saturday 09 September 2006 04:40, Stephen Smalley <sds@tycho.nsa.gov> 
wrote:
> Part of the confusion here is what you plan to put in vanilla
> Fedora/RHEL versus the LSPP certified configuration.  I assume you want
> a single newrole binary that can handle either case (which means it has
> to be setuid root, and include the capability manipulation code and
> pam_open_session call).  Do you plan to include pam_namespace in the pam
> config always, or only in the LSPP certified configuration?

pam_namespace will provide great benefits for many people who can't use the 
MLS policy, even on targetted systems it can do a lot of good (in some ways 
it can do more good on targetted systems than on strict or MLS).

Why not have a separate package for the newrole program which has 
selinux-policy-strict and selinux-policy-mls depend on it?  Then people who 
only use the targetted policy (most users) will not have newrole installed.

Another thing to consider is to have a type nonexec_t in the targeted policy 
assigned to the newrole program with an assertion that the type in question 
can never be executed.  Then the only case you have to worry about is running 
newrole on a system with SE Linux disabled.

-- 
http://etbe.blogspot.com/          My Blog
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages

http://www.coker.com.au/sponsorship.html Sponsoring Free Software development


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