[redhat-lspp] pam_namespace is broken from an SELinux perspective.

[Stephen Smalley]

On Thu, 2006-12-07 at 12:36 -0500, Stephen Smalley wrote:
> 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).

Oh, and you either need to check whether MLS is enabled or gracefully
handle a NULL result from context_range_get in case MLS is disabled.

-- 
Stephen Smalley
National Security Agency