Bug 237249

It's really questionable what is the best behaviour in the case getexeccon
fails. It would perhaps also make sense to completely fail out.

But I completely agree that the behavior should be documented.

I'll go for man page updates.

Behavior documented in pam-0.99.6.2-3.21.el5.

Man pages were updated. Taking this off the LSPP tracker.

Created attachment 153379 [details]
method change patch

I think this needs more than a doc change so I created a patch. The patch calls
getcon in the event that getexeccon fails and it doesn't change the user
specified method.

But if getexeccon fails, wouldn't that polyinstantiate based on the daemon's
context instead of the user's intended context? IOW,
system_u:system_r:xdm_t:SystemLow-SystemHigh. That would not be good either.

I'm curious if there is a valid application calling pam which wouldn't call
setexeccon and have the proper user's context assigned by other means?

If some app like this exists I think the best solution would be to add an option
which would make pam_namespace to simply call getcon instead of getexeccon. I'm
not really sure we want to change the current behavior unconditionally.

(In reply to comment #8)
> But if getexeccon fails, wouldn't that polyinstantiate based on the daemon's
> context instead of the user's intended context? IOW,
> system_u:system_r:xdm_t:SystemLow-SystemHigh. That would not be good either.

You're right so I took a crack at the patch. Instead of a straight getcon if
getexeccon fails I'm getting the users default context and using that instead. 

--- Linux-PAM-0.99.7.0/modules/pam_namespace/pam_namespace.c	2007-04-25
10:45:52.000000000 -0500
+++ Linux-PAM-0.99.7.0.new/modules/pam_namespace/pam_namespace.c	2007-04-25
10:45:37.000000000 -0500
@@ -251,21 +251,15 @@
 
     poly.method = NONE;
     if (strcmp(method, "user") == 0) 
-	    poly.method = USER;
+        poly.method = USER;
 
 #ifdef WITH_SELINUX
     if (strcmp(method, "level") == 0) {
-        if (idata->flags & PAMNS_CTXT_BASED_INST)
-            poly.method = LEVEL;
-	else
-            poly.method = USER;
+        poly.method = LEVEL;
     }
 
     if (strcmp(method, "context") == 0) {
-        if (idata->flags & PAMNS_CTXT_BASED_INST)
-            poly.method = CONTEXT;
-	else
-            poly.method = USER;
+        poly.method = CONTEXT;
     }
 
 #endif
@@ -447,6 +441,7 @@
 	int rc = PAM_SUCCESS;
 	security_context_t scon = NULL;
 	security_class_t tclass;
+	char *selinuxuser, *level;
 
 	/*
 	 * Get the security context of the directory to polyinstantiate.
@@ -462,9 +457,29 @@
 
 	rc = getexeccon(&scon);
 	if (rc < 0 || scon == NULL) {
+	    
+	  rc = getseuserbyname(idata->user, &selinuxuser, &level);
+	  if (rc < 0) {
 		pam_syslog(idata->pamh, LOG_ERR, 
-			   "Error getting exec context, %m");
+			   "Error getting selinux user, %m");
 		return PAM_SESSION_ERR;
+	  }
+	  if (idata->flags & PAMNS_DEBUG)
+	    pam_syslog(idata->pamh, LOG_DEBUG,
+		       "selinux user %s level %s", selinuxuser, level);
+	  
+	  rc = get_default_context_with_level(selinuxuser, level, NULL, &scon);
+	  free(selinuxuser);
+	  free(level);
+	  if (rc < 0) {
+		pam_syslog(idata->pamh, LOG_ERR, 
+			   "Error getting selinux user default context, %m");
+		return PAM_SESSION_ERR;
+	  }
+	  if (idata->flags & PAMNS_DEBUG)
+	    pam_syslog(idata->pamh, LOG_DEBUG,
+		       "selinux user default context %s", scon);
+	  
 	}
 
 	/*
@@ -515,6 +530,10 @@
 			pam_syslog(idata->pamh, LOG_ERR, "Unable to set MLS Componant of context");
 			goto fail;
 		}
+		if (idata->flags & PAMNS_DEBUG)
+		  pam_syslog(idata->pamh, LOG_DEBUG,
+			     "context_range_set %s %s", context_str(fcontext), context_str(scontext));
+
 		*i_context=strdup(context_str(fcontext));
 		if (! *i_context) {
 			pam_syslog(idata->pamh, LOG_ERR, "out of memory");

That's debatable as well. I'd just like to know why the getexeccon could fail
and if there is any real application using pam_namespace where the getexeccon
fails and it is reasonable to continue. Because in the standard login/sshd/su...
cases the getexeccon simply shouldn't fail.

gdm which I've configured to use pam_namespace doesn't ever calls setexeccon.
Also I don't believe that su calls setexeccon but I could be wrong.

They call it through pam_selinux.

Oops... I should have looked at the pam configs first. You're right that they
don't  have pam_selinux in configuration. But probably that should be changed?

And looking at the gdm sources it calls setexeccon on its own but after
pam_open_session is called so that's why pam_namespace doesn't see it.

Well then the patch from comment 10 could make sense, however I'd prefer it
being optional.

Thee su case is different because it doesn't change the context at all. So in
its case it would make more sense to get the context using getcon. Again that
could be a different option.

(In reply to comment #15)
> And looking at the gdm sources it calls setexeccon on its own but after
> pam_open_session is called so that's why pam_namespace doesn't see it.
> 
> Well then the patch from comment 10 could make sense, however I'd prefer it
> being optional.
> 
> Thee su case is different because it doesn't change the context at all. So in
> its case it would make more sense to get the context using getcon. Again that
> could be a different option.
> 
> 
What are you suggesting be the behavior if the option to use the users default
context is not set and in the case of su if the option to use getcon is not set?

(In reply to comment #15)
> And looking at the gdm sources it calls setexeccon on its own but after
> pam_open_session is called so that's why pam_namespace doesn't see it.
> 
> Well then the patch from comment 10 could make sense, however I'd prefer it
> being optional.
> 
> Thee su case is different because it doesn't change the context at all. So in
> its case it would make more sense to get the context using getcon. Again that
> could be a different option.
> 
> 
What are you suggesting be the behavior if the option to use the users default
context is not set and in the case of su if the option to use getcon is not set?

Either the current fallback to just username based polyinst. or returning
PAM_SESSION_ERROR.

This bug is about documenting the current behavior for RHEL5. I've created bug
237876 for the future development.

An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHSA-2007-0555.html