On Thu, 2006-12-07 at 11:17 -0500, Daniel J Walsh wrote: > I am trying to fix the problems with polyinstatiation and SELinux Policy > in MLS. > > I have found that the way pam_namespace works is broken from an SELinux > point of view. > > If I setup the /tmp directory to polyinstatiate and I log in as a > staff_t, I end up with /tmp mounted as staff_tmp_t instead of tmp_t. > This is wrong, since confined apps that I run as a user expect tmp_t. > > Similarly /home/dwalsh gets mounted as staff_home_t instead of > staff_home_dir_t. This causes all of the transitions to fail. > > The problem is the pam_namespace is asking the system if staff_t creates > a directory in tmp_t how should it be created. The system responds > staff_tmp_t. What pam_namespace should be doing is taking the directory > tmp_t and replacing it's MLS level with the level of the user. That is all.
security_compute_member() and the type_member rules in the policy configuration are supposed to provide the policy decision for polyinstantiation rather than a hardcoded policy in pam_namespace. Depending on your goal, you might want per-role instantiation of a directory as well and take away the ability to directly write to e.g. tmp_t from all user domains, only letting them write to their own xxx_tmp_t type. Part of the problem is that type_member rules currently only trigger level instantiation if the new type differs from the old, so you can't just say type_member staff_t tmp_t:dir tmp_t; That could be changed, but requires a (trivial) kernel patch. You could work around it by labeling the top-level directories like /tmp and /home/dwalsh with other types (e.g. poly_tmp_t, poly_home_t) distinct for polyinstantiated directories, and then define type_member rules on those, e.g. type_member staff_t poly_tmp_t:dir tmp_t; type_member staff_t poly_home_t:dir staff_home_dir_t; > So staff_t loging in as s0:c1 > will end up with /tmp being > system_u:object_r:tmp_t:s0:c1 > And /home/dwalsh > system_u:object_r:staff_home_dir_t:s0:c1 > > > I am trying out a patched version of pam_namespace to see if this fixes > the problem. > > Am I makeing the correct assumption. If I read it correctly, the patch completely removes the use of security_compute_member, and hardcodes per-level instantiation. So that limits its usefulness to MLS. Other comments: - Need to check return codes from context_new, context_range_set, context_str, strdup and handle appropriately, - I don't think you want the full range from scontext - just the low level (aka current/sensitivity level). -- Stephen Smalley National Security Agency -- redhat-lspp mailing list [email protected] https://www.redhat.com/mailman/listinfo/redhat-lspp
