From: sds@tycho.nsa.gov (Stephen Smalley) Date: Mon, 14 Feb 2011 08:26:35 -0500 Subject: [refpolicy] mls_systemlow is within mls_systemhigh? In-Reply-To: References: Message-ID: <1297689995.29692.7.camel@moss-pluto> To: refpolicy@oss.tresys.com List-Id: refpolicy.oss.tresys.com 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