[redhat-lspp] Re: [PATCH 2/3] Re: MLS enforcing PTYs, sshd, and newrole

Stephen Smalley sds at tycho.nsa.gov
Tue Oct 31 16:21:15 UTC 2006


On Tue, 2006-10-31 at 11:04 -0500, James Antill wrote:
> On Tue, 2006-10-31 at 10:11 -0500, Stephen Smalley wrote:
> 
> > As I understood it (and the code in pam seems to match this), you were
> > going to generate two security contexts for the user session, one based
> > on seusers and one based on the provided range, otherwise identical in
> > all respects, and apply a permission check between those two contexts.
> > So for example, if my seusers-defined default context would be
> > staff_u:staff_r:staff_t:s0-s0:c0.c255 and I entered a level of s0:c3 as
> > input, there would be a permission check made by pam_selinux between
> > staff_u:staff_r:staff_t:s0-s0:c0.c255 and staff_u:staff_r:staff_t:s0:c3.
> 
>  This should all be true.
> 
> > Thus, the TE rule would have to be between staff_t and itself (i.e. the
> > user domains), not between local_login_t and anything.
> 
>  Right. Does the mlsconstrain line not do that?

The mlsconstrain line wasn't my concern - it was the TE rule.

> > We aren't checking whether login can do anything (or using its context
> > anywhere); we are checking whether the seusers-defined default context
> > for the user contains the user-supplied context.
> 
>  Right my understanding was that the policy line:
> 
> allow $1 domain:context transition
> 
> ...meant that the login program could make security call:
> 
>  security_compute_av(src, dst, SECCLASS_CONTEXT, CONTEXT__TRANSITION, &avd)

No.  The ability to make the security call is controlled by the
compute_av permission on the security class, and isn't based on the
individual contexts passed as arguments.  That would be:
	allow $1 security_t:security compute_av;
which has an interface:
	selinux_compute_access_vector($1)
which is already in authlogin.if.  No change required for allowing the
call to happen.

What you are instead trying to do is to define the _result_ of that
compute_av call based on its arguments, not whether it can be made by
login.  So the TE rule would go into userdomain.if and be of the form:
	allow $1 self:context <permissionname>;

The mlsconstrain statement is ok, as long as it is sufficient to check
the high levels and not impose any constraint on the low levels.
 
-- 
Stephen Smalley
National Security Agency




More information about the redhat-lspp mailing list