directory polyinstantiation failure

directory polyinstantiation failure

[Xavier Toth]

pam_namespace complains that "Pathnames must start with '/'" when I
try and polyinstantiate "$HOME/$USER/.mozilla". Is there a particular
reason that I shouldn't be able to polyinstantiate a dot directory or
is this a bug?

--
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: directory polyinstantiation failure

[Michael C Thompson]

Xavier Toth wrote:
> pam_namespace complains that "Pathnames must start with '/'" when I
> try and polyinstantiate "$HOME/$USER/.mozilla". Is there a particular
> reason that I shouldn't be able to polyinstantiate a dot directory or
> is this a bug?

AFAIK, there is no reason that polyinstantiating shouldn't work for dot 
directories.

Mike

--
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: directory polyinstantiation failure

[Xavier Toth]

If you try and use $HOME in the directory name for instance
$HOME/.mozilla the $HOME is not expanded. I'll submit a patch.

On 4/17/07, Michael C Thompson <thompsmc@us.ibm.com> wrote:
> Xavier Toth wrote:
> > pam_namespace complains that "Pathnames must start with '/'" when I
> > try and polyinstantiate "$HOME/$USER/.mozilla". Is there a particular
> > reason that I shouldn't be able to polyinstantiate a dot directory or
> > is this a bug?
>
> AFAIK, there is no reason that polyinstantiating shouldn't work for dot
> directories.
>
> Mike
>

--
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: directory polyinstantiation failure

[Michael C Thompson]

Xavier Toth wrote:
> If you try and use $HOME in the directory name for instance
> $HOME/.mozilla the $HOME is not expanded. I'll submit a patch.

Nice find, thank you for the patch. :)

Mike

--
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: directory polyinstantiation failure

[Xavier Toth]

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

Here is the patch for to expand $HOME. However as I looked at the code
I see the reason for behavior that had confused me partly because it
isn't documented and partly because I don't think it is desired. I'd
specified some directories to be polyinstantiated by level but then
I'd see that they might also get polyinstantiated by user. The code as
described in the following comment is overriding my specified method
if getexeccon fails.
/*
 * This function checks if the calling program has requested context
 * change by calling setexeccon(). If context change is not requested
 * then it does not make sense to polyinstantiate based on context.
 * The return value from this function is used when selecting the
 * polyinstantiation method. If context change is not requested then
 * the polyinstantiation method is set to USER, even if the configuration
 * file lists the method as "context" or "both".
 */
static int ctxt_based_inst_needed(void)

Why if getexeccon fails doesn't it make sense to polyinstantiate based
on context/level? Why not call getcon lf getexeccon fails and use that
context instead of switching the method?

Oh yeah I also patch the debug output of an error that pam_namespace
doesn't care about so why should I.

On 4/17/07, Michael C Thompson <thompsmc@us.ibm.com> wrote:
> Xavier Toth wrote:
> > If you try and use $HOME in the directory name for instance
> > $HOME/.mozilla the $HOME is not expanded. I'll submit a patch.
>
> Nice find, thank you for the patch. :)
>
> Mike
>

[-- Attachment #2: pam-0.99.7.1-namespace-expand-home.patch --]
[-- Type: text/x-patch, Size: 1565 bytes --]

--- Linux-PAM-0.99.7.0/modules/pam_namespace/pam_namespace.c	2007-04-18 09:32:05.000000000 -0500
+++ Linux-PAM-0.99.7.0.new/modules/pam_namespace/pam_namespace.c	2007-04-18 09:31:23.000000000 -0500
@@ -196,14 +196,18 @@
     uids = strtok_r(NULL, " \t", &tptr);
 
     /*
-     * If the directory being polyinstantiated is the home directory
-     * of the user who is establishing a session, we have to swap
-     * the "$HOME" string with the user's home directory that is
-     * passed in as an argument.
+     * Expand $HOME in dir
      */
-    if (strcmp(dir, "$HOME") == 0) {
-	dir = home;
+    if ((tptr = strstr(dir, "$HOME")) != 0) {
+        if (strlen(dir) > 5) {
+            char *expanded = alloca(strlen(home)+strlen(dir)-5+1);
+            *tptr = 0;
+            sprintf(expanded, "%s%s", home, tptr+5);
+            dir = expanded;
+	}
+	else
+            dir = home;
     }
 
     /*
      * Expand $HOME and $USER in instance dir prefix
@@ -1117,10 +1141,11 @@
 
                 if (umount(pptr->dir) < 0) {
             	    int saved_errno = errno;
-            	    pam_syslog(idata->pamh, LOG_ERR, "Unmount of %s failed, %m",
+            	    if (saved_errno != EINVAL) {
+            	        pam_syslog(idata->pamh, LOG_ERR, "Unmount of %s failed, %m",
                     	pptr->dir);
-            	    if (saved_errno != EINVAL)
                 	return PAM_SESSION_ERR;
+		    }
                 } else if (idata->flags & PAMNS_DEBUG)
                     pam_syslog(idata->pamh, LOG_DEBUG, "Umount succeeded %s",
 				pptr->dir);

Re: directory polyinstantiation failure

[Linda Knippers]

Xavier Toth wrote:
> Here is the patch for to expand $HOME. However as I looked at the code
> I see the reason for behavior that had confused me partly because it
> isn't documented and partly because I don't think it is desired. I'd
> specified some directories to be polyinstantiated by level but then
> I'd see that they might also get polyinstantiated by user. The code as
> described in the following comment is overriding my specified method
> if getexeccon fails.
> /*
> * This function checks if the calling program has requested context
> * change by calling setexeccon(). If context change is not requested
> * then it does not make sense to polyinstantiate based on context.
> * The return value from this function is used when selecting the
> * polyinstantiation method. If context change is not requested then
> * the polyinstantiation method is set to USER, even if the configuration
> * file lists the method as "context" or "both".
> */
> static int ctxt_based_inst_needed(void)
> 
> Why if getexeccon fails doesn't it make sense to polyinstantiate based
> on context/level? Why not call getcon lf getexeccon fails and use that
> context instead of switching the method?

Good question.  What did you end up with for directory names?

Would you be willing to file a couple of bugzillas (one for the $HOME
expansion and one for this behavior) for the LSPP project?  That will
help us determine whether we need fixes for our certification or just
some documentation for now.

Thanks,

-- ljk
> 
> Oh yeah I also patch the debug output of an error that pam_namespace
> doesn't care about so why should I.
> 
> On 4/17/07, Michael C Thompson <thompsmc@us.ibm.com> wrote:
> 
>> Xavier Toth wrote:
>> > If you try and use $HOME in the directory name for instance
>> > $HOME/.mozilla the $HOME is not expanded. I'll submit a patch.
>>
>> Nice find, thank you for the patch. :)
>>
>> Mike
>>
> 
> ------------------------------------------------------------------------
> 
> --- Linux-PAM-0.99.7.0/modules/pam_namespace/pam_namespace.c	2007-04-18 09:32:05.000000000 -0500
> +++ Linux-PAM-0.99.7.0.new/modules/pam_namespace/pam_namespace.c	2007-04-18 09:31:23.000000000 -0500
> @@ -196,14 +196,18 @@
>      uids = strtok_r(NULL, " \t", &tptr);
>  
>      /*
> -     * If the directory being polyinstantiated is the home directory
> -     * of the user who is establishing a session, we have to swap
> -     * the "$HOME" string with the user's home directory that is
> -     * passed in as an argument.
> +     * Expand $HOME in dir
>       */
> -    if (strcmp(dir, "$HOME") == 0) {
> -	dir = home;
> +    if ((tptr = strstr(dir, "$HOME")) != 0) {
> +        if (strlen(dir) > 5) {
> +            char *expanded = alloca(strlen(home)+strlen(dir)-5+1);
> +            *tptr = 0;
> +            sprintf(expanded, "%s%s", home, tptr+5);
> +            dir = expanded;
> +	}
> +	else
> +            dir = home;
>      }
>  
>      /*
>       * Expand $HOME and $USER in instance dir prefix
> @@ -1117,10 +1141,11 @@
>  
>                  if (umount(pptr->dir) < 0) {
>              	    int saved_errno = errno;
> -            	    pam_syslog(idata->pamh, LOG_ERR, "Unmount of %s failed, %m",
> +            	    if (saved_errno != EINVAL) {
> +            	        pam_syslog(idata->pamh, LOG_ERR, "Unmount of %s failed, %m",
>                      	pptr->dir);
> -            	    if (saved_errno != EINVAL)
>                  	return PAM_SESSION_ERR;
> +		    }
>                  } else if (idata->flags & PAMNS_DEBUG)
>                      pam_syslog(idata->pamh, LOG_DEBUG, "Umount succeeded %s",
>  				pptr->dir);


--
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: directory polyinstantiation failure

[Ted X Toth]

Linda Knippers wrote:
> Xavier Toth wrote:
>   
>> Here is the patch for to expand $HOME. However as I looked at the code
>> I see the reason for behavior that had confused me partly because it
>> isn't documented and partly because I don't think it is desired. I'd
>> specified some directories to be polyinstantiated by level but then
>> I'd see that they might also get polyinstantiated by user. The code as
>> described in the following comment is overriding my specified method
>> if getexeccon fails.
>> /*
>> * This function checks if the calling program has requested context
>> * change by calling setexeccon(). If context change is not requested
>> * then it does not make sense to polyinstantiate based on context.
>> * The return value from this function is used when selecting the
>> * polyinstantiation method. If context change is not requested then
>> * the polyinstantiation method is set to USER, even if the configuration
>> * file lists the method as "context" or "both".
>> */
>> static int ctxt_based_inst_needed(void)
>>
>> Why if getexeccon fails doesn't it make sense to polyinstantiate based
>> on context/level? Why not call getcon lf getexeccon fails and use that
>> context instead of switching the method?
>>     
>
> Good question.  What did you end up with for directory names?
>
> Would you be willing to file a couple of bugzillas (one for the $HOME
> expansion and one for this behavior) for the LSPP project?  That will
> help us determine whether we need fixes for our certification or just
> some documentation for now.
>
> Thanks,
>
> -- ljk
>   
>> Oh yeah I also patch the debug output of an error that pam_namespace
>> doesn't care about so why should I.
>>
>> On 4/17/07, Michael C Thompson <thompsmc@us.ibm.com> wrote:
>>
>>     
>>> Xavier Toth wrote:
>>>       
>>>> If you try and use $HOME in the directory name for instance
>>>> $HOME/.mozilla the $HOME is not expanded. I'll submit a patch.
>>>>         
>>> Nice find, thank you for the patch. :)
>>>
>>> Mike
>>>
>>>       
>> ------------------------------------------------------------------------
>>
>> --- Linux-PAM-0.99.7.0/modules/pam_namespace/pam_namespace.c	2007-04-18 09:32:05.000000000 -0500
>> +++ Linux-PAM-0.99.7.0.new/modules/pam_namespace/pam_namespace.c	2007-04-18 09:31:23.000000000 -0500
>> @@ -196,14 +196,18 @@
>>      uids = strtok_r(NULL, " \t", &tptr);
>>  
>>      /*
>> -     * If the directory being polyinstantiated is the home directory
>> -     * of the user who is establishing a session, we have to swap
>> -     * the "$HOME" string with the user's home directory that is
>> -     * passed in as an argument.
>> +     * Expand $HOME in dir
>>       */
>> -    if (strcmp(dir, "$HOME") == 0) {
>> -	dir = home;
>> +    if ((tptr = strstr(dir, "$HOME")) != 0) {
>> +        if (strlen(dir) > 5) {
>> +            char *expanded = alloca(strlen(home)+strlen(dir)-5+1);
>> +            *tptr = 0;
>> +            sprintf(expanded, "%s%s", home, tptr+5);
>> +            dir = expanded;
>> +	}
>> +	else
>> +            dir = home;
>>      }
>>  
>>      /*
>>       * Expand $HOME and $USER in instance dir prefix
>> @@ -1117,10 +1141,11 @@
>>  
>>                  if (umount(pptr->dir) < 0) {
>>              	    int saved_errno = errno;
>> -            	    pam_syslog(idata->pamh, LOG_ERR, "Unmount of %s failed, %m",
>> +            	    if (saved_errno != EINVAL) {
>> +            	        pam_syslog(idata->pamh, LOG_ERR, "Unmount of %s failed, %m",
>>                      	pptr->dir);
>> -            	    if (saved_errno != EINVAL)
>>                  	return PAM_SESSION_ERR;
>> +		    }
>>                  } else if (idata->flags & PAMNS_DEBUG)
>>                      pam_syslog(idata->pamh, LOG_DEBUG, "Umount succeeded %s",
>>  				pptr->dir);
>>     
>
>
>   
With the patch I can now polyinstantiate directories with names like 
'$HOME/.mozilla', is that what you were asking? I'd be more than happy 
to file the bug reports but I don't have access to bugzilla.

Ted

--
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: directory polyinstantiation failure

[Russell Coker]

On Thursday 19 April 2007 02:59, "Xavier Toth" <txtoth@gmail.com> wrote:
> Why if getexeccon fails doesn't it make sense to polyinstantiate based
> on context/level? Why not call getcon lf getexeccon fails and use that
> context instead of switching the method?

That depends on the aim of the PI.

If the aim is merely to isolate the session from other sessions then it's 
probably OK to skip the things that don't change (although this optimisation 
doesn't seem to give any benefit).

If the aim is to give each session a PI directory that matches it's context 
such that any other session which is established with the same context will 
have the same directory then all items have to be used.

Also while on the topic, we need an option to do PI based on the GID as well 
(this was requested on a few occasions when I gave talks about it).  So we 
could have configuration options to specify a list of items to use, the full 
SE Linux context, the MLS/MCS level, the role, the Linux UID, and the Linux 
GID.

-- 
russell@coker.com.au
http://etbe.blogspot.com/          My Blog

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: directory polyinstantiation failure

[Chad Hanson]

I believe "user" fallback case also creates a problem in utilizing namespace
for the current version of GDM with RHEL 5 from my testing. 

-Chad

> -----Original Message-----
> From: Xavier Toth [mailto:txtoth@gmail.com] 
> Sent: Wednesday, April 18, 2007 12:00 PM
> To: Michael C Thompson
> Cc: selinux@tycho.nsa.gov
> Subject: Re: directory polyinstantiation failure
> 
> Here is the patch for to expand $HOME. However as I looked at 
> the code I see the reason for behavior that had confused me 
> partly because it isn't documented and partly because I don't 
> think it is desired. I'd specified some directories to be 
> polyinstantiated by level but then I'd see that they might 
> also get polyinstantiated by user. The code as described in 
> the following comment is overriding my specified method if 
> getexeccon fails.
> /*
>  * This function checks if the calling program has requested context
>  * change by calling setexeccon(). If context change is not requested
>  * then it does not make sense to polyinstantiate based on context.
>  * The return value from this function is used when selecting the
>  * polyinstantiation method. If context change is not requested then
>  * the polyinstantiation method is set to USER, even if the 
> configuration
>  * file lists the method as "context" or "both".
>  */
> static int ctxt_based_inst_needed(void)
> 
> Why if getexeccon fails doesn't it make sense to 
> polyinstantiate based on context/level? Why not call getcon 
> lf getexeccon fails and use that context instead of switching 
> the method?
> 

--
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: directory polyinstantiation failure

[Ted X Toth]

Here is the bug I opened:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=237249

Hopefully others will add their input because I think this need more 
attention than just a documentation change.


Chad Hanson wrote:
> I believe "user" fallback case also creates a problem in utilizing namespace
> for the current version of GDM with RHEL 5 from my testing. 
>
> -Chad
>
>   
>> -----Original Message-----
>> From: Xavier Toth [mailto:txtoth@gmail.com] 
>> Sent: Wednesday, April 18, 2007 12:00 PM
>> To: Michael C Thompson
>> Cc: selinux@tycho.nsa.gov
>> Subject: Re: directory polyinstantiation failure
>>
>> Here is the patch for to expand $HOME. However as I looked at 
>> the code I see the reason for behavior that had confused me 
>> partly because it isn't documented and partly because I don't 
>> think it is desired. I'd specified some directories to be 
>> polyinstantiated by level but then I'd see that they might 
>> also get polyinstantiated by user. The code as described in 
>> the following comment is overriding my specified method if 
>> getexeccon fails.
>> /*
>>  * This function checks if the calling program has requested context
>>  * change by calling setexeccon(). If context change is not requested
>>  * then it does not make sense to polyinstantiate based on context.
>>  * The return value from this function is used when selecting the
>>  * polyinstantiation method. If context change is not requested then
>>  * the polyinstantiation method is set to USER, even if the 
>> configuration
>>  * file lists the method as "context" or "both".
>>  */
>> static int ctxt_based_inst_needed(void)
>>
>> Why if getexeccon fails doesn't it make sense to 
>> polyinstantiate based on context/level? Why not call getcon 
>> lf getexeccon fails and use that context instead of switching 
>> the method?
>>
>>     



--
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: directory polyinstantiation failure

[Ted X Toth]

Russell Coker wrote:
> On Thursday 19 April 2007 02:59, "Xavier Toth" <txtoth@gmail.com> wrote:
>   
>> Why if getexeccon fails doesn't it make sense to polyinstantiate based
>> on context/level? Why not call getcon lf getexeccon fails and use that
>> context instead of switching the method?
>>     
>
> That depends on the aim of the PI.
>
> If the aim is merely to isolate the session from other sessions then it's 
> probably OK to skip the things that don't change (although this optimisation 
> doesn't seem to give any benefit).
>
> If the aim is to give each session a PI directory that matches it's context 
> such that any other session which is established with the same context will 
> have the same directory then all items have to be used.
>
> Also while on the topic, we need an option to do PI based on the GID as well 
> (this was requested on a few occasions when I gave talks about it).  So we 
> could have configuration options to specify a list of items to use, the full 
> SE Linux context, the MLS/MCS level, the role, the Linux UID, and the Linux 
> GID.
>
>   
One of the enhancements I've thinking about would be to allow for a user 
defined method for naming instead of the fixed naming of the current 
implementation. There could be expandable terms like USER, CONTEXT, 
LEVEL, UID, GID, HASH, ROLE which could be used to format the name to be 
generated. For example :
/tmp/foo    /tmp/foo.inst     $LEVEL_$USER   root


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