[redhat-lspp] some additional pam_namespace issues ..

JANAK DESAI janak at us.ibm.com
Thu Feb 16 17:10:54 UTC 2006


I have a couple more pam_namespace issues that I would like your
thoughts on. As an example, I will use /tmp as a directory that is being
polyinstantiated based on user and security context.

Current polyinst mechanism makes available the original /tmp
directory from a protected alternate location (/.poly*), so trusted
apps that wish to process un-polyinstantiated /tmp can do so.
Trusted apps can use pam to figure out which directories are
being polyinstantiated and how to locate their alternate location.
A cleaner way (suggested by Dan Walsh and Al Viro) for a
trusted app to access the original directory is to simply unmount
the instance directory. So for example, when an a user logs
in, /tmp/user-instance is bind mounted on top of /tmp. When
that user executes a trusted app, the app can use pam_namespace,
which can unshare namespace and unmount /tmp. That will
will unmount the instance directory and expose the original
/tmp. With this approach we won't need to create alternate
location directory and bind mount the original /tmp there.
I have unit tested this and it works well. Does anyone see any
issues in getting to the original directory in this manner?

The second is a question regarding su/getexeccon/getcon..
The pam_namespace module uses pam session management
hooks to create polyinstantiation instance directory based on
the context returned by getexeccon. Since su no longer
uses pam_selinux (which does a setexeccon), getexeccon
in pam_namespace returns null. I am wondering if it is
ok to use getcon() when getexeccon() returns null (indicating
default policy behavior for the context of the next execed
process)? If I use getcon(), su will re-polyinstantiate based
on the correct new user id and the correct mls range,
however the domain name used in instance directory
will not reflect the domain of the shell executed by su.
However, since we do not re-polyinstantiate on domain
transitions through execs anyway, I am guessing using
getcon() is acceptable. Thoughts?

-Janak




More information about the redhat-lspp mailing list