[refpolicy] mls_systemlow is within mls_systemhigh?

[sds@tycho.nsa.gov (Stephen Smalley)]

On Sat, 2011-02-12 at 09:25 +0000, HarryCiao wrote:
> Hi all,
> 
> I seems to run into a weird problem, that a staff user(t2 in below
> example) that could only assume mls_systemhigh could log in system
> successfully with some other lower security level such as
> mls_systemlow !
> 
> Shouldn't such login be denied?
> 
> The openssh source code calls libselinux API of security_compute_av()
> to check if the source context of staff_u:staff_r:staff_t:s0 is ever
> contained in that of staff_u:staff_r:staff_t:s15:c0.c1023, which could
> be reproduced by the compute_av command:
> 
> [root/sysadm_r/s0 at QtCao ~]# compute_av
> staff_u:staff_r:staff_t:s15:c0.c1023 staff_u:staff_r:staff_t:s0
> context 
> allowed= { contains }
> [root/sysadm_r/s0 at QtCao ~]# 
> 
> How come this ever happen?  Is there a selinuxfs kernel driver bug
> for /selinux/access file?
> 
> Any comment is greatly welcomed. The detailed logs are below.

Looks like policy is configured that way.  policy/mls has this rule:
mlsconstrain context contains
        ( h1 dom h2 );

So as long as the source context high level dominates the target context
high level, the constraint will evaluate to true and the permission will
be allowed.  If you want to enforce a minimal level for a user, you'd
have to rewrite that constraint, e.g.
mlsconstrain context contains 
	( ( h1 dom h2 ) and (l1 domby l2) );


-- 
Stephen Smalley
National Security Agency